Von GrapheneOS mit ARM MTE entdeckte Bluetooth-Speicherbeschädigung
(grapheneos.social)- Die Unterstützung für Hardware Memory Tagging im Pixel 8 und Pixel 8 Pro hat einen neu in Android 14 QPR2 eingeführten Speicherbeschädigungsfehler in Bluetooth LE offengelegt
- Als Ursache wurde ein Upstream-Use-after-Free-Bug in Bluetooth LE bestätigt; GrapheneOS hat einen Patch erstellt und will ihn in ein neues Release aufnehmen
- Ein Nutzer, der das Problem im Bluetooth-LE-Modus der Samsung Galaxy Buds2 Pro reproduziert hatte, bestätigte, dass der Fix funktioniert; auch das Stock Pixel OS ist betroffen
- Da Bluetooth eine große Angriffsfläche darstellt, hält GrapheneOS einen Workaround, der Memory Tagging für den betreffenden Prozess deaktiviert, selbst kurzfristig für ungeeignet
- Teile des Android-Bluetooth-Codes wurden nach Rust portiert, doch es sind weitere Portierungen des verbleibenden Codes sowie Tests von HWASan- und MTE-Builds auf echten Geräten nötig
Bluetooth-LE-Bug in Android 14 QPR2 und Fix
- GrapheneOS hat durch die Unterstützung für Hardware Memory Tagging im Pixel 8 und Pixel 8 Pro einen Speicherbeschädigungsfehler in Bluetooth LE unter Android 14 QPR2 entdeckt
- Das Problem tritt nicht bei allen Bluetooth-Geräten auf, sondern lässt sich nur mit bestimmten Bluetooth-LE-Geräten reproduzieren
- GrapheneOS untersucht Möglichkeiten, die neu eingeführte Funktion zu korrigieren oder vorübergehend zu deaktivieren
- Als Ursache wurde ein Upstream-Use-after-Free-Bug in Bluetooth LE bestätigt; GrapheneOS hat einen Patch entwickelt
- Priorität hat die schnelle Bereitstellung eines GrapheneOS-Releases mit diesem Fix
- Der Bug soll als Android-Sicherheitsfehler gemeldet werden
- Der Fix dürfte auch die BLE-Audio-Regression beheben
- Ein Nutzer, der das Problem mit den Samsung Galaxy Buds2 Pro im Bluetooth-LE-Modus reproduzierte, bestätigte, dass der Fix funktioniert
- Dasselbe Problem betrifft auch das Stock Pixel OS
- GrapheneOS hat den Fehler über die Memory-Tagging-Unterstützung von hardened_malloc erkannt und eine MTE-Crash-Benachrichtigung mit kopierbarem Report hinzugefügt
MTE-Einsatz und Herausforderungen im Android-Bluetooth-Code
- GrapheneOS hält einen Workaround, der Memory Tagging in diesem Prozess deaktiviert, selbst kurzfristig nicht für angemessen
- Bluetooth ist unabhängig von der praktischen Ausnutzbarkeit dieses konkreten Bugs eine große Angriffsfläche
- Android hat einen erheblichen Teil des Bluetooth-Codes nach Rust portiert, benötigt aber weitere Ressourcen für die Portierung des verbleibenden Codes
- In realen Umgebungen sind mehr Tests von HWASan- und MTE-Builds mit unterschiedlichen Bluetooth-Geräten nötig
- Pixel-Geräte verfügen mit MTE über eine wichtige Hardware-Sicherheitsfunktion, das Standard-OS aktiviert sie jedoch nicht, mit der Begründung einer Einsparung von 3,125 % bei Speicher- und Cache-Nutzung
- Die Berechnung basiert auf einem 4-Bit-Tag pro 16 Byte getaggtem Speicher
- Heap-MTE hat im asynchronen Modus (async mode) nahezu 0 % Performance-Overhead; im asymmetric mode sind die Kosten niedriger als bei bestehenden Schutzmaßnahmen wie SSP
- GrapheneOS aktiviert MTE standardmäßig für vom Nutzer installierte Apps, deren Kompatibilität mit dem Standard-OS bekannt ist
- Unter Settings > Security kann es per Opt-in für alle vom Nutzer installierten Apps aktiviert werden
- Es bietet eine Benachrichtigung zum Kopieren von Crash-Reports sowie App-spezifische Schalter
- Die MTE-Implementierung von hardened_malloc in GrapheneOS verwendet standardmäßige Zufalls-Tags und ein dediziertes Free-Tag und schließt dynamisch das vorherige Tag sowie aktuelle oder vorherige benachbarte Tags aus
- Die Chromium-Integration wurde korrigiert, und auch PartitionAlloc soll verbessert werden
1 Kommentare
Kommentare auf Hacker News
Es ist schon seltsam, dass Pixels mit MTE ein großes Hardware-Sicherheitsfeature verbaut haben, es im OS aber nicht aktivieren, nur um 3,125 % Speicher-/Cache-Nutzung zu sparen.
Ich würde wirklich gern sehen, wie das Pixel-Team diese Entscheidung rechtfertigt, und mich interessiert der Gedankengang, ein so wichtiges Sicherheitsfeature wegen eines minimalen Performancegewinns abzuschalten.
GrapheneOS ist ein großartiges Projekt, unterstützt aber nur ungefähr 11 Geräte; AOSP-Änderungen müssen ein deutlich größeres OEM-Ökosystem berücksichtigen.
Wir suchen ständig nach Wegen, Android besser zu machen, aber ein bestimmtes Feature-Release zu kritisieren und dabei das größere OEM-Ökosystem auszublenden, wirkt kurzsichtig.
Es ist sehr unwahrscheinlich, dass dieses Feature wegen 3 % Speicher/Cache nicht aktiviert wurde; vermutlich gab es andere Abwägungen.
Bei der Entscheidung, ob man das Feature aktiviert, ist das vermutlich sogar ein größerer Faktor.
Wenn auch andere OS derzeit nicht mit aktiviertem MTE ausgeliefert werden, ist die Entscheidung, ob man es einschaltet, wahrscheinlich deutlich nuancierter.
Leute bei Google haben Hardware-MTE überhaupt erst vorangetrieben, und es entstand in einem Team, das an ASAN, syzkaller usw. beteiligt war.
Es gehörte zwar nicht zum Android-Team, hatte aber Hilfe und Unterstützung von Android-Seite, und natürlich gab es Zusammenarbeit mit ARM und anderen.
Da ich damals diese Teams geleitet habe, kenne ich die Abwägungen gut; es geht nicht nur um Speicher- oder Cache-Probleme.
MTE kann dynamisch ein- und ausgeschaltet werden und wurde tatsächlich so entworfen, dass die Performance-Kosten nahezu bei 0 liegen, aber der damalige Hauptanwendungsfall war Bug-Finding auf Sampling-Basis.
Wenn man es über die gesamte Geräteflotte nur 1 % der Zeit aktiviert, reicht das bei ausreichender Größenordnung, um Bugs sehr schnell zu finden, und es lässt sich auch für interne Tests nutzen.
Das Ziel war also, bei Bedarf ASAN-ähnliche Funktionalität ein- und ausschalten zu können.
Es als dauerhaft aktivierte Sicherheitsmitigation zu nutzen, war eine sekundäre Möglichkeit, und neben dem Speicher-Overhead gibt es weitere Probleme.
Zum Beispiel treten plötzlich viele für Nutzer sichtbare Crashes auf; auf Phones mit MTE crasht etwas, auf Phones ohne MTE nicht, was zudem inkonsistent ist.
Aus Entwicklersicht wäre es ebenfalls wenig erfreulich, wenn es praktisch nur ein Phone mit aktiviertem MTE gibt und man alle zwingen müsste, genau auf diesem Phone zu testen.
Es kann Security-Exploits verhindern und statt Ausnutzung einen Crash auslösen.
Es kann auch harmlose Bugs finden.
Aber wie gesagt würde ich nicht annehmen, dass es nicht genutzt wird; eher scheint richtig zu sein, dass es in Production nicht dauerhaft eingeschaltet ist.
Jemand mit Erfahrung bei der Einführung solcher Hardwarefeatures würde sagen: Allein die Tatsache, dass das System bootet und läuft und nur bei bestimmten Aktionen unter MTE crasht, ist eher ein gutes Zeichen dafür, dass es bereits genutzt wird.
Wäre es nicht genutzt worden, wäre es wahrscheinlich schon eine Million Mal gecrasht.
Außerdem ist nicht klar, ob es als Runtime-Mitigation überhaupt die beste Option ist.
Standard-Pixels werden möglicherweise nicht mit standardmäßig aktivierter Funktion an Endnutzer ausgeliefert, aber wer möchte, kann Memory Tagging Extensions in den Entwickleroptionen aktivieren.
Man kann es eingeschaltet lassen, bis man es wieder deaktiviert, oder nur für eine Session aktivieren, um eine bestimmte App zu testen.
Wenn man im Standard-Pixel-OS die Unterstützung für Memory Tagging in den Entwickleroptionen aktiviert, macht das sie nur verfügbar; tatsächlich genutzt wird sie dadurch noch nicht.
Man muss auch Heap Memory Tagging in einer Android-Debug-Bridge(ADB)-Shell per
setpropeinschalten.Wenn Allokationen nicht getaggt werden, hat es keinerlei Wert, dass es einfach nur aktiviert ist.
Über Scudo, die Standard-Allocator-Implementierung, lässt sich User-Space-Heap-MTE im Standard-OS vollständig aktivieren, aber derzeit ist das keine besonders gehärtete Implementierung.
KASan mit MTE-Backend kann ebenfalls per
setpropgenutzt werden, ist derzeit aber nicht als Hardening gedacht, und es ist unklar, ob es das künftig sein wird.Der Kernel braucht wahrscheinlich eine eigenständige MTE-Implementierung statt nur Teile von KASan; GrapheneOS hat das ebenfalls noch nicht umgesetzt, daher ist MTE-Hardening derzeit ein User-Space-Feature.
GrapheneOS verwendet für hardened_malloc eine eigene Implementierung von Hardware Memory Tagging mit stärkeren Sicherheitseigenschaften.
Um es im Standard-OS standardmäßig zu aktivieren, mussten mehrere Probleme, einschließlich dieses Issues, behoben oder umgangen werden.
Statt asynchrones MTE auf den Main-Cores zu verwenden, wird auf allen Cores der asymmetrische Modus genutzt.
Der asymmetrische Modus ist bei Writes asynchron und bei Reads synchron, sodass kein Zeitfenster für eine erfolgreiche Ausnutzung bleibt und sie korrekt blockiert wird.
Bei Systemaufrufen wird geprüft; und io_uring, das ein weiterer Umgehungsweg sein könnte, ist unter Android durch SELinux-Beschränkungen nur für zwei zentrale Systemprozesse erlaubt.
fastbootd wird nur während der Installation verwendet, und snapuserd wird nach dem Anwenden von Updates im Kern-OS genutzt.
GrapheneOS verwendet Heap-MTE immer für Apps, deren Kompatibilität mit dem Standard-OS bestätigt ist.
Für vom Nutzer installierte Apps, die nicht in der Kompatibilitätsdatenbank stehen und sich nicht selbst als kompatibel markieren, gibt es einen MTE-Schalter pro App.
Nutzer können MTE auch standardmäßig für vom Nutzer installierte Apps erzwingen und nur inkompatible Apps ausnehmen.
Damit das in der Praxis nutzbar ist, brauchte es ein für Nutzer sichtbares Crash-Reporting-System, und es wurde so umgesetzt, dass sich für Entwickler hilfreiche Crash-Reports leicht kopieren und versenden lassen.
Wenn man in den Einstellungen nach Memory Tagging Extensions sucht, wird es angezeigt; ich dachte, es sei irgendwo versteckt, aber es war nur für Pixel-8-Phones: https://news.ycombinator.com/item?id=38125379
GrapheneOS ist in puncto Sicherheit allem anderen so weit voraus, dass man sich fragt, warum man überhaupt etwas anderes als Pixel-Hardware wählen sollte
Aber ich möchte wirklich einen austauschbaren Akku
Ich weiß nicht, warum heutzutage alles so mies ist
Andere Android-Geräte kommen nicht einmal in die Nähe
Unterstützung für Hardware Memory Tagging ist einer von mehreren großen Sicherheitsvorteilen der Pixel-Geräte
Die offizielle Liste der Hardwareanforderungen ist hier: https://grapheneos.org/faq#future-devices
Diese Anforderungen werden ab der 8. Pixel-Generation vollständig erfüllt
Bei Pixel-Geräten der 6./7. Generation fehlen nur MTE, BTI und PAC, wobei MTE die wertvollste Funktion auf der Liste der Hardwareanforderungen ist
Korrekte Sicherheits-Patches sind wichtiger und werden außerhalb von Pixel nicht auf dieselbe Weise bereitgestellt
Android hat monatliche, vierteljährliche und jährliche Releases
Andere Android-OEMs liefern von den monatlichen Sicherheits-Backports nur alle Fixes mit Critical/High-Schweregrad aus und lassen die meisten Fixes mit Moderate/Low-Schweregrad, einschließlich der meisten Datenschutz-Fixes, größtenteils weg
Wenn man solche Patches mit einem alternativen OS bereitstellt, wird das teilweise abgemildert, aber alternative OS für diese Geräte drehen die Sicherheit oft auf mehrere Arten zurück
Firmware und ein großer Teil des Geräte-Support-Codes stammen tatsächlich vom OEM
Android 14 QPR2 auf einem Android-12-Kernel samt Treibern laufen zu lassen, ist möglich, aber dann fehlen Sicherheitsverbesserungen für große Teile des OS
Pixel-Akkus sind zwar nicht einfach zu tauschen, ohne das Gerät zu beschädigen, aber der Austausch wird offiziell unterstützt und es gibt offizielle Teile: https://www.ifixit.com/Device/Google_Pixel
Wir können keine unsicheren Geräte unterstützen, die nicht einmal die Grundlagen erfüllen
Unsere Liste der Hardwareanforderungen enthält sowohl sehr grundlegende Dinge, die die meisten Android-OEMs nicht bieten, als auch fortgeschrittene Funktionen wie MTE, die wir inzwischen als Grundanforderung für angemessene Sicherheit ansehen
Wir würden gern auch andere Geräte unterstützen, aber diese Geräte müssen diese Anforderungen erfüllen
Memory Tagging ist eine grundlegende Funktion, die von Standard-Cortex-ARMv9-Kernen unterstützt wird
Es ist bedauerlich, dass Qualcomm sie nicht implementiert und dass auch OEMs, die SoCs mit Unterstützung dafür nutzen, sie nicht konfigurieren
Es ist traurig, wenn die CPU-Architektur eine Funktion hat, die man wegen des SoC oder des OEM nicht nutzen kann
Zum Glück soll das Pixel 8 immerhin 7 Jahre unterstützt werden
Apple und Samsung sind auch schwer zu vertrauen, und Google ist noch die beste Option geworden
Es wäre gut, wenn jemand antworten könnte, der GrapheneOS nutzt
Allerdings war ich kürzlich mit meiner Frau in Orlando, Florida, bei Disney World und den Universal Studios; mit den sandboxed Google Play Services funktionierten die Apps zwar im Großen und Ganzen, aber es gab nervige Probleme
Die My Disney Experience App hatte einige Standort-bezogene Fehler, und gelegentlich erschien bei wichtigen Aktionen die Meldung, dass man sich in den USA oder Kanada befinden müsse, sodass wir das Phone meiner Frau als Workaround nutzen mussten
In der Universal-App konnte ich mich nicht in mein Konto einloggen; auf dem normalen Samsung Galaxy meiner Frau ging es problemlos, daher sah es nach einem GrapheneOS-Problem aus
Wenn man außerdem Kreditkartenzahlungen mit Google Wallet macht, wird das nicht unterstützt, weil Google GrapheneOS nicht zertifiziert
Andere Funktionen von Wallet funktionieren
Uber funktioniert ohne Probleme
Sonst nutze ich keine proprietären Apps
Wenn man hauptsächlich freie/Open-Source-Apps nutzen will, sollte es keine Probleme geben
Die meisten proprietären Apps funktionieren mit den sandboxed Google Play Services, aber wenn darunter eine geschäftlich sehr wichtige App ist, kann man auf nervige Probleme stoßen, wie ich sie bei Universal Studios und My Disney Experience erlebt habe
Ich habe ein normales USB-Kabel und
adbauf der Linux-Kommandozeile benutzt, aber die empfohlene Methode läuft über WebUSB in Chromium und sollte für Nicht-Techniker einfacher seinIn meinem Fall hat das allerdings nicht gut funktioniert
Durch die sandboxed Google Play Services hat man das Beste aus beiden Welten: Man kann all die proprietären Apps installieren, die das moderne Leben erträglich machen, ohne dass Google Play unbegrenzten Zugriff auf das ganze Phone bekommt
Wenn man mehr Isolation möchte, kann man einen separaten Nutzer anlegen und die Google-Play-bezogenen Komponenten in diesem Konto ausführen
Ich habe das kurz ausprobiert, fand den Nutzerwechsel jedes Mal aber persönlich lästig
Das Phone ist noch nie abgestürzt, und Banking-Apps funktionieren ebenfalls
Das Gerät ist ein Pixel 6a
Man kann auch ein Gerät mit vorinstalliertem System kaufen, aber fast jeder kann den Web-Installer nutzen
Unter Android, ChromeOS und macOS ist es besonders einfach; Windows ist etwas komplizierter, weil Treiber installiert werden müssen
Desktop-Linux erfordert die Installation von udev-Regeln, und einige Distributionen mit fest eingefrorenen Softwareversionen haben störende, fehlerhafte Dienste
Auch Nicht-Techniker können es machen; man braucht nur einen Browser mit WebUSB-Unterstützung
Spezielle Software ist nicht nötig
Im Alltag ist es mit sandboxed Google Play fast wie das Standard-Pixel-OS, und auch die App-Kompatibilität ist nahezu ähnlich
Es ist sehr wahrscheinlich, dass man nicht nennenswert mehr Crashes erlebt
Es gibt Crash-Berichte für Nutzer, die das Standard-OS nicht hat, sodass man Crashes bemerken kann, die einem sonst gar nicht aufgefallen wären
Fehlerhafte Apps mit Speicherbeschädigungen können abstürzen, bis man den Kompatibilitätsmodus pro App aktiviert; das ist besonders wahrscheinlich, wenn man sich dafür entscheidet, MTE für alle vom Nutzer installierten Apps zu erzwingen
Banking-Apps funktionieren, wenn die Bank ein nicht von Google zertifiziertes OS zulässt, und derzeit tun das die meisten noch
Allerdings blockieren Banken zunehmend OSes ohne Google-Zertifizierung; das sollte im Kern als wettbewerbsrechtliches Regulierungsproblem behandelt werden
In der Zwischenzeit versuchen wir, Banken davon zu überzeugen, https://grapheneos.org/articles/attestation-compatibility-guide zu nutzen
Die zusätzlichen Sicherheitsfunktionen, Sandboxing-Einstellungen und der hardened memory allocator machen es etwas umständlicher, als einfach Stock-Android zu verwenden und jede Anfrage auf Datenzugriff mit OK zu bestätigen
Auch die Ersteinrichtung und das Verständnis dafür, worin sich GrapheneOS unterscheidet und wie man die Sicherheitsfunktionen nutzt, brauchen etwas Zeit
In 4 Jahren Nutzung hatte ich keine Crashes
Zumindest keine systemweiten Crashes; Crashes, wegen derer man tagelang debuggen müsste, treten nach meiner Erfahrung nicht auf, weil Pixel-Hardware und -Software gut aufeinander abgestimmt sind
Banking-Apps hängen von der jeweiligen App ab
Einige funktionieren ohne Play Services, die meisten mit sandboxed Play Services, und nur sehr wenige funktionieren überhaupt nicht
Wenn du sagst, welche Bank du nutzt, können andere Nutzer prüfen, ob es funktioniert
Selbst die schwierige Installationsmethode besteht im Wesentlichen daraus, das Phone per USB anzuschließen, ein wenig auf Power-/Lautstärketasten zu drücken und zwei oder drei Terminalbefehle zu kopieren und einzufügen
Die einfache Methode besteht nur darin, das Phone mit dem Computer zu verbinden und in einem Chrome-Browser auf einen Ein-Klick-Installationsbutton zu drücken
Ich nutze es fast durchgehend als Alltags-OS, seit kurz nach Erscheinen des Google Pixel 6, und es ist kein einziges Mal abgestürzt
Ich hatte auch nie Bugs oder irgendetwas, das Debugging, Fixes oder Wartung erfordert hätte
Alle Apps, die ich ausprobiert habe, funktionierten einfach wie unter Stock-Android, und ehrlich gesagt merke ich kaum einen Unterschied
Manchmal vergesse ich sogar, dass das nicht das OS ist, das ursprünglich auf dem Phone installiert war
Meine Banking-App Discover funktioniert, zu anderen Apps kann ich nichts Sicheres sagen
Da es aber Google Play services gibt und der Bootloader nach der Installation gesperrt wird, dürften vermutlich die meisten funktionieren
Im Jahr 2024 brauchen wir ein formal verifiziertes Betriebssystem, Anwendungen und Tools, die den Geist von seL4 fortführen, aber auf einem noch strengeren Niveau
In der heutigen Zeit leicht getestete, überkonstruierte Codebasen mit verwundbaren und gefährlichen Sprachen zusammenzuflicken, bedeutet, Angriffsflächen für viele lästige Bugs, Malware und Hacking-Angriffe zu schaffen — und ausländische Akteure könnten Systeme hacken, wodurch Nutzer sogar sterben könnten
Darüber hinaus müssen sie eine saubere, integrierte User Experience und brauchbare Funktionen bieten; sonst ist die ganze Engineering-Arbeit vergeblich
Siehe Qubes OS
Gibt es unter den brauchbaren Single-Board-Computern welche, die Arm MTE implementieren? So etwas wie die neuesten Raspberry Pi?
Der RasPi 5 hat einen Quad-A76 und nutzt v8.2-Erweiterungen; MTE gehört zu v8.5.
Wie schneidet MTE im Vergleich zu CHERI ab?
MTE ist dazu gedacht, potenzielle Sicherheits-Bugs zu finden, und ist kein echter Schutz.
Die Tags haben nur 4 Bit und können von Anwendungen gefälscht werden; wenn ein Angreifer also den richtigen Tag treffen muss, liegt er selbst bei zufälliger Wahl mit einer Wahrscheinlichkeit von 1/16 richtig.
Die Idee beim Einsatz von MTE ist, dass selbst ohne Angreifer gelegentlich fehlerhafte Zugriffe auftreten und man Fälle erwischt, die in der Praxis gar keine schlimmen Folgen hätten.
Man denke an einen typischen Buffer Overflow: Die Wörter direkt hinter dem Ende des Buffers werden vielleicht für nichts anderes verwendet, sodass es praktisch trotzdem funktionieren kann.
MTE erkennt solche Zugriffe und ermöglicht es, sie zu untersuchen und zu patchen, bevor daraus ein weaponized Exploit wird.
Über reservierte Tags kann es allerdings starke deterministische Sicherheitseigenschaften bereitstellen.
Nicht getaggtes hat den Tag 0, und Getaggtes hat wegen des standardmäßigen Ausschlusses grundsätzlich einen Tag ungleich 0.
Andere Tags können per Instruktion ebenfalls statisch oder dynamisch ausgeschlossen werden; nutzt man aber den Tag 0 für interne Zwecke wie freigegebenen Speicher, kann kein getaggter Pointer darauf zugreifen.
In hardened_malloc werden für Allocation-Slots benachbarte Tags und zuvor verwendete Tags dynamisch ausgeschlossen.
Das bietet deterministischen Schutz gegen lineare Overflows und kleine Overflows.
Bei Use-after-free können Pointer auf freigegebene Allocations weder während der Freigabe noch unmittelbar nach einer erneuten Allocation zugreifen; sie müssen bis zur nächsten Wiederzuweisung warten, und dann beträgt die Wahrscheinlichkeit für den richtigen Tag 1/15.
Das passt gut zu den anderen Sicherheitseigenschaften von hardened_malloc.
Für Slab-Allocation und virtuellen Speicher gibt es FIFO-/zufällige Quarantänebereiche, die Wiederverwendung weiter verzögern und nichtdeterministisch machen.
Bis über 128k hinaus werden Speicherpositionen niemals zwischen unterschiedlichen Allocation-Größenklassen wiederverwendet; jede Klasse liegt in einem anderen Bereich, und sämtliche Metadaten liegen wiederum in einem weiteren reservierten Bereich.
Im allgemeinen Fall hat MTE derzeit nur 4 Bit, daher liegt die Umgehungswahrscheinlichkeit bei etwa 1/15.
Es ließe sich leicht um Unterstützung für 8 Bit erweitern, und wenn man PAC nicht nutzt, gibt es noch weitere freie Bits.
Theoretisch könnte in einem üblichen 39-Bit-Adressraum für Adressräume ab 48 Bit sogar MTE mit bis zu 16 Bit unterstützt werden.
Derzeit ist es auf 4 Bit festgelegt; ich habe gehört, dass das statt 8 Bit gewählt wurde, damit zusätzliche Bits im ECC-Paritätsspeicher abgelegt werden können.
Allerdings erkennt es sie nicht so zuverlässig wie CHERI.
Es gibt keinen Schutz für die Tags, und der Tag-Raum ist klein (2^4).
Ich freue mich auf den Tag, an dem Mainstream-Hardware die Memory-Tagging-Architekturen von Solaris SPARC aus dem Jahr 2015 oder noch früher einholt und wir Memory-Corruption-Probleme endlich in den Griff bekommen.
Natürlich werden diese Probleme oft so abgetan, als würden sie nur von unfähigen Entwicklern verursacht.
Das ist kein Problem „unfähiger Entwickler“, sondern betrifft alle.
Memory Corruption ist praktisch eher ein Sprachfeature von C/C++.
Man sollte nicht die Vorstellung verbreiten, sie entstehe wegen dummer Leute.
Kaum jemand hält sich selbst für dumm, und ich habe auch wirklich hervorragende Coder lustige Memory-Bugs produzieren sehen.
Das gehört einfach zum Terrain dieser Sprachen; es ist keine Frage des „ob“, sondern des „wann“.
Mir gefällt, dass da ziemlich beiläufig der Satz eingebaut wurde, dass Android einen großen Teil des Bluetooth-Codes nach Rust migriert hat und dass das zeigt, warum mehr Ressourcen in die Migration des restlichen Codes zu Rust gesteckt werden sollten.
Ich habe jahrelang C und C++ genutzt, aber keine Rust-Erfahrung; deshalb frage ich mich, wie viel Refactoring beim Portieren von C nach Rust nötig ist.
Aufgeteilt gefragt: 1. Wie direkt lässt sich C nach Rust übersetzen? Erzwingt Rust eine Umstrukturierung oder Refactoring?
2. Wie geht Google dabei vor? Versuchen sie möglichst nah zu „übersetzen“, oder sehen sie es als Gelegenheit für ein großes Rewrite/Refactoring?
Außerdem frage ich mich, ob der Android-Bluetooth-Stack irgendwann auf Desktop-Systemen mit Standard-Linux-Distributionen nutzbar sein wird.
Es gab viele zyklische Referenzen; die Module kommunizierten über eine Art „Signal-Bus“ mit Callbacks miteinander, und Rust fühlte sich eher wie ein Gegner an als wie eine Hilfe.
Selbst an Stellen, an denen C++ Daten inline speichern konnte, brauchte ich viele Boxen, also Heap-Pointer.
Mein Fazit: Bei einfachen Kommandozeilentools oder Request-Response-Strukturen ist ein Rust-Port vermutlich leicht.
Allgemeiner gesagt: Wenn die Code-Struktur gut zu Arena-Allocation passt, ist es kein großes Problem, Referenzen mit Lifetime-Tags zu übertragen.
Wenn man aber C-Programmierer-typisch zugegebenermaßen hässlichen Code mit zyklischen Referenzen geschrieben hat, fühlt sich Rust wie ein steiler Aufstieg an und ist nicht der richtige Startpunkt.
Zuerst müsste man die C++-Codestruktur ändern und Ownership zu einem gemeinsamen Parent verschieben.
Dann dürfte es besser werden.
Ich werde Rust schrittweise weiter lernen, aber vorerst in C++ weiterarbeiten, bis der Code besser zu Rust passt.
Einen großen Teil dessen, was du schreibst, wirst du neu architektieren müssen.
Wegen der Art, wie Rust Memory Safety garantiert, lässt sich das nicht vermeiden.