Die neue Versionsnummer des Linux-Kernels wirkt wie ein kleiner Paukenschlag. Wir schreiben nun eine 7.0. Das hat jedoch weniger mit einem großen architekturellen Wurf oder den neuen Features zu tun. Linus Torvalds ist dafür bekannt, große Zahlen hinter dem Punkt einer Versionsnummer nicht sonderlich zu mögen. Daher erfolgt dieses Mal wieder ein Sprung auf ein neues Major-Release, nur der besseren Nummerierung wegen.

Wüsste man es jedoch nicht besser, ließen einige Features in Linux 7.0 durchaus an einen Major-Release-würdigen Sprung glauben. Immerhin verspricht der Neue im Kernel-Reigen selbstheilende Dateisysteme, robusten Code beim Allokieren von Speicher und Rust als offizielles – nicht experimentelles – Feature.

Rust bleibt

Das Projekt „Rust für Linux“ hat einen wichtigen Meilenstein erreicht. Wie Maintainer Miguel Ojeda in einem Commit zum Entwicklungszweig von Linux 7.0 festhält, gilt die Integration der Programmiersprache Rust nicht länger als experimentell. Wörtlich heißt es, Rust sei „here to stay“. Diese Einschätzung wird auch von Linus Torvalds und anderen Kernel-Entwicklern getragen.

Entsprechend wurde der Status der Rust-Unterstützung im Kernel angepasst. In der Konfigurationsoberfläche (menuconfig) wird Rust nicht mehr als experimentelles Feature geführt. Damit ist die Sprache formal im Mainline-Kernel etabliert.

Rust war erstmals 2022 mit Linux 6.1 in den Kernel aufgenommen worden. Zu diesem Zeitpunkt beschränkte sich die Unterstützung im Wesentlichen auf ein einfaches Beispielmodul für ein „Hello, world!“. Seither wurde die Infrastruktur kontinuierlich erweitert, etwa im Bereich von Treibern und Kernel-Schnittstellen.

Weiterer Ausbau nötig

Ungeachtet dieses Fortschritts befindet sich die Rust-Integration weiterhin im Ausbau. Zahlreiche Subsysteme bieten bislang nur eingeschränkte oder noch keine Rust-Schnittstellen. Entsprechend ist auch in kommenden Kernel-Versionen mit weiteren Anpassungen und Erweiterungen zu rechnen.

Parallel dazu wird Rust bereits in anderen Bereichen des Linux-Ökosystems eingesetzt, etwa im Android-Umfeld. Die Entwicklung im Mainline-Kernel ist damit Teil eines übergeordneten Trends hin zu speichersicheren Programmiersprachen in systemnaher Software.

Mit dem Auszug aus dem Experimentellen will Ojeda auch ein Zeichen setzen. Investitionen in Rust stünden auf gesichertem Fundament. Insbesondere Aufwände in das Training von Kernel-Entwicklern zu Rust sollen eine sichere Anlage sein. Ein wenig Exot bleibt Rust dennoch. Den jeweiligen Maintainern bleibt es freigestellt, Rust aus ihren Subsystemen im Kernel herauszuhalten.

XFS: Selbstüberwachung statt Reparaturwerkzeug

Mit der Einführung des „autonomous self-healing support“ entwickelt sich XFS konzeptionell weiter: weg von einem rein reaktiven Dateisystem hin zu einer Architektur, die Fehler früh erkennt und automatisiert darauf reagieren kann. Dabei geht es weniger um „Selbstheilung“ im engeren Sinne als um eine intelligente Aufgabenteilung zwischen Kernel und User-Space. Es ist also kein Feenstaub im Spiel.

Traditionell erfolgt die Fehlerbehebung bei XFS über Werkzeuge wie xfs_repair. Dieses starten Administratoren manuell und typischerweise dann, wenn bereits ein Problem aufgetreten ist – etwa nach einem Absturz oder bei erkannten Inkonsistenzen im Dateisystem.

Der Ablauf ist dabei klar strukturiert, aber auch schwergewichtig: Zunächst muss das Dateisystem ausgehängt werden, also offline gehen. Es folgt eine vollständige Analyse des Dateisystems. Abschließend erfolgt die Reparatur aller gefundenen Fehler.

Dieses Vorgehen ist zuverlässig, bringt aber klare Nachteile mit sich: Es verursacht Downtime, reagiert erst spät auf Probleme und ist bei großen Speichersystemen zeitaufwendig.

Ereignisbasierte Selbstüberwachung

Der neue „Selbstheilungsmechanismus“ verfolgt einen grundlegend anderen Ansatz. Anstatt Fehler erst im Nachhinein zu beheben, erkennt der Kernel Probleme bereits während des laufenden Betriebs und meldet sie an den User-Space. Dabei gilt ein wichtiges Prinzip: Der Kernel erkennt und meldet. Die Entscheidung, was zu tun ist, trifft jedoch der User-Space.

