zurück zum Artikel

Der Linux-Kernel 6.5 liefert Optimierungen und Unterstützung für USB4 v2, MIDI 2.0 und WiFi 7. Memory-Leaks sagt er den Kampf an.

In der Nacht zum Montag dieser Woche wurde der neue Linux-Kernel 6.5 veröffentlicht. Die Entwickler drehten einige Optimierungsschräubchen und bringen den Kernel für neue Hardware in Stellung. Ein Patch für das Vermeiden von Memory-Leaks verspricht, zukünftig die Stabilität des Kernels zu erhöhen.

Bootzeiten verkürzen

Früher war die Welt einfach. Ein Betriebssystem nahm sich allen Arbeitsspeicher, den die Hardware bereitstellte. Seit dem Virtualisieren von mehreren "Computern" auf einer Hardware wurde es vielschichtiger. Die einzelnen virtuellen Maschinen (VM) dürfen einander nicht in die Karten schauen. Sogar beim Hostsystem, das die VMs kontrolliert, verwaltet und ausführt, schwindet das bedingungslose Vertrauen. Systemerweiterungen wie AMDs "Secure Encrypted Virtualization and Secure Nested Paging" (SEV-SNP) und Intels Trusted Domain Extensions (TDX) erlauben, die VMs untereinander und gegen das Hostsystem abzuschotten. Hierbei kommen beispielsweise das Verschlüsseln und das spezielle Verwalten (Reverse-Mapping Tables, Secure Nested Paging) des eigenen Arbeitsspeichers zum Einsatz.

All diese absichernden Maßnahmen drücken die Leistung. Verschlüsseln und zusätzliche Verwaltung kosten Rechenzeit. Bootet ein Betriebssystem, initialisiert es den verfügbaren Speicher. Im Falle einer VM ist das der Speicher, den das Hostsystem der VM aktuell zugesteht. Initialisieren heißt an dieser Stelle, dass die gesamte Verschlüsselungsmaschinerie anläuft. Das dauert seine Zeit und verlängert die Boot-Zeit.

Hätte das Betriebssystem weniger Speicher für den Einsatz klarzumachen, wäre es schneller einsatzbereit. An dieser Stelle setzt das Unified Extensible Firmware Interface (UEFI) in Version 2.9 an. Es führt die Idee des "nicht akzeptierten Speichers" (unacceppted memory) ein. Ein System startet mit dem zugewiesenen Speicher in einem nicht akzeptierten Zustand. Heißt konkret: Es kann den Speicher so lange nicht verwenden, bis es diesen explizit gegenüber dem Hostsystem akzeptiert.

Damit es überhaupt booten kann, akzeptiert (pre-accept) der Bootloader solcher Systeme gerade so viel Speicher, wie der Kernel zum Starten benötigt. Aller weiterer Speicher akzeptiert der Kernel dann Stück für Stück, wenn er gebraucht wird. Das entzerrt das Initialisieren des Speichers, indem es bei Bedarf und nicht auf Vorrat geschieht. Das System ist durch die kürzere Startzeit schneller einsatzbereit.

Speicherakzeptanz

Linux 6.5 kann mit dem Konzept des "unaccepted memory" umgehen. Da das Prozedere zum Akzeptieren des Speichers auf AMD SEV-SNP und Intel TDX unterschiedlich ist, kommen sie in separaten Patches in den Kernel. Wohingegen bei Intel TDX alles nach Friede, Freue, Eierkuchen aussieht, hat AMD SEV-SNP ein "Problem". SEV-SNP hat auf Linux eine bestehende Nutzerbasis; TDX nicht.

Wohingegen TDX praktisch auf der grünen Wiese beginnen kann, muss ein zusätzlicher Patch für SEV-SNP für Kompatibilität sorgen. SEV-SNP unterstützt Linux seit Kernel 5.19. Bislang kennen diese Kernel den Prozess zum Akzeptieren von Speicher aber nicht. Auf einem neuen Hostsystem mit "unaccepted memory" würden diese Systeme zwar Speicher zugewiesen erhalten, könnten diesen aber nicht verwenden. Jeder Zugriffsversuch auf den nicht akzeptieren Speicherbereich seitens des Gastsystems würde als unberechtigt mit einem Fault quittiert. Die alten Systeme wären auf einem neuen Host praktisch nicht lauffähig.

Daher hat Linux 6.5 einen zusätzlichen Mechanismus im Gepäck. Der zusätzliche "Kompatibilitätspatch" steuert ein spezielles UEFI-Protokoll bei. Das bootende Gastsystem muss dieses Protokoll ausführen, um explizit auf den "unaccepted memory" umzuschalten. Erfolgt das nicht – wie bei alten Kerneln – akzeptiert die Firmware automatisch den gesamten zugewiesenen Speicher. Die "neue Welt" muss also explizit eingeschaltet werden. Es gibt sie nur auf Anforderung.

