Drei Fragen und Antworten: Was die Rust-Zukunft für Linux bringt

Mit Linux 6.1 hielt Rust Einzug in den Kernel. Doch außer einem simplen „Hello, World!“ bietet die erste Beispielimplementierung nichts – und das mit Absicht, denn um Module nicht mehr nur in C programmieren zu können, ist noch einiges an Rust-Integration nötig. iX sprach mit Miguel Ojeda, Betreuer des Projekts, über den Stand und die Zukunft von Rust für Linux.

Im Interview: Miguel Ojeda

Miguel Ojeda ist Softwareengineer und Betreuer des Rust-für-Linux-Projekts. Ferner ist er Teil des ISO-C-Komitees und interessiert sich für undefiniertes Verhalten und Themen der Speichersicherheit.

Zum Start ist der Rust-Support in Linux experimentell. Welche Features wollt ihr als Nächstes anpacken?

Unser primäres Ziel ist es momentan, genügend Abstraktionen in den Haupt-Branch zu bringen, damit später erste Rust-Treiber im Kernel darauf aufbauen können. Diese Abstraktionen packen Kernel-Subsysteme in sichere APIs, damit Rust-Treiber so weit wie möglich in sicherem Rust geschrieben werden können.

Die ersten Treiber und die ihnen zugrundeliegenden Abstraktionen, die den Weg in den Kernel-Haupt-Branch finden werden, sind wahrscheinlich die GPU-Treiber für Asahi Linux, Androids Binder und die NVMe-Treiber. All diese sind nicht trivial und werden als Vorbild für kommende Rust-Kernel-Abstraktionen und -Treiber dienen. Dabei müssen wir auch sicherstellen, dass die relevanten Kernel-Betreuer so weit wie möglich eingebunden sind, zum Beispiel durch Code-Reviews und Kommentare. Dass sie also den Code durch ihren Tree nehmen, und so weiter.

Außerdem sind viele Infrastrukturverbesserungen in Arbeit, darunter ein besseres Build-System für Rust-Code im Kernel und eine weitere Integration in die Testing- und Dokumentationssysteme des Kernels. Zudem hat ARM begonnen, Code für die Rust-Unterstützung der AArch64-Architektur für die Übernahme in den Haupt-Branch des Linux-Kernels einzureichen, basierend auf unserem prototypischen Support für Rust für Linux.

Es sind auch sehr interessante neue Tools in der Entwicklung, darunter klint: Es nutzt den Rust-Compiler als Bibliothek, um zusätzliche statische Codeanalysen im Rust-Kernel-Code durchzuführen. Einer der ersten Tests, an denen wir arbeiten, stellt sicher, dass Rust-Code die Kernel-Locking-Regeln einhält, indem der Preemption Count bereits zur Übersetzungszeit geprüft wird. Auch bei der Toolchain arbeiten wir an Verbesserungen: Hierunter fallen der Kernel-CFI-Support im Rust-Compiler, Security-Compiler-Flags, potenziell bessere Unterstützung für Rust in pahole und einiges mehr.

Aber vielleicht am interessantesten für den Einsatz von Rust außerhalb des Kernels sind die Vorschläge zum Verbessern der Sprache, Bibliothek und des Tooling, die aus dem Projekt heraus entstanden sind. Besonders bemerkenswert ist der Field Projection RFC, der den Zugriff auf Felder spezifischer Wrapper-Typen auf ergonomische und sichere Weise vereinfachen soll.

Manche Nutzer beschweren sich darüber, dass es zu langsam vorangeht. Welchen ungewöhnlichen Herausforderungen muss sich das Projekt stellen?

Ich weiß nicht, auf welche Nutzer sich die Frage bezieht – aber einige Leute vertreten die Ansicht, dass es andersherum wäre! So sind wir manchen zu voreilig. Vielleicht haben sie den Eindruck, dass Rust als Sprache und Toolchain noch zu jung und unreif sei.