Technisch geschieht das über ein Ereignissystem, beispielsweise mittels File Deskriptor und ioctl. Über dieses erhalten spezialisierte Programme kontinuierlich Informationen über den Zustand des Dateisystems.

Dämonen im User-Space

Ein zentraler Bestandteil dieser Architektur ist ein User-Space-Dienst (Healer Daemon). Dieser bewertet eingehende Ereignisse und entscheidet, welche Maßnahmen sinnvoll sind. Typische Reaktionen könnten der Start eines gezielten Scrubbing-Prozesses, das Anstoßen einer Teilreparatur oder der Neustart betroffener Anwendungen oder Container sein. Auch die Eskalation an Monitoring- oder Alerting-Systeme wäre eine Option.

Dadurch wird die Fehlerbehandlung deutlich flexibler und kontextabhängig. Das verspricht einen entscheidenden Vorteil gegenüber starren Kernel-Mechanismen.

Der Unterschied zwischen dem klassischen und dem neuen Ansatz lässt sich auf eine grundlegende Verschiebung reduzieren: proaktiv statt reaktiv. Früher reagierte das System auf bereits eingetretene Schäden. Der neue Ansatz hingegen setzt auf Früherkennung und automatisiertes Reagieren. Während xfs_repair eher als „Notfallwerkzeug“ dient, versteht sich der Self-Healing-Ansatz als kontinuierliches Überwachungs- und Reaktionssystem im Hintergrund.

Bedeutung für moderne Systeme

Diese Entwicklung ist besonders relevant für moderne IT-Umgebungen wie Cloud-Infrastrukturen, Container-Plattformen wie Kubernetes und große, hochverfügbare Speichersysteme. In solchen Szenarien ist eine Downtime mindestens teuer, wenn nicht gar inakzeptabel. Systeme müssen in der Lage sein, Probleme selbstständig zu erkennen und möglichst ohne menschliches Eingreifen beheben zu können.

Der neue Self-Healing-Support in XFS ersetzt klassische Reparaturwerkzeuge zwar (noch) nicht, ergänzt sie aber sinnvoll. Während Werkzeuge wie xfs_repair weiterhin für schwerwiegende Fälle notwendig bleiben, ermöglicht die neue Architektur eine deutlich frühere und feinere Reaktion auf Probleme. Damit mausert sich XFS zu einem Dateisystem, das nicht nur Daten verwaltet, sondern aktiv zur Stabilität des Gesamtsystems beiträgt.

Typsicherheit für alte API

Mit Linux 7.0 erfährt eine der zentralsten Schnittstellen des Kernels eine grundlegende Modernisierung: kmalloc(). Dabei handelt es sich nicht um eine komplette Neuentwicklung der Speicherverwaltung, sondern um eine gezielte Weiterentwicklung für robusteren Code. Typische Fehlerquellen in der C-Programmierung sollen systematisch vermieden werden.

Es ist ein altbekanntes Problem. Traditionell arbeitet kmalloc() größenbasiert: Entwickler geben explizit an, wie viele Bytes reserviert werden sollen. Zumeist kommen Konstrukte wie sizeof(...) zum Einsatz. Diese Flexibilität hat jedoch ihren Preis. Fehler wie die Verwendung von sizeof(ptr) statt sizeof(*ptr) sind syntaktisch korrekt, führen aber zu kleinen Allokationen. Die Folgen zur Laufzeit sind potenziell schwerwiegend. Wenn der Speicherbereich zu klein ist für die aufzunehmenden Daten, überschreiben diese andere. Ein klassischer Überlauf (Overflow) ist die Folge. Solche Bugs gehören seit Jahrzehnten zu den klassischen Problemfeldern im Kernel.

Objektbasierte Allokation

Linux 7.0 führt daher eine Reihe neuer Makros ein, darunter kmalloc_obj() und kmalloc_objs(). Statt die Größe manuell zu berechnen, beschreibt der Entwickler direkt den gewünschten Objekttyp. Die benötigte Speichergröße wird automatisch abgeleitet. Gleichzeitig stellt der Compiler sicher, dass Rückgabetyp und Zielvariable zusammenpassen.

Dieser Wechsel von einer größenorientierten zu einer typbasierten Denkweise erhöht nicht nur die Lesbarkeit des Codes, sondern erkennt Fehler bereits zur Compile-Zeit.

Ein weiterer Fortschritt betrifft Strukturen mit flexiblem Array am Ende. Ein häufig verwendetes Muster im Kernel. Mit kmalloc_flex() steht im neuen Kernel ein spezialisiertes Makro zur Verfügung, das die korrekte Gesamtgröße solcher Objekte automatisch berechnet. In Kombination mit modernen Compiler-Erweiterungen wie __counted_by() lässt sich sogar die zugehörige Längenangabe passend setzen. Dadurch werden Inkonsistenzen zwischen Speichergröße und Metadaten deutlich reduziert.

