Linux 5.5 freigegeben: Wireguard-Fundament und Performance-Verbesserungen
Seite 3: Verbesserungen für Qualität und Live-Patching
Live-Patching wird flexibler
Mit Linux 5.5 wird es leichter, einen bereits mit Kernel Live Patching (KLP) zur Laufzeit veränderten Kernel abermals im Betrieb zu modifizieren. Das ist "System State Tracking" zu verdanken, durch das der Kernel selbst Buch über bereits vorgenommene Änderungen führt. Entwickler können mit diesen Informationen komplexere und verwobene Live-Patches erstellen. Das erleichtert es deutlich, Sicherheitslücken in Code-Bereichen zur Laufzeit zu flicken, die bereits ein anderer Live-Patch zuvor modifiziert hat. Das gilt umso mehr, wenn der ältere Live-Patch dazu auch Datenstrukturen in nicht-abwärtskompatibler Weise angepasst hat (u. a. 1, 2, Dokumentation).
Arbeitsverteilung grundrenoviert
Der Prozess-Scheduler nutzt beim Verteilen der Arbeit auf die Prozessorkerne jetzt einen grundlegend neuen Ansatz, der zeitgemäßer vorgeht und die Performance mancher Workloads zu verbessern verspricht (u. a. 1, [2, 3, 4, 5, 6). Der neue Load-Balancing-Code verhält sich allerdings etwas anders, daher ist er in einigen Situationen besser, in manchen aber vielleicht auch schlechter. Daher gab es Befürchtungen, dass der Ansatz nochmal überarbeitet werden muss. Da bislang keine größeren Probleme an die Kernel-Entwickler herangetragen wurden, spricht mittlerweile viel dafür, dass der Code verbleibt, aber in nächster Zeit noch Feintuning erhält.
Der Kernel bietet über den Systemaufruf clone3() jetzt einen zuverlässigeren Weg, um neuen Prozessen eine bestimmte Process ID (PID) zuzuweisen. Das ist vor allem zum Wiederanlaufenlassen von Programmen wichtig, die mit CRIU (Checkpoint/Restore In Userspace) eingefroren wurden. Genau für diesen Einsatzweck ist auch der Time Namespace hilfreich, der bei Linux 5.6 folgen soll und verhindern kann, dass Anwendungen beim Aufwachen einen Zeitsprung bemerken.
Die Kernel-Entwickler haben den Systemaufruf sysctl() entfernt – augenscheinlich nutzt den keiner mehr, da sich darüber einstellbare Konfigurationsoptionen seit vielen Jahren auch via /proc/ setzen lassen.
Kernel-Code durchtesten
Das schon länger in Linux enthaltene Coverage-Testing-Framework "Kcov" ermöglicht Fuzzing-Programmen nun Einblicke in Hintergrund-Threads des Kernels. Das Testprogramm Syzkaller, das schon hunderte sicherheitsrelevante Fehler in Linux und anderen Betriebssystemen aufgespürt hat, konnte durch diese Kcov-Erweiterung eine Reihe von Fehlern im USB-Code von Linux finden, die bereits korrigiert wurden.
Der Linux-Quellcode enthält jetzt das "Kunit" genannte Framework, über das Entwickler ihren Kernel-Code mit Unit Tests auf korrekte Funktion prüfen können. Der End-to-End-Testing ermöglichende Ansatz macht sich User Mode Linux (UML) zunutze, mit dem sich ein Linux-Kernel wie ein normaler Prozess unter einem anderen Linux-Kernel starten lässt (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11). Weitere Details zur Funktionsweise und den Einsatzmöglichkeiten liefern die Kunit-Dokumentation und der "LWN.net-Artikel "A kernel unit-testing framework". Noch weiter in die Tiefe gehen die Vortragsfolien und die Videoaufzeichnung eines im September auf der Linux Plumbers Conference (LPC) 2019 gehaltenen Vortrags:
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Rüsten fürs Jahr-2038 und Kernel anders installieren
Viel Feinschliff erhielten die Änderungen, um das Jahr-2038-Problem (Y2K38) auf 32-Bit-Systemen zu vermeiden (1, 2). Dadurch kann man jetzt auch testweise Systemaufrufe deaktivieren, die bekanntermaßen einen zu kleinen Zeitstempel enthalten. Das führt dann zu Laufzeitfehlern, über die Entwickler zuverlässig die Programme aufspüren können, die noch nicht Jahr-2038-fest sind; diese müssen sie dann anpassen, um die alternativen, in den letzten zwei bis drei Jahren geschaffenen Systemaufrufe zu nutzen, die einen größeren Zeitstempel verstehen.
Dank eines neuen Make-Target kann man einen gebauten Kernel jetzt per make dir-pkg leicht in ein temporäres Verzeichnis installieren. Das ist für Anwender gedacht, die dieses Verzeichnis dann per scp, rsync & Co. auf einen anderen Rechner übertragen wollen, für den der neu gebaute Kernel gedacht ist.
Die Kernel-Dokumentation beschreibt über die neuen "Maintainer Entry Profiles" jetzt Eigenarten, die bei der Entwicklung für einige Subsysteme des Kernels wichtig sein können.
Wie immer gab es viele kleine Performance-Optimierungen am Memory-Management-Code, die wir hier nur anreißen. Ein Entwickler hat etwa eine lediglich vierzeilige Änderung vorgenommen, durch die sich die Zeit zum Kompilieren eines Kernels bei seinem Multicore-System von zirka 2:50 Minuten auf 2:40 reduzierte.
Kleine, nette Verbesserungen bei Analyse- und Messwerkzeugen
Unter zahlreichen Änderungen an der Infrastruktur von Perf und dem Performance-Analyse-Tool selbst war etwa eine Erweiterung von perf diff, durch die das Werkzeug die Standardabweichung mit einer UTF8-Balkengrafik anzeigen kann. Viele weitere Neuerungen bei Perf nennen einige Sub-Git-Merges (1, 2, 3, 4, 5, 6).
Auch bei Ftrace gab es wieder allerlei Neues (1, 2) – darunter etwa Verbesserungen, um Ftrace zuverlässig innerhalb des Kernels nutzen zu können.
Details zu diesen und weitere Änderungen an der allgemeinen Infrastruktur von Linux nennen die wichtigsten Git-Pull-Requests der Bereiche ACPI, Apparmor, Cgroup, Crypto, Device Properties, Documentation, IOMMU, Kbuild, Kgdb, Kselftests, Livepatches, Locking, Modules, Power Management, Printk, RCU (Core), Seccomp, SELinux, Threads, TPM und TTY.
