Rust ist jetzt offiziell im Linux-Kernel – und Speichersicherheit wird zur Sicherheitspolitik

Die folgenreichste Sicherheitsverbesserung in der Computergeschichte könnte kein neues Authentifizierungsschema, eine intelligentere Firewall oder ein besseres Erkennungssystem sein. Es könnte die Änderung der Programmiersprache sein, in der Betriebssysteme geschrieben werden.

Speichersicherheitslücken – Use-After-Free-Fehler, Pufferüberläufe, Nullzeiger-Dereferenzierungen, Integer-Überläufe, die zu Pufferüberläufen werden – machen seit Jahren etwa 70 % der hochriskanten CVEs von Microsoft aus. Google meldet ähnliche Zahlen für Chrome und Android. Die NSA hat Leitlinien veröffentlicht, die besagen, dass etwa 70 % aller ausnutzbaren Softwareschwachstellen Speichersicherheitsprobleme sind. Dies sind keine obskuren Randfälle – sie sind die häufigste Klasse ausnutzbarer Schwachstellen und sind seit vierzig Jahren häufig, weil der meiste Betriebssystemcode in C und C++ geschrieben ist, Sprachen, die es leicht machen, speicherunsicheren Code zu schreiben und schwer, die Fehler zu erkennen, bis etwas in der Produktion abstürzt.

Rust eliminiert die gesamte Kategorie. Nicht durch Hinzufügen eines Laufzeit-Garbage-Collectors – Go und Java verfolgen diesen Ansatz, und er kostet Leistung, die sich Betriebssysteme nicht leisten können. Stattdessen verwendet Rust einen Compilezeit-Borrow-Checker, der die Ownership und Lebenszeiten jedes Speicherstücks zur Build-Zeit verfolgt. Wenn Sie Code schreiben, der einen Use-After-Free-Fehler erzeugen könnte, weigert sich der Rust-Compiler, ihn zu kompilieren. Der Speicherfehler tritt zur Laufzeit nicht auf. Er scheitert zur Build-Zeit mit einer Fehlermeldung, die genau sagt, was falsch ist. Kein Absturz, kein CVE, kein Patch-Zyklus, kein notfallmäßiger Hotfix, der um 3 Uhr morgens ausgerollt wird.

Der Linux-Kernel-Meilenstein

Der Linux-Kernel ist die Grundlage von Android, der meisten Cloud-Infrastruktur und einer Vielzahl eingebetteter Systeme. Er ist fast vollständig in C geschrieben – etwa 27 Millionen Codezeilen, die über dreißig Jahre angesammelt wurden. Das Hinzufügen einer neuen Programmiersprache zu einer so alten und kritischen Codebasis ist eine Entscheidung, die Jahre der Validierung erfordert, bevor sie zur offiziellen Politik wird.

Der erste Rust-Code wurde mit der Version 6.8 im Dezember 2023 in den Linux-Kernel integriert. Die ersten Implementierungen umfassten den Asahi GPU-Treiber (der Apple M1- und M2-Macs unter Linux unterstützt) und einige NVMe-Treiberinfrastrukturen – Bereiche, in denen neue Entwicklungen stattfanden und das Risiko, bestehende Funktionalität zu brechen, minimiert war. Dies war ein Proof-of-Concept, dass Rust innerhalb der strengen Kernel-Beschränkungen arbeiten und mit der bestehenden C-Codebasis koexistieren kann.

Im Dezember 2025 erklärte das Linux-Kernel-Projekt offiziell, dass Rust im Kernel nicht mehr experimentell ist. Die Kernel-Entwicklung in Rust ist jetzt ein offizieller Teil des Kernel-Entwicklungsprozesses, mit denselben Stabilitätsgarantien, Testanforderungen und Code-Review-Standards wie die C-Entwicklung. Neue Kernel-Subsysteme können in Rust geschrieben werden, mit der Zuversicht, dass Rust langfristig eine unterstützte Kernel-Sprache bleibt – eine Zusage, die zuvor nicht gemacht werden konnte, weil die experimentelle Bezeichnung bedeutete, dass die Rust-Kernel-Infrastruktur entfernt werden konnte, wenn es nicht funktionierte.

