Запуск инструментов производительности с использованием RBAC - PullRequest
Новая
       98

Запуск инструментов производительности с использованием RBAC

1 голос
/ 21 февраля 2020

Я недавно приступил к работе, которая потребует значительных настроек производительности.

Мне было интересно, можно ли использовать такие инструменты, как eBPF и perf, с RBA C? Или потребуется полный root доступ? Получение доступа root может быть затруднено. В основном мы используем довольно старые Linux машины - RHEL 6.5. Я не слишком знаком с RBA C. Дома я использовал Dtrace в Solaris, macOS и FreeBSD, но там у меня есть пароль root.

1 Ответ

2 голосов
/ 22 февраля 2020

RHEL перечисляет несколько решений для профилирования и трассировки для RHEL6, включая perf в своих Руководстве по настройке производительности и Руководство разработчика : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-analyzperf-perf https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/perf-using

Глава 3. Мониторинг и анализ производительности системы из Руководство по настройке производительности упоминает несколько инструментов: Gnome System Monitor, KDE System Guard, Performance Co-Pilot ( PCP), top / ps / vmstat / sar, tuned и ktune, MRG Tuna и профилировщики приложений SystemTap, Oprofile, Valgrind (который не является реальным профилировщиком, а эмулятором процессора с подсчетом команд и событий кэша), perf.

Глава 5. Профилирование из Руководство разработчика перечисляет Valgrind, oprofile, SystemTap, perf и ftrace.

Обычно профилирование ядра или всей системы допускается только для root, или для пользователя с возможностью CAP_SYS_ADMIN. Некоторое профилирование ограничено переменными sysctl 

perf_event_paranoid:

Использование элементов управления системы событий производительности непривилегированными пользователями (без CAP_SYS_ADMIN). Значение по умолчанию: 2. 

 -1: Allow use of (almost) all events by all users
     Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>=0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN
     Disallow raw tracepoint access by users without CAP_SYS_ADMIN
>=1: Disallow CPU event access by users without CAP_SYS_ADMIN
>=2: Disallow kernel profiling by users without CAP_SYS_ADMIN

kptr_restrict:

This toggle indicates whether restrictions are placed on
exposing kernel addresses via /proc and other interfaces.

Более поздние версии ubuntu и rhel (7.4) также имеют kernel.yama.ptrace_scope http://security-plus-data-science.blogspot.com/2017/09/some-security-updates-in-rhel-74.html

... используйте kernel.yama.ptrace_scope, чтобы установить, кто может выполнять трассировку. Различные значения имеют следующее значение: 

# 0 - Default attach security permissions.
# 1 - Restricted attach. Only child processes plus normal permissions.
# 2 - Admin-only attach. Only executables with CAP_SYS_PTRACE.
# 3 - No attach. No process may call ptrace at all. Irrevocable until next boot.

Вы можете временно установить его следующим образом: 

 echo 2 > /proc/sys/kernel/yama/ptrace_scope

Для профилирования программы вы должны иметь доступ к ее отладке, например присоединение с помощью gdb (возможность ptrace) или strace. Я не знаю RHEL или его RBA C, поэтому вы должны проверить, что вам доступно. Как правило, профилирование собственных программ пользовательского пространства по программным событиям доступно для большего количества случаев. Доступ к аппаратным счетчикам процессоров, профилирование программ других пользователей, профилирование ядра более ограничены. Я могу ожидать, что правильно включенный RBA C не должен позволять вам или root профилировать ядро, так как perf может внедрить зонды трассировки и утечки информации от ядра или других пользователей.

Qeole говорит в комментарии что eBPF не реализован для RHEL6 ( добавлено в RHEL7.6 ; с XDP - eXpress Путь данных в RHEL8 ), поэтому вы можете использовать только ftrace для трассировки или stap (SystemTap) для расширенного отслеживания.

...