Altlast vorprogrammiert

Diese "Krücke" ist als temporär deklariert und sollte ein Verfallsdatum erhalten. Das Protokoll sollte spätestens dann aus dem Kernel verschwinden, wenn der letzte LTS-Kernel ohne "unaccepted memory"-Mechanismus außer Dienst gestellt wird.

Das wirft gleich zwei Probleme auf. Einerseits gibt es genügend Upstream-Kernel in der freien Wildbahn, die zwar SEV-SNP beherrschen, aber nicht von "unaccepted memory" verstehen. Das Ermitteln eines konkretes Datum ist schwierig, wann diese Kernel eingemottet werden. Andererseits werden keine archivierten Altsysteme ab diesem Tag x mehr reaktiviert werden können. Im Zuge von revisorischen und gesetzlichen Vorgaben ist dies aber in gewissen Situationen und Branchen notwendig. Zeithorizonte von 10 oder 20 Jahren nach Außerdienststellung der jeweiligen Lösung sind keine Seltenheit.

Eine Möglichkeit wäre es, den alten Kerneln mittels Backport "unaccepted memory" beizubringen. Doch auch das scheint auf breiter Front in den Augen einiger Kernel-Entwickler ein illusorisches Unterfangen zu sein. Faktisch wird dieses "Provisorium" lange oder auf immer erhalten bleiben. Das ist ähnlich wie bei x86-Prozessoren, die noch heute im Real-Mode aufwachen. Erst durch Umschalten in den Protected Mode lassen sie die 1980er Jahre hinter sich und sind für mehr als MS-DOS oder CP/M-86 offen.

Dauerbaustelle Rust

Typisch für die Kernel-Entwicklung legte sich das Entwicklerteam beim Einführen von Rust mit Linux 6.1 eine unterstützte Rust-Version fest. Die Wahl fiel auf die damals bereits ältere Version 1.62.0. Linux 6.5 bringt das erste Update von Rust im Mainline-Kernel mit sich. Zukünftig ist 1.68.2 das Rust der Wahl [1], welches am 28. März dieses Jahres erschien.

Die Entscheidung ist wieder konservativ. Aktuell ist Rust 1.72.0, welches am vergangenen Donnerstag [2] erschien. Notwendig machten diesen Versionswechsel benötigte Rust-Features, die die alte Version bisher nicht bot.

Die Änderungen an der Rust-Integration beschränken sich hauptsächlich auf Anpassungen durch den Wechsel der Toolchain von Rust 1.62.0 auf 1.68.2. Der aktuelle Kernel stellt damit vorerst die Weichen für den weiteren Ausbau der Rust-Integration. Das eigentliche Programmieren von Kernel-Modulen in Rust bringt er zunächst nicht voran. Er stellt den Unterbau neu auf.

Memory-Leaks verhindern

Ein leidiges Thema in Bezug auf die Programmiersprache C sind Memory-Leaks. Zuvor allozierte Speicherbereiche bleiben als unnutzbares "schwarzes Loch" zurück, wenn keine extra programmierte Freigabe dieser Bereiche erfolgt. Um dem Problem abseits des C-Sprachstandards zu begegnen, bieten die dominierenden Open-Source-Compiler gcc und Clang schon länger passende Erweiterungen an.

Diese Erweiterungen erlauben es, einer Variablen mittels der Schlüsselwörter __attribute__ und __cleanup__ eine "Aufräumfunktion" mit auf den Weg zugeben. Sobald eine Variable ihren Gültigkeitsbereich (Scope) verlässt, sorgt ein Aufruf dieser Funktion für die ordentliche Freigabe der Variablen. Dieses "scope-based" Ressourcen-Management befreit davon, selbst an jeder möglichen Stelle auf die Freigabe zuvor allozierter Spreicherbereiche zu achten.

Stabilitätsgewinn

Das Kernel-Team hat ein Patch-Set von Peter Zijlstra pragmatisch aufgegriffen, der diese Compiler-Erweiterung im Kernel nutzbar macht. Linus Torvalds schaltete sich in das Thema ein und ermutigte Zijlstra, seine Lösung allgemein nutzbar für den Kernel zu machen. Zijlstras ursprünglicher Ansatz zielte zunächst nur auf Locks ab.

Dieser Rückgriff auf die Compiler-Erweiterungen wird den Kernel über kurz oder lang sicherer gegen die "Löcher" im Speicher machen. Diese Leaks sind schließlich im Kernel schwerwiegender als in einer Anwendung. Der Kernel läuft dauerhaft. Eine Anwendung lässt sich beenden, um Leaks freizugeben. Beim Kernel funktioniert das nur durch einen Reboot.