Dies ist aus mehreren Gründen praktisch bedeutsam. Treiberentwickler können neue Treiber in Rust schreiben, ohne Unsicherheit darüber, ob die Rust-Kernel-Infrastruktur in der nächsten Kernel-Version existieren wird. Sicherheitskritische Kernel-Komponenten – Netzwerk-Stacks, Dateisystemtreiber, kryptografische Subsysteme – können im Laufe der Zeit systematisch in Rust neu geschrieben werden, wodurch die Angriffsfläche von Code reduziert wird, der derzeit mit Ring-0-Privilegien läuft und nicht vertrauenswürdige externe Eingaben verarbeitet. Und es signalisiert der breiteren Systemprogrammiergemeinschaft, dass Rust eine ernsthafte langfristige Wahl für Kernel-Arbeit ist, was Einstellungs-, Schulungs- und Tool-Investitionsentscheidungen in der gesamten Branche beeinflusst.

Rust-Übernahme bei Android und Ergebnisse

Google begann 2021 mit dem Hinzufügen von Rust zu Android und war am transparentesten bei der Messung der Ergebnisse. Bis 2024 berichtete Google, dass etwa 77 % des neuen Android-Codes in Rust geschrieben sind – eine Zahl, die neu zur Plattform hinzugefügten Code widerspiegelt, nicht die bestehende C- und C++-Codebasis, die weitgehend wie geschrieben bleibt und weiterhin gewartet wird.

Die messbare Sicherheitsauswirkung ist signifikant. Die Rate der in Android entdeckten Speichersicherheitslücken ist seit 2019 Jahr für Jahr gesunken, dem gleichen Zeitraum, in dem die Rust-Übernahme begann. Google führt dies direkt auf die Sprachwahl zurück: Rust-Code, der in Android läuft, produziert nicht im gleichen Maße Speichersicherheits-CVEs wie C-Code, weil der Compiler die gesamte Fehlerklasse verhindert, bevor der Code ausgeliefert wird.

Androids Bluetooth-Stack, Teile des Netzwerk-Stacks und Komponenten der Media-Codec-Infrastruktur wurden in Rust neu geschrieben. Dies sind genau die Angriffsflächen, die historisch betrachtet hochriskante Schwachstellen produziert haben – sie verarbeiten nicht vertrauenswürdige externe Eingaben (Bluetooth-Pairing-Pakete, Netzwerkdaten, Videodateien aus nicht vertrauenswürdigen Quellen) mit komplexer Parsing-Logik, wo ein einziger Off-by-One-Fehler zu einer Remote-Code-Execution-Schwachstelle werden kann, die ohne Benutzerinteraktion ausnutzbar ist.

Microsofts Ansatz

Microsofts Übernahme speichersicherer Sprachen verteilt sich auf mehrere Initiativen, anstatt ein zentrales Mandat zu sein. Das Windows-Kernel-Team evaluiert Rust für die Entwicklung neuer Kernel-Treiber, und Microsoft beteiligt sich aktiv am Rust for Windows-Projekt, das Rust-Bindungen an Windows-APIs bereitstellt. Die Azure-Infrastruktur hat Rust in mehreren Komponenten übernommen. Microsofts Hyperlight-Projekt – ein leichtgewichtiger Hypervisor für die Ausführung serverloser Funktionen in großem Maßstab – wurde von Grund auf in Rust gebaut.

