☰

Was bewirkt Leistungsparanoia Stufe vier?

tag-icon • tag-icon kernel
Was bewirkt Leistungsparanoia Stufe vier?

Bei meiner Installation von Ubuntu Focal kernel.perf_event_paranoidist der Wert standardmäßig auf 4 eingestellt:

$ sysctl kernel.perf_event_paranoid
kernel.perf_event_paranoid = 4

(Ich habe /etc/sysctl.confes im zugehörigen Konfigurationsverzeichnis überprüft, ich habe es nicht festgelegt.)

Das erscheint mir merkwürdig, da in der Kernel-Dokumentation keine zusätzlichen Effekte für Werte über 2 beschrieben werden:

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

(Quelle.)

Ich habe eine schnelle Suche im Quellcode des Hauptkernels durchgeführt und konnte keine Stelle finden, wo perf_event_paranoidmit einer Zahl verglichen wurde, die größer als 2 ist.

Die Einstellung auf 4 hat jedoch einen Effekt. Ich habe den folgenden Perf-Befehl mit perf_event_paranoiddem Wert 4 ausgeführt, alsnicht gerootedBenutzer:

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

Es wird der folgende Fehler angezeigt:

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>)

Wenn ich kernel.perf_event_paranoidzu 3 wechsle und denselben Befehl ausführe, erhalte ich (wieder als Nicht-Root-Benutzer) das folgende Ergebnis:


 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

Das Ändern der perf_event_paranoidEinstellung vom Standardwert 4 auf 3 hat also eine gewisse Auswirkung, auch wenn in der Dokumentation des Linux-Kernels nicht angegeben ist, welche.

Was ist los? Wird Ubuntu mit einem benutzerdefinierten Patch ausgeliefert, der ein neues, paranoideres Leistungsniveau hinzufügt?

Andere Distributionen

Debian scheint einen nicht standardmäßigen Patch zu haben, der eine perf_event_paranoidEbene 3 erstellt:

Jeff Vander Stoep hat den Patch am 27. Juli gepostet. Er fügt einen weiteren Wert hinzu, der für den Sysctl-Parameter (dh kernel.perf_event_paranoid=3) festgelegt werden kann, der perf_event_open()auf Prozesse mit dieser CAP_SYS_ADMINFähigkeit beschränkt ist. Derzeit perf_event_paranoidist standardmäßig 2 festgelegt, was Prozessen ohne die entsprechenden Fähigkeiten den Zugriff auf einige Leistungsfunktionen (Rohdaten-Tracepoint-Zugriff, CPU-Ereigniszugriff und Kernel-Profiling) verwehrt; der Patch ändert den Standardwert nicht. Er hat auch einen weiteren Patch eingereicht, der es ermöglichen würde, den Kernel so zu konfigurieren, dass 3 der Standardwert für perf_event_paranoid ist.

(Quelle.)

Aber es scheint, dass Ubuntu noch paranoider ist.

Antwort1

Level 4 bewirkt genau dasselbe wie der Debian-Patch: Es verhindert, dass nicht privilegierte Prozesse verwenden perf_event_open(). Die Einschränkung tritt jedoch erst bei Paranoia-Level 4 und nicht erst bei Paranoia-Level 3 in Kraft.

Die aktuellen Paranoia-Stufen sind in einem Kommentar im Kernel-Quellcode in der Datei dokumentiert 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
 */

Das Commit, das diese Änderung vornimmt, finden SieHier. (Hinweis: Die Commit-Nachricht und die Kernel-Kommentare widersprechen sich. Die Kernel-Kommentare scheinen mir korrekt zu sein.)

Zusammenfassen:

  • Ebenen -1 bis 2: Gleich wie der Hauptkernel.
  • Level 3: Dasselbe wie Level 2? Konnte das nicht 100%ig bestätigen. Es gibt eine Konstante PERF_SECURITY_TRACEPOINTauf 3, die an manchen Stellen noch verwendet wird.
  • Stufe 4: Deaktivieren Sie perf_event_open vollständig für nicht privilegierte Benutzer.

Antwort2

Wie Nick richtig anmerkt, werden bei Paranoiastufe 4 die gleichen Einschränkungen nicht nur für nicht privilegierte Benutzer deaktiviert, sondern auch auf privilegierte Dateien angewendet.

Beispielsweise habe ich auf meinem Ubuntu 20.04-System eine perf_users-Gruppe gemäß demamtliche Dokumentationund perfmit den folgenden Fähigkeiten ausgestattet

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

Die Ausführung mit Paranoiastufe 3 funktioniert für nicht privilegierte Benutzer wie erwartet. Bei Paranoiastufe 4 wird jedoch perftrotz der Dateiberechtigungen der Fehler aus der Frage zurückgegeben.

verwandte Informationen