Linux-Kernel: Linux 5.17 mit neuem AMD-Powermanagement
Seite 4: BPF-Schleifen im Kernel
Das wesentliche Design-Prinzip der eBPF-Virtual-Maschine war, sie so einfach wie möglich zu halten. Statt teurer und womöglich unsicherer Konstrukte sollte der Befehlsvorrat schlank und überschaubar bleiben. Das sollte Stabilität, Vorhersagbarkeit und Sicherheit garantieren. Daher waren Schleifen tabu. Ein Programm ohne Schleifen endet grundsätzlich in endlicher Zeit. Dreht es hingegen Schleifen, kann es auch unendlich Kreise drehen.
Was der Systemstabilität dient, ist dem Programmierer hier ein Dorn im Auge. Programmieren ohne Schleifen schränkt nicht nur die möglichen Lösungen ein, sondern auch die Problemstellungen, welche sich adressieren lassen. Mit Linux 5.3 hielten daher die "bounded loops" Einzug. Bei diesen simuliert der eBPF-Verifier die Schleife mit allen möglichen Ausgangszuständen vorab, bevor der Code zum Einsatz kommt. Das soll sicherstellen, dass die Schleife in jedem Fall terminiert. Dieses Verifizieren ist kostspielig und kann einige Zeit in Anspruch nehmen. Zudem ist nicht garantiert, dass der eBPF-Verifier die Schleife auch korrekt als "terminierend" erkennt.
Linux 5.17 führt die Hilfsfunktion bpf_loop() ein, die eBPF-Programme direkt aufrufen können. bpf_loop() erlaubt es, eine Funktion mit einer festen Anzahl an Runden zu durchlaufen. Es ist im Grunde eine formalisierte for-Schleife. Die wiederkehrend aufgerufene Funktion kann über einen Rückgabewert steuern, ob bereits vor dem Erreichen der vorgegebenen Anzahl von Runden die Schleife abgebrochen werden soll. Damit läuft die bpf_loop() maximal die vorher festgelegte Anzahl an Runden und wird in jedem Fall enden. Statt einer aufwendigen Verifikation über eBPF-Code wie bei "bounded loops" verlagert bpf_loop() die Schleife selbst in ein klar definiertes eBPF-Konstrukt. Eine Simulation über den eBPF-Verifier ist bei bpf_loop() daher nicht notwendig.
ID-Remapping erweitert
Mit Kernel 5.12 hielt das ID-Remapping Einzug. Damit lassen sich Dateisysteme (erneut) mounten, wobei die Benutzer- und Gruppen-IDs auf andere abgebildet werden. Das ist hauptsächlich für Container ein nützliches Feature, um so Benutzer und Gruppen auf die passenden IDs im Container "umzubiegen".
Bislang war das ID-Remapping auf den Remount von Dateisystemen beschränkt, die selbst nicht "ID-remapped" waren. Mit Kernel 5.17 ist es jetzt auch möglich, ID-Remapping rekursiv zu verwenden. Dateisysteme mit aktivem ID-Remapping können wiederum einem neuen ID-Remapping unterzogen werden. Damit kommt das Kernel-Team aktuellen Erfordernissen entgegen. Eine Diskussion auf GitHub war Stein des Anstoßes und ist explizit im Commit erwähnt.
Weitere Highlights
Der Zufallszahlengenerator (Random Number Generator = RNG) wechselt vom in die Jahre gekommenen Hash-Algorithmus SHA-1 zu BLAKE2s. SHA-1 gilt schon lange nicht mehr als sicher. Der Wechsel zum sicheren BLAKE2s erhöht zudem auch die RNG-Geschwindigkeit.
Das Modul zum Überwachen von Dateisystemen und -zugriffen fanotify kann über das Ereignis FAN_RENAME umbenannte Dateien melden. Dabei informiert es in Extradatensätzen über den neuen und alten Namen. Damit dampft es die beiden aus inotify-stammenden Einzelereignisse MOVED_FROM und MOVED_TO zu einem Ereignis zusammen.
Im Kontext der Bestrebungen des PREEMPT_RT-Projektes, Linux echtzeitfähig zu machen, erhält Linux auch das "Real-Time Linux Analysis Tool" (RTLA). RTLA bringt Kommandos mit, über die sich die Echtzeiteigenschaften von Linux analysieren lassen. Hierzu nutzt es diverse Kernel-Tracing-Einrichtungen, um präzise Information nicht nur über die Eigenschaften, sondern auch die Ursachen von unerwarteten Ereignissen zu liefern. RTLA vereinfacht es, Performance- und Tracing-Daten fürs Fein-Tuning von System und Algorithmen zu sammeln.
