Linux 6.5 mit zahlreichen Optimierungen erschienen

Inhaltsverzeichnis

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.