Es hängt also davon ab, wen man fragt. Wir als Projekt glauben, dass wir vorsichtig sein sollten bei dem Code, den wir in den Kernel einbringen. Vor allem braucht es Zeit, damit der Code genug Reviews durchlaufen hat und die Kernel-Betreuer ihn guten Gewissens akzeptieren können. Außerdem sind viele Details noch zu diskutieren und zu entscheiden – und jetzt ist es an der Zeit, das innerhalb des Kernels in Angriff zu nehmen.

Dieser Prozess dauert, aber bereits im Kernel zu sein, bietet uns auch weitere Vorteile. So werden jetzt Unternehmen, andere Projekte, potenzielle Nutzer und Entwickler anfangen, sich Rust im Kernel näher anzusehen – und das wird die Unterstützung verbessern, die wir erhalten. Tatsächlich spüren wir genau das bereits jetzt!

Was Herausforderungen betrifft – da mussten wir uns natürlich einigen stellen. Eine wichtige war, dass wir beweisen mussten, dass es tatsächlich möglich ist, Abstraktionen mit sicherem Rust-Code rund um existierende Kernel-Funktionen zu erstellen, also ohne alles in Rust neu schreiben zu müssen und ohne die Performance zu beeinträchtigen. Das alles zu koordinieren war für mich persönlich eine Herausforderung, die ich aber auch genossen habe – dank der Leute, die am Projekt arbeiten, und der Firmen, die ebenfalls einen Beitrag leisten.

Sobald es mit dem Rust-Support in Linux wirklich losgeht: Welche Vorteile winken Kernel-Entwicklern und Linux-Nutzern?

Für Endanwender und Unternehmen gibt es einen klaren Vorteil: die Zahl der Schwachstellen zu reduzieren. Mehrere Studien großer Firmen und Software-Projekte zeigen, dass etwa 70 Prozent der Sicherheitslücken auf Speichersicherheitsprobleme der C/C++-Codebasis zurückgehen. Wenn wir also den Großteil dieser Probleme eliminieren und den Schweregrad der Schwachstellen reduzieren können, bedeutet das hoffentlich eine verbesserte Security für Endnutzer und weniger dringende Kernel-Updates, die sie einspielen müssen, sowie weniger Sicherheitslücken für Unternehmen.

Für Kernel-Entwickler bietet Rust als Sprache, Bibliothek und Tooling viele moderne Verbesserungen im Vergleich zu C. Das ist nicht überraschend, da Rust auf Basis der Erfahrungen aus der Arbeit mit älteren Programmiersprachen sowie neuesten, wissenschaftlichen Erkenntnissen gestaltet wurde. Unserer Meinung nach wird sich das in insgesamt weniger Logik-Bugs im Kernel niederschlagen, wird aber auch rascheres Debugging und mehr Komfort beim Coding nach sich ziehen. Und all das bedeutet wiederum eine höhere Produktivität für Firmen, die Entwickler für den Kernel beschäftigen, sowie zuverlässigere Treiber für Endanwender. Das unterstreichen auch die Erfahrungen der Entwickler der ersten Rust-Treiber.

Idealerweise können sich Kernel-Betreuer beim Akzeptieren von Patches und Refactoring-Code in ihre Subsysteme sicherer sein – aus denselben Gründen. Falls zum Beispiel ein Patch einen sicheren Rust-Treiber ändert, sollte es auf diese Weise nicht möglich sein, Speicherzugriffsfehler in den Kernel einzubringen. Hier steht mehr auf dem Spiel als im Userspace. Wir glauben, dass diese zusätzliche Schutzschicht in Rust für den Code sehr wertvoll ist.

Zu guter Letzt hoffen wir, dass sich neue und jüngere Generationen mit der Kernel-Entwicklung beschäftigen wird – dank der angesagten Sprache und ihrer Techniken. Im Idealfall wird all das Linux dabei helfen, auch in den kommenden Jahrzehnten der am weitesten eingesetzte Kernel der Welt zu bleiben.

Miguel, vielen Dank für die Antworten. Das Interview führten wir auf Englisch, es findet sich im Original hier. Alle Informationen zu Linux 6.1 und den Arbeiten an 6.2 erfahren Sie in den zugehörigen Artikeln. Den Fortschritt von Rust für Linux können Interessierte auf der Projektseite verfolgen.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(fo)