Es ist davon auszugehen, dass die Kernel-Entwicklerinnen und Entwickler dieses neue Feature dankend aufgreifen werden. Schließlich befreit es elegant, eigenen Code für die Freigabe an jeder möglichen Stelle zu bedenken und zu programmieren.

Optimierte Leistung

Auf x86-Systemen kann der Linux-Kernel die CPUs in weiten Teilen parallel online bringen. Bislang war das nur CPU für CPU in Sequenz nacheinander möglich. Der neue parallele Ansatz reduziert die Zeit, die benötigt wird, alle Prozessoren im System zu aktivieren. Der Prozess lässt sich damit maximal auf ein Zehntel verkürzen. Das kommt insbesondere beim Booten von Systemen mit vielen Prozessoren zum Tragen. Auch beim Reaktivieren von CPUs fällt der neue Ansatz positiv auf.

Optimierter Code für den PCIe-Bus sorgt dafür, dass der Kernel weniger Zeit beim Warten auf PCIe-Geräte vertrödelt. Gemäß der PCIe-Spezifikation müssen lediglich Geräte mit Transferrate von über 5 GT/s aktiv ihre Verbindung ins System signalisieren. Im Umkehrschluss sind die langsameren Geräte bis zu 5 GT/s nicht verpflichtet, aktiv ihre Präsenz und Einsatzbereitschaft bekannt zu geben. Der Kernel behandelte bislang beide Fälle identisch. Er wartete bei den langsamen Geräten auf aktive Rückmeldung, die jedoch nicht zwingend kam. Beim System-Resume bedeutete das teils eine Verzögerung um rund eine Minute, bis das System wieder wach und einsatzbereit war. Gemäß PCIe-Spezifikation genügt es jedoch, eine Sekunde zu warten, um ein Gerät als präsent zu erkennen. Das setzt Linux 6.5 für die langsamen Geräte nun um, was die Wartezeit vor allem beim Resume deutlich verkürzen kann.

Hardware-Unterstützung aufgepeppt

Mit Kernel 6.5 macht sich Linux fit für die neueste Generation von Hardware. So bringt es sich für USB4 v2 in Stellung. USB4 v2 erlaubt Transferraten von bis zu 80 Gbps via USB C. Zudem gestattet es auch 120 Gbps in eine Richtung, wobei in Gegenrichtung dann nur 40 Gbps möglich sind.

Als weitere Neuerung schreitet der Ausbau von WiFi 7 in Linux voran. WiFi 7 erlaubt mit der "Multi-Link Operation" (MLO) simultanes Senden und Empfangen von Daten über mehrere Frequenzbänder und Kanäle hinweg. Entsprechende Hardware vorausgesetzt, lassen sich mit MLO Bänder mit 2,4 GHz, 5 GHz und 6 GHz simultan verwenden. Ziel ist es, die Bandbreite durch diese Bündelung zu erhöhen.

Ebenso ist mit MIDI 2.0 die neueste Generation des "Music Instruments Digital Interface" mit an Bord. Selbst der PS/2-Treibercode für Mäuse und Tastaturen erfuhr eine Runderneuerung.

Zusammengefasst

Linux 6.5 baut die Hardware-Unterstützung aus. Zudem zieht es einige Register zur Optimierung und Verbesserung der Stabilität. Das Entscheidende findet unter der Oberfläche statt. Es mag wie ein Wartungs-Release erscheinen, stellt aber intern viele Weichen für die Zukunft.

Ein erster prominenter Nutzer des neuen Kernels steht bereits fest. Canonical hat bekannt gegeben [3], seiner kommenden Distribution Ubuntu 23.10 "Mantic Minotaur" den neuen Linux-Kernel 6.5 mit auf den Weg zu geben.

Der neue Kernel steht wie gewohnt unter www.kernel.org zum Download bereit. Alle Änderungen sind im ChangeLog [4] nachzulesen.

Zuletzt erschien Linux-Kernel 6.4 zum Ende Juni [5]. Er brachte erste Unterstützung für Apples M2-Prozessoren sowie bessere Leistung und optimierte Energieaufnahme bei AMD-CPUs mit.

(dmk [6])

URL dieses Artikels:
https://www.heise.de/-9289506

Links in diesem Artikel:
[1] https://blog.rust-lang.org/2023/03/28/Rust-1.68.2.html
[2] https://blog.rust-lang.org/2023/08/24/Rust-1.72.0.html
[3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release/36896
[4] https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5
[5] https://www.heise.de/news/Linux-6-4-mit-fruehem-Support-fuer-Apple-M2-erschienen-9200498.html
[6] mailto:dmk@heise.de

Copyright © 2023 Heise Medien