© Matthew Dixon, 123RF

Statt der 3.20 erhält der nächste Kernel die Versionsnummer 4.0. Die größte Neuerung dürfte das Kernel Live Patching sein, das Downtimes überbrücken soll. Das Bauwerk der Tüftler ist aber umstritten.

Mit überschaubaren Neuerungen erschien am 22. Februar der erste Release Candidate des Linux-Kernels 4.0. Seitdem läuft die Testphase für die nächste Version [1], die aller Voraussicht nach Anfang April erscheint. Mit der neuen Versionsnummer folgt Linus Torvalds seinem 2011 formulierten Plan, die Kernelnummern künftig zu kürzen.

Bei seiner Umfrage auf Google Plus (Abbildung 1, [2]) habe es für die 4.0 eine knappe Stimmenmehrheit von 56 zu 44 Prozent bei rund 30000 Teilnehmern gegeben, erklärte Torvalds auf der Mailingliste [3] und läutete die Testphase ein. Zudem hätten die Kritiker nicht genügend stichhaltige Argumente gegen den Sprung geliefert.

Abbildung 1: Über eine Umfrage bei Google Plus holte Torvalds ein Stimmungsbild in der Linux-Community ein.

Während die Unterstützer der neuen Versionsnummer belustigt darauf hinwiesen, dass in der Science-Fiction-Reihe “Terminator” der Killerroboter T-800 auf dem Linux-Kernel 4.1.15 läuft [4], forderten die Kritiker, Versionsnummern nur dann zu ändern, wenn neue Features ins Spiel kommen.

Ihnen erklärte Torvalds, eine spektakuläre Funktion sei noch nie Grund für einen Versionssprung gewesen und Brüche in der Kompatibilität gebe es beim Kernel ohnehin nicht. Überhaupt würde er nicht zu viel Aufhebens um die Zahl 4.0 machen, sie vereinfache bloß die Zählweise künftiger Linux-Versionen.

Mit etwa 9000 Änderungen im Merge Window ist die Zahl der Neuerungen in Linux 4.0 vergleichsweise klein, im Kernel 3.19 waren es noch 11400. Zudem verzeichnet eine aktuellen Studie der Linux Foundation (siehe Kasten “Jobs für Kernelkenner”) einen Trend, nach dem die Zahl der unabhängigen gegenüber der angestellter Entwickler sinke.

Ohne Unterbrechung

Eine wesentliche Neuerung von Linux 4.0: Es kann im laufenden Betrieb bestimmte Patches einspielen und entfernen. Dazu bringt der Kernel ein Framework mit, das Schnittstellen für Suses Kgraft und Red Hats Kpatch anbietet.

Wie Entwickler Jiri Kosina im Kommentar zum Merge-Commit [5] schreibt, gibt es ein API für die gepatchten Kernelmodule sowie ein Userspace-API und -ABI, um die Patches anzuwenden oder zu deaktivieren. Red Hat und Suse müssen ihre Userspace-Tools noch für den Kernel anpassen, doch einfache Sicherheitspatches lassen sich bereits integrieren.

Security-Theater

Streit gibt es allerdings um die Konsistenz des Ansatzes. Ingo Molnar hat auf der Kernel-Mailingliste die Implementierung und das Design von Kpatch und Kgraft kritisiert. Sie seien “(unfreiwillig) ein verlängerter Arm des Security-Theaters” [6]. Kgraft würde zum Beispiel das Nebeneinander alter und neuer Kernelfunktionen erlauben, Kpatch auf Kernelstack-Backtraces setzen, die nicht für diesen Zweck gedacht und fehlerträchtig seien. Beide Ansätze, so Molnar weiter, würden zudem nicht für komplexe Upgrades funktionieren.

Er möchte lieber “auf den Mond zielen” und Live-Kernelupgrades in Linux integrieren. Dazu müsste der Kernel jedoch in der Lage sein, Usertasks und Kernelthreads zu parken, Systemaufrufe zu unterbrechen und neu zu starten sowie Schnappschüsse vom Status der Tasks und Geräte anzufertigen.

Ein deutlich umfassenderer Ansatz also, der laut Molnar Upgrades von “Kernel 3.20 auf 3.21” in “unter 10 Sekunden” ermögliche. Kgraft-Entwickler Vojtech Pavlik sieht diesen Vorschlag eher skeptisch [7]. Man würde wohl mehr als zehn Jahre brauchen, um so ein System zu erforschen und zu realisieren.

Btr-FS-Reparaturen

Abseits der Hauptattraktion feilen die Entwickler an anderen Komponenten. Die Btr-FS-Macher haben ihr Maintainerteam verstärkt und kümmern sich unter anderem um einen berüchtigten Speicherplatzfehler. Der tritt etwa in Facebooks Rechenzentren auf, wo große Cluster mit Btr-FS im Einsatz sind. Das Dateisystem meldet zu wenig Speicherplatz, obwohl genügend vorhanden ist. Solche “Out of disc space”-Fehlermeldungen nannten kürzlich auch die Core-OS-Entwickler als einen der Gründe, von Btr-FS auf Ext 4 zu wechseln [8].

Leisere Grafikkarten

Auch bei den Grafiktreibern tut sich etwas. Der freie Radeon-Treiber für Grafikkarten von AMD erhält Unterstützung für Audio über den Display-Port. Ventilatoren solcher Grafikkarten sollen künftig leiser laufen. Genauer gesagt passt der Treiber sie beim Betrieb besser an die tatsächliche Hitzeentwicklung an.

Der Carrizo genannte Nachfolger des Kaveri-Chips von AMD erhält erste Unterstützung im »amdkfd« -Treiber. Für Grafikkarten von Intels kommender Skylake-Plattform gibt es erste Codekomponenten, zudem verbessern die Entwickler den Treiber für aktuelle Grafikchips [9]. Nicht zuletzt taktet der freie Nouveau-Treiber für Nvidia-Karten die Kepler-basierten GK20A-Chips optimal.

Besser netzwerken

Über die Routingtabelle und Parameter für »ip route« regulieren Netzwerk-Admins künftig die Auslastung für einzelne Hosts gezielter. Beispiele liefert die Dokumentation, die dem Patch [10] beiliegt. Die für den Einsatz von Linux in Clustern verwendete Transparent Inter-Process Communication (TIPC) unterstützt unter anderem die Group-Policy-Erweiterung von VXLAN. Zudem verwendet sie nun einen Kompatibilitätslayer, der auf ein neues Netlink-API setzt, was die Codekomplexität reduziert.

Der Android-Binder-Code kommt in Android 4.0 mit den Richtlinien von SE Linux und anderen Frameworks zurecht. Das Unsorted Block Image File System (UBIFS) für Flashspeicher dockt dank Extended-Attributes-Support (XATTR) neuerdings an SE Linux an.

Kernel 4.0 unterstützt den TPM-Standard 2.0 (Trusted Platform Module) und TPM erhält eine eigene Geräteklasse [11]. Das Linux-Security-Kernelmodul Smack erweitert Netfilter um Security Markings (»secmark« ), mit denen sich Paket-Datenstrukturen in Iptables oder Netfilter labeln und verfolgen lassen.

Die kommenden Release Candidates von Linux 4.0 stehen wie gewohnt auf Kernel.org [12] bereit.