☰

¿Qué hace el nivel cuatro de paranoia de rendimiento?

tag-icon • tag-icon kernel
¿Qué hace el nivel cuatro de paranoia de rendimiento?

En mi instalación de Ubuntu Focal, kernel.perf_event_paranoidestá configurado en 4 de forma predeterminada:

$ sysctl kernel.perf_event_paranoid
kernel.perf_event_paranoid = 4

(Revisé /etc/sysctl.confel directorio de configuración asociado, no lo configuré).

Esto me parece extraño, porque la documentación del kernel no describe ningún efecto adicional para valores superiores a 2:

perf_event_paranoid:

Controls use of the performance events system by unprivileged
users (without CAP_SYS_ADMIN).  The default value is 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

(Fuente.)

Hice una búsqueda rápida en el código fuente del kernel principal y no pude encontrar ningún lugar donde perf_event_paranoidse comparara con un número superior a 2.

Sin embargo, establecerlo en 4 tiene un efecto. Ejecuté el siguiente comando de rendimiento, perf_event_paranoidconfigurado en 4, comosin raizusuario:

perf stat -e context-switches,cpu-migrations -r 1 -- sleep 1

Muestra el siguiente error:

Error:
Access to performance monitoring and observability operations is limited.
Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open
access to performance monitoring and observability operations for processes
without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability.
More information can be found at 'Perf events and tool security' document:
https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
perf_event_paranoid setting is 4:
  -1: Allow use of (almost) all events by all users
      Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>= 0: Disallow raw and ftrace function tracepoint access
>= 1: Disallow CPU event access
>= 2: Disallow kernel profiling
To make the adjusted perf_event_paranoid setting permanent preserve it
in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = <setting>)

Si cambio kernel.perf_event_paranoida 3 y ejecuto el mismo comando, obtengo el siguiente resultado, nuevamente como usuario no root:


 Performance counter stats for 'sleep 1':

                 0      context-switches:u                                          
                 0      cpu-migrations:u                                            

       1.000502603 seconds time elapsed

       0.000460000 seconds user
       0.000000000 seconds sys

Entonces, cambiar la perf_event_paranoidconfiguración predeterminada de 4 a 3 tiene algún efecto, incluso si la documentación del kernel de Linux no dice qué.

¿Lo que da? ¿Ubuntu viene con un parche personalizado que agrega un nivel de rendimiento nuevo y más paranoico?

Otras distribuciones

Debian parece tener un parche no estándar que crea un perf_event_paranoidnivel 3:

Jeff Vander Stoep publicó el parche el 27 de julio. Agrega otro valor que se puede configurar para el parámetro sysctl (es decir kernel.perf_event_paranoid=3), que se restringe perf_event_open()a procesos con la CAP_SYS_ADMINcapacidad. Actualmente, perf_event_paranoidestá configurado en 2 de forma predeterminada, lo que no permite el acceso a algunas funciones de rendimiento (acceso a puntos de seguimiento sin procesar, acceso a eventos de CPU y perfiles de kernel) a procesos sin las capacidades adecuadas; el parche no cambia el valor predeterminado. También envió otro parche que permitiría configurar el kernel para que 3 sea el valor predeterminado de perf_event_paranoid.

(Fuente.)

Pero parecería que Ubuntu es aún más paranoico que eso.

Respuesta1

El nivel 4 hace exactamente lo mismo que el parche de Debian: desactiva el uso de procesos sin privilegios perf_event_open(). Sin embargo, la restricción entra en vigor en el nivel de paranoia 4, en lugar del nivel de paranoia 3.

Los niveles actuales de paranoia están documentados en un comentario en la fuente del kernel, en el archivo kernel/events/core.c.

/*
 * perf event paranoia level:
 *  -1 - not paranoid at all
 *   0 - disallow raw tracepoint access for unpriv
 *   1 - disallow cpu events for unpriv
 *   2 - disallow kernel profiling for unpriv
 *   4 - disallow all unpriv perf event use
 */

El compromiso que realiza este cambio se puede encontraraquí. (Nota: el mensaje de confirmación y los comentarios del núcleo se contradicen. Los comentarios del núcleo me parecen correctos).

Para resumir:

  • Niveles -1 a 2: Igual que el kernel principal.
  • Nivel 3: ¿Igual que el nivel 2? No se pudo confirmar esto al 100%. Hay una constante PERF_SECURITY_TRACEPOINTestablecida en 3 que todavía se usa en algunos lugares.
  • Nivel 4: deshabilite perf_event_open por completo para usuarios sin privilegios.

Respuesta2

Además de deshabilitarlo para usuarios sin privilegios, como Nick señala correctamente, el nivel de paranoia 4 también parece aplicar las mismas restricciones a archivos privilegiados.

Por ejemplo, en mi sistema Ubuntu 20.04 he configurado un grupo perf_users de acuerdo con eldocumentación oficial, y dotado perfde las siguientes capacidades

$ getcap perf
perf = cap_sys_ptrace,cap_syslog,38+ep

Ejecutar con el nivel de paranoia 3 funciona como se esperaba para usuarios sin privilegios. Sin embargo, en el nivel de paranoia 4, perfdevuelve el error de la pregunta a pesar de las capacidades del archivo.

información relacionada