Weniger Boilerplate, mehr Sicherheit

Neben der Typsicherheit wurde auch die Bedienung verfeinert. In vielen Fällen kann das bislang obligatorische Allokations-Flag GFP_KERNEL entfallen, da es implizit angenommen wird. Das reduziert redundanten Code und macht typische Allokationen kompakter und übersichtlicher.

Die Einführung der neuen Makros blieb nicht auf neue Codepfade beschränkt. Große Teile des bestehenden Kernels wurden damit automatisiert angepasst. Die Änderung ist damit weniger ein punktuelles Feature als vielmehr eine breit angelegte Qualitätsverbesserung der gesamten Codebasis.

Die Überarbeitung von kmalloc() in Linux 7.0 ist ein typisches Beispiel für evolutionäre Kernel-Entwicklung. Statt neue Funktionalität zu schaffen, wird die bestehende Infrastruktur sicherer und klarer gestaltet. Durch typsichere Makros, bessere Unterstützung komplexer Datenstrukturen und reduzierte Fehleranfälligkeit trägt die Neuerung maßgeblich zur langfristigen Stabilität und Wartbarkeit des Linux-Kernels bei.

Ruhe in Frieden, Laptop-Mode

Der neue Sprössling der Linux-Kernel mottet den Laptop-Mode ein. Diesen Modus erhielt der Kernel in Version 2.4 (als Backport, offiziell kam er in 2.6.6 dazu). Er holte über die Jahre so manches Wättstündchen mehr aus dem Akku des Laptops heraus. Damit ist nun Schluss.

Der Laptop Mode im Linux-Kernel ist eine Energiesparfunktion, die vor allem für Systeme mit mechanischen Festplatten entwickelt wurde. Dabei werden Schreibzugriffe auf den Datenträger gezielt verzögert und gebündelt, sodass die Festplatte seltener aktiviert werden muss und länger im stromsparenden Ruhezustand bleiben kann. Technisch geschieht dies durch Anpassungen im Writeback-Verhalten des Kernels (steuerbar über /proc/sys/vm/laptop_mode). Der Nachteil ist ein erhöhtes Risiko von Datenverlust bei Abstürzen, da Daten länger im RAM verbleiben.

Auf modernen Systemen mit SSDs spielt der Laptop Mode kaum noch eine Rolle. Da auch die Zeiten von intern verbauten mechanischen Festplatten bei modernen Notebooks vorbei sind, fällt der Laptop-Mode aus dem Kernel heraus. Zu aufwendig ist das stetige Nachziehen im Code für ein nicht mehr zeitgemäßes Feature.

SELinux hält eBPF im Zaum

Die Integration von eBPF in das Sicherheitsmodell von SELinux erweitert die bislang primär technische Absicherung durch den Verifier um eine umfassende Zugriffskontrolle. Im Linux Kernel wird damit nicht mehr nur geprüft, ob ein eBPF-Programm sicher ist, sondern auch, ob ein Prozess es gemäß definierter Richtlinien überhaupt nutzen darf.

Kern der Erweiterung ist die Einbindung von eBPF in das Mandatory-Access-Control-Modell. Prozesse benötigen explizite Berechtigungen, um Programme zu laden, an Kernel-Hooks anzuhängen oder mit bestehenden BPF-Objekten zu interagieren. Gleichzeitig können Programme, Maps und andere eBPF-Strukturen mit eigenen Sicherheitskontexten versehen werden, wodurch sich Zugriffe und Datenflüsse gezielt einschränken lassen.

Diese Kombination aus Verifier und SELinux schafft ein zweistufiges Sicherheitskonzept: Während der Verifier die Korrektheit von Programmen sicherstellt, kontrolliert SELinux deren zulässige Verwendung. Dadurch wird eBPF deutlich besser in bestehende Sicherheitsarchitekturen integriert und für den Einsatz in sicherheitskritischen Umgebungen geeignet.

Zusammengefasst

Der neue Kernel bietet wieder viele neue Treiber und Unterstützung von neuer Hardware. Auch gibt es viele Detailverbesserungen, beispielsweise bei eBPF und Rust. Allein durch das Self-Healing bei XFS und das verbesserte kmalloc() rangiert der neue Kernel nicht mehr als reines „Wartungsrelease“. Damit wird er auch abseits der „Phobie“ vor langen Nummern von Linus Torvalds einem Release-Sprung auf 7.0 gerecht.

Alle Änderungen im neuen Kernel finden sich im ChangeLog. Linux 7.0 steht wie üblich unter www.kernel.org zum Download bereit. Die Entwicklung an Kernel 7.0 startet Linus Torvalds zwei Wochen, nachdem der Kernel 6.19 Anfang Februar 2026 das Licht der Welt erblickte.

(dmk)