Linux 5.9: Neue Kernel-Version schließt Lizenzlücke und unterstützt FSGSBASE
Im Vergleich zur Vorgängerversion als Update "normalen" Umfangs geplant, wartet Linux 5.9 nun doch mit zahlreichen Neuerungen und Richtungsentscheidungen auf.
(Bild: Ludwig Winklhofer / Wikimedia Commons / CC BY-SA 2.0 DE)
Nach dem extrem umfangreichen Update auf Linux 5.8 hatte Linus Torvalds beim ersten Release-Candidate (rc1) von 5.9 ein "normales" Update in Aussicht gestellt. Es kam anders: Als die Entwickler in rc7 immer noch etliche Änderungen einreichten, verlängerte Torvalds die Entwicklungsphase für 5.9 kurzerhand um eine weitere Woche und einen weiteren Release-Candidate.
Eine Vielzahl der Commits machen in 5.9 neue und verbesserte Treiber aus. Mit der endgültigen Beseitigung einer Lizenzlücke und der nun fertig gestellten FSGSBASE-Unterstützung finden sich aber auch ein paar "Hingucker". Unter der Haube wartet das neue Release mit Verbesserungen beim Echtzeit-Scheduling auf asymmetrischen CPU-Konfigurationen, bei der Speicherverwaltung und bei der Thread-Priorisierung auf.
Lizenzlücke geschlossen
Ladbare Kernel-Module mussten auch bislang schon klar ausweisen, ob sie Closed-Source sind oder als quelloffener Code unter der GNU General Public License (GPL) stehen. Da GPL-Module expliziten Zugriff auf "GPL-only-Symbole" im Kernel haben, was proprietären Modulen verweigert ist, wurde in der Vergangenheit allerdings oft geschummelt. Insbesondere nutzten findige Entwickler eine Designlücke im Kernel aus: GPL-Module konnten bislang von proprietären Modulen abhängen. Statt das proprietäre Modul unter die GPL zu stellen, nutzten die betreffenden Entwickler deshalb einfach ein GPL-konformes, quelloffenes Verbindungsmodul als Kitt und Übersetzer zwischen Kernel und proprietärem Modul.
Linux 5.9 schließt diese Lücke, über die in jüngster Vergangenheit etwa Jonathan Lemon von Facebook versuchte hatte, aus Performance-Gründen ein "GPL-Adaptermodul" zwischen proprietärem Nvidia-Treiber und dem NetGPU-Core zu basteln. Ein Vorfall, der zur Entscheidung der Kernel-Entwickler beigetragen haben dürfte.
FSGSBASE endlich einsatzbereit
Linux 5.9 bringt eine zuvor unendliche scheinende Geschichte zu Ende: Die neue Version unterstützt die Intel-Befehle der FSGSBASE-Familie. FSGSBASE fasst einige CPU-Befehle zusammen, die zum direkten Lesen und Setzen der Segmentregister FS und GS dienen. Was wie ein kleines unbedeutendes Detail klingt, setzt tief im System an und öffnet neue Horizonte für Linux auf x86_64 und sichere Anwendungsszenarien.
Zum Hintergrund: Häufig nutzen Threads das FS-Register, um ihren Thread-lokalen Speicher zu adressieren. Jeder Thread hat einen eigenen FS-Wert und kann so transparent seinen eigenen Speicher ansprechen. Der Thread muss sich nicht darum kümmern, wo der Speicherbereich tatsächlich liegt: Er wendet seine Offsets auf die (indirekte) Adresse im FS-Register an. Ähnlich verhält es sich mit dem GS-Register, das der Linux-Kernel nutzt, um Daten pro CPU zu verwalten.
Das Verändern von Segmentregistern ist privilegiertem Code im Kernel-Space vorbehalten. Will der User-Space die Werte für FS oder GS ändern, erfordert dies Umwege (Syscalls und damit verbundene Context-Switches), die auf die Performance drücken. Was beim einmaligen Setzen des FS-Registers für einen Thread in Summe wenig ins Gewicht fällt, kann in modernen Anwendungsszenarien zum Bremsklotz avancieren. Intel führte daher 2012 mit der dritten Generation seiner Core-Prozessoren (Codename "Ivy Bridge") die FSGSBASE-Instructions ein. Sie ermöglichen das direkte Ändern von FS und GS aus dem User-Space. Die Syscall-Bremse entfällt damit. Allerdings muss der Kernel hierzu explizit ein spezielles Bit setzen, um die Instructions zu aktivieren.
Der Kernel ist darauf angewiesen, dass die Register FS und GS beim Eintritt in den Kernel-Space korrekt gesetzt sind. Insbesondere eine Änderung von GS könnte fatale Folgen nach sich ziehen. Schließlich ließen sich auf diesem Wege CPUs falsche Daten unterschieben und Angriffsszenarien konstruieren. Den Kernel für FSGSBASE fit zu machen, war daher ein langer Prozess: Intel hatte von 2012 bis 2019 Patches in sieben Versionen eingereicht, die ihren Weg nicht in die Praxis fanden.
SGX sauber implementiert
Der in Linux 5.9 verfügbare FSGSBASE-Support kommt auch SGX-Projekten wie etwa dem prominenten, von Intel unterstützten Projekt Graphene zugute.
Intels Software Guard Extension (SGX) ermöglicht das Erstellen von Enklaven. Diese Enklaven sind Speicherbereiche, die durch die CPU mittels transparenter Verschlüsselung und Integritätsschutz abgeriegelt werden. Selbst privilegierte Prozesse können durch die CPU daran gehindert werden, auf diese Enklaven zuzugreifen. SGX erlaubt somit, Code selbst auf einem bereits kompromittierten System unbeeinflusst und sicher ausführen zu können.
SGX-Projekte sind auf einen performanten Weg zum Setzen von FS und GS (aus dem Userspace) angewiesen. Bislang lud Graphene quasi als "Notlösung" ein eigenes kleines Kernelmodul, das FSGSBASE aktivierte. Solche Sonderwege sind mit Sicherheitsrisiken behaftet – und künftig zum Glück nicht mehr nötig: Dank des vom Kernel-Team bereitgestellten offiziellen FSGSBASE-Supports können SGX-Systeme künftig sicher, performant und vor allem kontrolliert implementiert werden.
Flexible IP-Port-Kombinationen
Der Berkeley Packet Filter (BPF) führt in Linux 5.9 einen neuen Programmtyp mit der Bezeichnung BPF_PROG_TYPE_SK_LOOKUP ein. Solche Programme werden ausgeführt, wenn ein Transport-Layer einen Lookup auf ein LISTEN-Socket ausführt. Dies ist bei einem neuen Connection-Request via TCP oder beim Eintreffen eines UDP-Pakets für ein unverbundenes Socket der Fall. Über das BPF-Programm kann in diesem Fall flexibel gesteuert werden, wer wann welches Paket erhält.
BPF hebt damit Beschränkungen der alten bind()-API auf und lässt flexiblere IP- und Port-Kombinationen zu. Ein mögliches Anwendungsszenario sind beispielsweise Sockets, die für eine IP-Adresse statt an einem einzigen Port, an einem Portbereich oder gar alle Ports lauschen. Ein weiterer Anwendungsfall sind Services auf verschiedenen IP-Adressen, die sich einen Port teilen. Aufgrund der Port-Bindung von bind() sind solche Konstellationen dort sonst nicht zulässig.
ZSTD-Kompression
Neu ist die Möglichkeit, ZSTD (Zstandard) zur Kompression für Kernel und initrd (initramfs) zu verwenden. ZSTD zeichnet sich durch hohe Kompressionsraten und sehr schnelle Dekompression aus. Letzteres kann den Bootprozess deutlich beschleunigen.
Die Kernel-Entwickler geben als Referenz Zahlen von Facebook an: Als das Unternehmen von einer mit xz komprimierten initrd zu einer mit ZSTD komprimierten umgestiegen sei, konnte die Dekompressionszeit beim Booten von zwölf auf drei Sekunden gesenkt werden. Das Umstellen des komprimierten Kernel-Images von xz auf ZSTD habe dem Unternehmen gemäß Kernel-Team zwei Sekunden Bootzeit eingespart.
Asymmetrie und Echtzeit-Scheduling
Der deadline-Scheduler für Echtzeitaufgaben ist dank eines Patchs des Entwicklers Dietmar Eggemann in Linux 5.9 für asymmetrische CPU-Konfigurationen tauglich.
Anders als der POSIX-realtime-Scheduler, welcher anhand von Prioritätsstufen Tasks CPU-Zeit zuweist, arbeitet der deadline-Scheduler nicht mit Prioritäten. Stattdessen bewertet er einen Task anhand seiner benötigten Laufzeit, der Aktivierungsperiode und anhand der "Deadline"; der Zeitspanne also innerhalb der die Task abgeschlossen sein soll. Anhand dieser Werte kann der Kernel bestimmen, welcher Task wann CPU benötigt.
Problemlos klappte dies bislang nur bei symmetrischen CPU-Konfigurationen. Asymmetrische Konfigurationen, die verschieden leistungsstarke CPUs in einem System vereinen, brachten den deadline-Scheduler in Stresssituationen allerdings zum Stolpern. Mit der neuen Version hat sich dies geändert: Der Scheduler weiß nun mit solchen Konfigurationen umzugehen.
Kapazitätsbasiertes Scheduling
Der Patch von Eggemann führt ein kapazitätsbasiertes Berechnungsmodell ein: Statt eine homogene CPU-Kapazität für die "Deadline" als Berechnungsgrundlage heranzuziehen, gehen nun die tatsächlich vorhandenen und womöglich unterschiedlichen CPU-Kapazitäten in die Rechnung ein. Damit können auch auf einem asymmetrischen System die "Deadlines" korrekt bestimmt und die Tasks passgenau verteilt werden.
Die neue Lösung setzt jedoch voraus, dass mindestens eine CPU nicht mit dem Ausführen von Deadline-Tasks betraut ist. Andernfalls kann die Task-Verteilung immer noch aus dem Ruder laufen, da dann zum eigentlichen Berechnen der Verteilung womöglich nicht mehr ausreichend CPU-Kapazitäten zur Verfügung stehen. Dieses Problem von High-Performance- und Hochlast-Systemen wollen die Entwickler zu einem späteren Zeitpunkt adressieren.
Ebenso ist für die Zukunft eine Lösung angedacht, um das Überfrachten von starken CPUs mit kleinen Tasks zu vermeiden. Dies kann dazu führen, dass es zu einer Art "Fragmentierung" der CPU-Kapazitäten kommt. Ein größerer Task könnte so keine CPU finden, die innerhalb der Deadline die notwendigen Rechenkapazitäten liefern kann. Auch hierfür sind Lösungen angedacht, aber noch nicht implementiert.
Neues bei den Dateisystemen
Der neue Linux-Kernel unterstützt nun erweiterte Dateisystemattribute (xattr) über NFS (Network File System) v4.2 gemäß RFC 8276. btrfs wartet mit kleineren Verbesserungen auf. Hervorzuheben ist hier die Mount-Option rescue, durch die sich Mount-Optionen für den Recovery-Fall gruppieren lassen.
Das Dateisystem XFS verfügt nun über ein asynchrones Inode-Flushing. Das Memory-Reclaiming kann somit nicht mehr vom Inode-Flushing blockiert werden. Der Quota-Code wurde von einem langjährigen Bug befreit, der ein korrektes Tracking der Soft- und Inode-Limits verhinderte. Außerdem wurde das Zusammenspiel beim Direct Access (DAX) zwischen ext4 und XFS verbessert und stabilisiert.
Neue Treiber und Altlasten
Linux 5.9 wappnet sich bei AMD-Grafik für die neue RDNA-2-Architektur und Big Navi. Die neuen GPUs Sienna Cichlid und Navy Flounder finden im neuen Kernel Unterstützung. Im Umfeld von Intel i915 ist der erste Treiber für die "Rocket Lake"-Architektur mit von der Partie.
Die Unterstützung für die chinesische CPU-Architektur Unicore32 wurde hingegen gestrichen. Der Port wurde schon lange Zeit nicht mehr gewartet; zudem ist keine Toolchain mehr verfügbar, um Linux für Unicore32 überhaupt noch zu bauen. Wie schon länger angekündigt, wurde außerdem die Unterstützung von Paravirtualization (PV) für 32-Bit-Gäste unter Xen eingestellt. Als Alternativen können jedoch HVM (Hardware-assisted virtualization) und der PVH-Modus (Paravirtualization Hardware) zum Einsatz kommen.
Fazit und Ausblick
Linux 5.9 stellt im Vergleich zu seinem eher evolutionär getriebenen Vorgänger vor allem wichtige Weichen für die Zukunft. Die FSGSBASE-Ankunft nach einer langen und zähen Odyssee wird künftig der Sicherheit des Betriebssystems zugutekommen, da sich selbstgestrickte Notlösungen damit erübrigen. Und das klare "Nein" gegenüber Tricks und Schummeleien zum Umgehen der GPL wurde nun in Code umgesetzt, was die Inkonsequenz zwischen lizenzrechtlich gewolltem und technisch möglichen endlich aufhebt.
(ovw)