- Auf der Android-Plattform ist der Anteil der Speichersicherheitslücken nach der Einführung von Rust auf unter 20 % des Gesamtaufkommens gesunken, wodurch sich Sicherheit und Entwicklungseffizienz gleichzeitig verbessert haben
- Rust-Code weist im Vergleich zu C/C++ eine 1000-fach geringere Dichte an Speichersicherheitslücken auf, dazu eine 4-fach niedrigere Rollback-Rate und 25 % kürzere Code-Review-Zeiten
- Die Ausweitung des Rust-Einsatzes erstreckt sich auf Kernel, Firmware und 1st-Party-Apps und trägt damit zu einem höheren grundlegenden Sicherheitsniveau im gesamten System bei
- Am Beispiel des in CrabbyAVIF entdeckten ersten Beinahefalls einer Rust-basierten Speichersicherheitslücke wurde die Bedeutung des Scudo-Allocators und von Schulungen für sicheren
unsafe-Code bestätigt
- Der Wechsel zu Rust wird als neues Paradigma der Softwareentwicklung bewertet, das gleichzeitig mehr Sicherheit und höhere Entwicklungsgeschwindigkeit erreicht
Auswirkungen der Rust-Einführung und Daten für 2025
- 2025 ist der Anteil der Speichersicherheitslücken in Android auf unter 20 % gesunken, was die Wirksamkeit der sicherheitsorientierten Rust-Strategie belegt
- Rust erreicht gegenüber C/C++ eine 1000-fach geringere Dichte an Speichersicherheitslücken, eine 4-fach niedrigere Rollback-Rate und 25 % kürzere Code-Review-Zeiten
- Die Einführung von Rust geht über eine reine Sicherheitsverbesserung hinaus und führt auch zu schnellerer Softwarebereitstellung
- Die Daten umfassen Änderungen an 1st-Party- und 3rd-Party-Code über C, C++, Java, Kotlin und Rust innerhalb der Android-Plattform hinweg
Wechsel der Systemprogrammiersprache und Entwicklungsproduktivität
- Android hat Rust als Alternative zu C/C++ für die Systemprogrammierung übernommen und reduziert bei vergleichbarem Kontrollniveau die Risiken
- Bezogen auf 1st-Party-Code hat das Wachstum von Rust-Code C++ überholt, wodurch ein Vergleich der Entwicklungskennzahlen zwischen beiden Sprachen möglich wurde
- Mit dem DORA-Framework werden Throughput und Stability gemessen
- Der Vergleich erfolgte unter Kontrolle von Codegröße, Entwicklerpool und zeitlichen Trends bei Rust und C++
Throughput: Effizientere Code-Reviews
- Rust-Code benötigt im Vergleich zu C++ 20 % weniger Überarbeitungen (Revisions) und die Code-Review-Zeit ist 25 % kürzer
- Zwischen 2023 und 2024 hat sich die Review-Effizienz durch steigende Rust-Expertise deutlich verbessert
- Weniger Reviews und Nacharbeit steigern die Produktivität, wobei die verbesserte Stabilität den größten Effektfaktor darstellt
Stability: Weniger Rollbacks und höhere Qualität
- Nach DORA-Maßstäben ist die Rollback-Rate von Rust etwa 4-mal niedriger als bei C++, besonders bei mittelgroßen und großen Änderungen
- Die niedrigere Rollback-Rate trägt direkt zur Produktivität bei, da Nebenkosten wie erneute Build-Arbeit, Postmortems und blockierte Teams sinken
- Auch in einer Google-Entwicklerumfrage von 2022 wurde Rust als leicht zu reviewen und präziser bewertet
- Die Daten stützen diese Wahrnehmung empirisch
Gleichzeitige Verbesserung von Sicherheit und Produktivität
- Früher führte stärkere Sicherheit oft zu Leistungseinbußen oder langsameren Entwicklungszyklen, doch der Wechsel zu Rust verbessert Sicherheit und Effizienz gleichzeitig
- Mit Rust entsteht eine Struktur, in der sich Sicherheit, Entwicklungseffizienz und Produktstabilität gemeinsam verbessern
Bereiche der Rust-Ausweitung
- Kernel: Im Linux-Kernel von Android 6.12 wurden Rust-Unterstützung und der erste Rust-Treiber eingeführt
- In Zusammenarbeit mit Arm und Collabora wird derzeit ein GPU-Treiber auf Rust-Basis entwickelt
- Firmware: Durch die Einführung von Rust wird die Sicherheit in hochprivilegierten und eingeschränkten Umgebungen gestärkt; dazu wurden Tutorials, Schulungen und Code veröffentlicht
- Gemeinsam mit Arm läuft das Projekt Rusted Firmware-A
- 1st-Party-Apps:
- Nearby Presence: Ein Bluetooth-basiertes Protokoll zur Geräteerkennung wurde in Rust implementiert und läuft in Google Play Services
- MLS: Ein Sicherheitsprotokoll für RCS-Messaging wurde in Rust implementiert und soll künftig in die Google-Messages-App aufgenommen werden
- Chromium: PNG-, JSON- und Webfont-Parser wurden durch Rust ersetzt, wodurch sich die Einhaltung der Rule of 2 erleichtert
Erster Beinahefall einer Rust-basierten Speichersicherheitslücke
- In CrabbyAVIF wurde kurz vor dem Release eine Buffer-Overflow-Schwachstelle (CVE-2025-48530) entdeckt und noch vor der Veröffentlichung behoben
- Der gehärtete Scudo-Allocator machte die Schwachstelle dank Guard Pages nicht ausnutzbar (non-exploitable)
- Scudo wird auf Geräten wie dem Pixel bereits standardmäßig verwendet, und bei Partnerunternehmen wird eine verpflichtende Einführung vorangetrieben
- Durch verbessertes Crash-Reporting wurden Signale zur Overflow-Erkennung klarer
Stärkere Kontrolle von unsafe-Code und mehr Schulung
- Für die OS-Entwicklung ist unsafe-Code (C/C++ oder
unsafe Rust) unvermeidbar
- Google hat dem Comprehensive-Rust-Kurs ein vertiefendes Modul zu unsafe-Code hinzugefügt
- Behandelt werden unter anderem Soundness von unsafe-Code, undefiniertes Verhalten, Sicherheitskommentare und Techniken für sichere Abstraktionen
- Ein besseres Verständnis von unsafe Rust führt zu höherer Codequalität in Android und im gesamten Open-Source-Ökosystem
Vergleich der Lückendichte
- In rund 5 Millionen Zeilen Android-Rust-Code wurde 1 potenzielle Schwachstelle gefunden → Rust-Lückendichte 0,2/MLOC
- Der historische Durchschnitt von C/C++ liegt bei 1.000/MLOC, also mehr als 1000-mal höher
- Die geringere Dichte an Speichersicherheitslücken stärkt die Wirksamkeit der gesamten Sicherheitsarchitektur
- Etwa 4 % des Rust-Codes bestehen aus
unsafe{}-Blöcken, doch laut Daten ist die Fehlerwahrscheinlichkeit niedriger als bei C/C++
- Als Gründe werden unter anderem beibehaltene Sicherheitsprüfungen, Kapselung und zusätzliche verstärkte Prüfungen genannt
Fazit
- Früher waren zur Absicherung kostenintensive Maßnahmen wie statische Analyse, Sandboxing und Patches nötig
- Der Wechsel zu Rust ist ein neuer Ansatz, der Sicherheit und Effizienz gleichzeitig sicherstellt
- Statt „schnell entwickeln und später reparieren“ beginnt nun eine Phase des „schnell entwickeln und gleichzeitig reparieren“
- Je stärker die Sicherheit wird, desto größer wird auch das Potenzial zur Wiedergewinnung von Leistung und Produktivität
Dank
- Es werden zahlreiche Beitragende für die Analyse von CVE-2025-48530, Verbesserungen an Scudo, die Entwicklung von Schulungen zu unsafe Rust und die Bereitstellung von Informationen zur Rust-Nutzung erwähnt
- Dank gilt auch dem Android-Rust-Team und der gesamten Android-Organisation für ihre kontinuierlichen Bemühungen um Qualitätsverbesserung
3 Kommentare
Es lebe Rust!
Ich habe ein wenig mit der Firmware-Entwicklung mit Embassy herumprobiert.
Die sprachliche Sicherheit ist zwar gut, aber ... weil das Tooling so hervorragend ist, ist die Produktivität im Vergleich zu der Zeit, als ich C/C++ verwendet habe, überwältigend höher.
Hacker-News-Kommentare
In 5 Millionen Zeilen Rust-Code wurde nur eine einzige Speichersicherheitslücke gefunden.
Das heißt, Rust kommt auf 0,2 Schwachstellen pro Million Zeilen.
C/C++ liegt dagegen bei etwa 1.000 pro Million Zeilen, der Unterschied ist also überwältigend.
Aber angesichts solcher klaren Daten ist schwer zu verstehen, warum das weiterhin ignoriert wird.
Ich selbst habe Rust noch nicht benutzt, will es aber irgendwann unbedingt lernen.
Sicherheit ist wichtig, aber Deployments ohne Rollback sind das, was Entwickler wirklich wollen.
Mit Rust scheint man genau dieses Gefühl von Stabilität zu bekommen.
Solche Innovationen sind in der Informatik wirklich selten.
2025 gibt es kaum noch einen Grund, C++ zu verwenden, außer bestehende Codebases zu pflegen.
Alles Neue sollte in Rust entstehen.
Neue Projekte starten nun einmal mit modernen Testsystemen und klaren Zielen.
Trotzdem lässt sich kaum bestreiten, dass Rust gegenüber C++ die mental gesündere Sprache ist.
Rust zu lernen war wirklich schmerzhaft, deutlich komplexer als andere Sprachen.
Aber wenn man ein paar Mal mit dem Compiler gerungen hat, entsteht das Vertrauen, dass der Code beim Laufen fast keine Probleme mehr macht.
Wenn man von Ruby, JS/TS oder Python zu Rust wechselt, fühlt es sich an wie: „Wenn es kompiliert, ist es zu 80–90 % fertig.“
Und dazu ist es schnell.
Der Kampf mit dem Compiler ist in Wahrheit der Prozess, versteckte Bugs schon im Voraus zu beheben.
Die Denkweise von Rust übernimmt irgendwann den eigenen Kopf.
Der Witz ist, dass es ebenso leicht zu vergessen wie wieder neu zu lernen ist.
Bei Ruby, JS und Python stimme ich zu, aber TS ist aus meiner Sicht etwas anders.
Google unterstützt Rust im Android-Userspace offiziell noch nicht.
NDK und Android Studio unterstützen weiterhin nur C/C++.
Wer Rust einsetzen will, muss die Tools selbst in der Community bauen.
Ohne Code auf der JVM-Seite ist es schwer, Apps zu bauen.
.so-Dateien bauen und in das NDK einbinden.Die ABI von Android ist sprachunabhängig, solange man sich an die Regeln hält.
Das ist ein Ereignis wie eine Bombe, die C++ versenkt.
Jetzt wird es schwerer, sich mit Ausreden wie „Rust ist auch unsafe“ oder „C++ ist sicher, wenn man es richtig benutzt“ herauszureden.
Sicheren Code zu schreiben ist lästig, aber wenn man einmal durch ist, hat man selbst in Multithread-Umgebungen Vertrauen.
Ich würde Android-Apps gern auch in Rust schreiben.
Ich freue mich einfach, dass es mehr Möglichkeiten gibt, sichere Systemwerkzeuge zu bauen.
Die Industriestandards sind weiterhin stark auf C/C++ ausgerichtet, deshalb wird Rust es schwer haben, alles vollständig zu ersetzen.
Dass sich die Rollback-Rate um den Faktor 4 unterscheidet, ist schockierend.
Die meisten anderen Zahlen entsprachen in etwa dem, was man ohnehin erwarten würde, aber das ist neu.
Das bedeutet weniger, dass Rust besonders perfekt ist, sondern eher, dass im bestehenden Code so viele Bugs stecken.
Dass solche Daten aus einer großen Codebase kommen, ist beeindruckend.
Wenn man von Beginn an auf Modulebene ein Akzeptanztestsystem aufsetzt, kann man einen Teil der Prüfungen, die Rust übernimmt, durch Tests ersetzen.
Damit lassen sich nicht nur Speicherlecks, sondern auch Performance-Einbrüche überwachen.
könnte es einfach ein Unterschied im Risiko alter Codebestände sein.
Ein Freund hat ein Rust-Rewrite-Projekt übernommen und dazu gewitzelt,
„Damit sind die Gehälter für die nächsten drei Jahre gesichert.“
Eine halb scherzhafte Strategie nach dem Muster Rewrite → Speichersicherheit herstellen → gesicherter Gehaltskreislauf.
Während der Rust-Compiler langsam kompiliert, kann man in Ruhe den alten Code lesen und entspannt arbeiten.
Diese Daten kontrollieren Störvariablen nicht.
In der Regel sind Rewrites Code, den man bereits gut versteht, deshalb gehen Reviews schneller und es gibt weniger Rollbacks.
Komplexer Legacy-Code braucht dagegen längere Reviews und führt häufiger zu Rollbacks.
Wenn nur einfacher Code neu geschrieben worden wäre, hätte sich die Rate an Speichersicherheitslücken anders dargestellt.
Tatsächlich werden eher problematische Teile bevorzugt in Rust neu geschrieben.
Es ist kein perfektes Experiment, aber es ist plausibler, das als realen Effekt zu betrachten.
Eine Analyse der Rewrite-Größe anhand gelöschter Zeilen wäre noch interessanter.
desto eher entsteht paradoxerweise eine leichter neu zu schreibende Umgebung.
Ich glaube an die Vorteile von Rust, aber ich sehe das eher als starke empirische Evidenz denn als wissenschaftlichen Beweis.
Mich würde interessieren, welchen Einfluss die Einführung von Rust künftig auch auf nicht speichersicherheitsbezogene Bugs haben wird.
Ich nutze Rust für Spieleentwicklung (nicht mit Bevy).
Wegen der Stabilität und des Durchsatzes habe ich nicht vor, zu einer anderen Sprache zurückzukehren.
Mich würde interessieren, welche crate-Kombination und welche Architektur dafür verwendet werden.
Ich bastle auch hobbymäßig an Spielen und fand Bevy etwas überdimensioniert.
Für mich fühlt es sich so an, als hätte Rust inzwischen selbst in zentralem Systemcode ausreichend Fuß gefasst.
Es ist kein uphill battle mehr.
„Schreibt es in Rust neu“ ist nicht länger nur ein Meme, sondern wird zunehmend mit realen Belegen unterfüttert.
sind 80 % der Kommentare immer noch von Rust-Hassern geprägt.
Es kommen stets dieselben Behauptungen wie „C++ ist auch sicher, wenn man es richtig benutzt“ oder „Rust hat auch Bugs“.
Diese uninformierte Kritik ist inzwischen weniger lustig als vielmehr traurig.
Es auf alles anwenden zu wollen, wäre aber übertrieben.
Das Ownership-Modell von Rust bremst die Entwicklungsgeschwindigkeit, und auch die Sprache selbst entwickelt sich noch weiter.
Bei Services mit hoher Netzwerklatenz sind Python oder Node womöglich effizienter.
Rust ist also hervorragend, aber nicht die Antwort auf jedes Problem.