Im weiteren Sinne hat Microsoft sich verpflichtet, neuen sicherheitskritischen Code in speichersicheren Sprachen zu schreiben (dazu gehören Rust, Go und C# neben den älteren sicheren Sprachen Swift und Java) und bestehenden C- und C++-Code systematisch in speichersichere Alternativen umzuschreiben, wo das Sicherheitsrisiko die Ingenieurskosten rechtfertigt. Dies ist kein Befehl "Alles in Rust umschreiben" – es ist ein risikopriorisierter Ansatz, der speichersichere Neuschreibungen auf Code konzentriert, der externe Eingaben verarbeitet und mit erhöhten Privilegien läuft, was genau der Punkt ist, an dem Speicherfehler in ausnutzbare Schwachstellen übersetzt werden.

Die wirklichen Herausforderungen

Rusts Speichersicherheitsgarantien kommen mit echten Kompromissen, die für die praktische Übernahme wichtig sind:

Die Lernkurve ist steil. Der Borrow-Checker erzwingt Ownership-Regeln, die sich für Entwickler, die von C, C++ oder den meisten anderen Sprachen kommen, ungewohnt anfühlen. "Den Borrow-Checker bekämpfen" ist eine häufige Frustration für Rust-Neulinge. Google schätzt, dass es sechs Monate bis ein Jahr dauert, bis ein erfahrener C-Entwickler in einer großen Codebasis wirklich produktiv in Rust wird. Im großen Maßstab ist dies eine erhebliche Investition in Schulung und Rekrutierung.

Interoperabilität mit C ist notwendig, aber komplex. Jede realistische Migrationsstrategie beinhaltet Rust, das C aufruft, und C, das Rust aufruft – das Überschreiten der FFI-Grenze zwischen den beiden Sprachen. Diese Grenze erfordert unsafe Rust-Blöcke, die dieselben Speicherfehler einführen können, die Rust verhindert. Das korrekte Einrichten von FFI-Grenzen erfordert sorgfältige Ingenieurarbeit, und jeder unsafe-Block muss sorgfältig überprüft werden.

Kompilierzeiten sind länger. Die Analyse des Borrow-Checkers ist rechenintensiv. Große Rust-Codebasen kompilieren deutlich langsamer als äquivalente C-Codebasen, was die Entwickler-Iterationsgeschwindigkeit und CI/CD-Pipeline-Zeiten beeinflusst. Dies ist ein bekanntes Problem, an dem das Rust-Team aktiv arbeitet, aber es bleibt eine echte Kostenbelastung.

Die bestehende Codebase wird nicht schnell verschwinden. Der Linux-Kernel besteht aus 27 Millionen Zeilen C. Die schrittweise Migration zu Rust wird viele Jahre dauern, und der bestehende C-Code wird während dieses Übergangs weiterhin Speichersicherheitslücken produzieren. Die Hinwendung zu speichersicheren Sprachen ist strukturell und generationell – sie verhindert neue Schwachstellen in neuem Code, nicht bestehende Fehler in vorhandenem Code.

Die politische Dimension

Die bedeutendste jüngste Entwicklung ist kein technischer Meilenstein – es ist der Wandel von technischer Empfehlung zu Sicherheitspolitik. CISA, die NSA und ihre Five Eyes-Pendants haben alle formelle Leitlinien veröffentlicht, die besagen, dass Softwareentwickler die Verantwortung haben, speichersichere Sprachen für neuen sicherheitskritischen Code zu verwenden. Die nationale Cybersicherheitsstrategie des Weißen Hauses verweist explizit auf Speichersicherheit. Dieser Rahmen verändert die Gleichung für Organisationen, die Software schreiben, die sensible Daten oder kritische Infrastruktur verarbeitet.

Es ist nicht länger eine rein technische Entscheidung. Es ist eine Frage, ob eine Organisation ihre Sprachwahl gegenüber Regulierungsbehörden, Prüfern und Kunden verteidigen kann. Die Kombination aus technischer Reife – Rusts Werkzeuge, Ökosystem und Dokumentation haben sich seit 2021 dramatisch verbessert – und formalem politischem Druck beschleunigt die Übernahme über das hinaus, was der rein technische Fall allein bewirken würde.

Speichersicherheit ist ein gelöstes Problem in der Programmiersprachentheorie. Sie zum praktischen Standard in der Betriebssysteminfrastruktur zu machen, ist ein generationelles Ingenieurprojekt. Der Linux-Kernel-Meilenstein, die Übernahmekennzahlen von Android und der politische Wandel deuten alle darauf hin, dass dieses Projekt von einer akademischen Übung zur Ingenieursrealität übergegangen ist – langsam, mit rauen Kanten und auf einer Zeitskala, die in Jahrzehnten statt in Produktzyklen gemessen wird. Die Richtung ist klar, und die Dynamik ist real.