Android unterstützt mehrere Tools zum Beheben von Speicherfehlern. In beiden Fällen haben beide Vor- und Nachteile. Lesen Sie daher die folgenden Informationen, um zu entscheiden, welche für Ihren Anwendungsfall am besten geeignet ist. Dieses Dokument gibt Ihnen einen Überblick über die verfügbaren Tools, damit Sie entscheiden können, welche Sie weiter untersuchen möchten. Es ist jedoch kurz und prägnant. Lesen Sie daher die toolspezifischen Dokumente, um mehr zu erfahren.
Kurzfassung
- Verwenden Sie nach Möglichkeit eine speichersichere Sprache, um Arbeitsspeicherfehler unmöglich zu machen.
- Immer PAC/BTI verwenden, um ROP/JOP-Angriffe abzuschwächen
- Verwenden Sie immer GWP-ASan, um seltene Speicherfehler in der Produktion zu erkennen.
- Verwenden Sie HWASan, um Arbeitsspeicherfehler beim Testen zu erkennen
- MTE-fähige Geräte sind 2023 nicht allgemein verfügbar. Verwenden Sie sie jedoch, wenn Sie Fehler in der Produktion erkennen können.
- Verwenden Sie ASan während des Tests nur als letzte Option.
Speichersichere Sprachen
Eine speichersichere Sprache ist die einzige Möglichkeit, Speicherfehler vollständig zu vermeiden und zu minimieren. Mit den anderen Tools auf dieser Seite können Sie den Code sicherer und zuverlässiger für den Arbeitsspeicher machen. Durch die Verwendung einer speichersicheren Sprache werden jedoch alle Probleme beseitigt.
Die offiziell unterstützten arbeitsspeichersicheren Sprachen für Android sind Java und Kotlin. Die meisten Android-Apps lassen sich einfacher in einer dieser Sprachen entwickeln.
Allerdings gibt es App-Entwickler, die Code in Rust versenden. Wenn Sie diese Seite lesen, haben Sie wahrscheinlich einen guten Grund, nativen Code zu benötigen (Portabilität, Leistung oder beides). Rust ist die beste Wahl für speichersicheren nativen Code unter Android. Das NDK-Team kann Ihnen auf diesem Weg nicht unbedingt weiterhelfen, aber wir würden gerne mehr darüber erfahren.
PAC/BTI
Zeiger-Authentifizierung und Zweig-Ziel-Identifizierung, auch PAC/BTI genannt, sind Entschärfungstools, die für den Einsatz in der Produktion geeignet sind. Trotz unterschiedlicher Technologien werden sie vom selben Compiler-Flag gesteuert und deshalb immer zusammen verwendet.
Diese Funktionen sind abwärtskompatibel mit Geräten, die sie nicht unterstützen, da die neue Anleitung auf älteren Geräten managementfrei ist. Außerdem ist es erforderlich, dass der Kernel und das Betriebssystem ausreichend neu sind.
Wenn Sie in /proc/cpuinfo nach paca und bti suchen, sehen Sie, ob Sie genügend Hardware und einen ausreichend neuen Kernel haben. Android 12 (API 31) hat die erforderliche Userspace-Unterstützung.
Vorteile:
- Kann in allen Builds aktiviert werden, ohne auf älteren Geräten oder Kernels Probleme zu verursachen. Testen Sie jedoch unbedingt auf einer Kombination aus Gerät, Kernel und Betriebssystem, die diese unterstützt.
Nachteile:
- Nur für 64-Bit-Apps verfügbar
- Wenig Fehler auf Geräten, die diese Funktion nicht unterstützen
- 1% Overhead für Codegröße
GWP-Asan
Mit GWP-ASan lassen sich Speicherfehler in einem Bereich erkennen. Allerdings ist die Abtastrate zu niedrig, um diese effektiv zu entschärfen.
Vorteile:
- Keine signifikante CPU- oder Arbeitsspeicherauslastung
- Einfache Bereitstellung: nativer Code muss nicht neu erstellt werden
- Kompatibel mit 32-Bit-Apps
Nachteile:
- Bei einer niedrigen Abtastrate ist eine große Anzahl von Nutzenden erforderlich, um Fehler effektiv zu finden.
- Erkennt nur Heap-Fehler, keine Stack-Fehler
Washington, D.C.
Hardware Address Sanitizer, auch als HWASan bezeichnet, eignet sich am besten, um während Tests Speicherfehler zu erkennen. Sie ist am nützlichsten bei automatisierten Tests, insbesondere wenn Sie Fuzz-Tests ausführen. Je nach Leistungsanforderungen Ihrer App kann sie aber auch auf High-End-Smartphones in einer Dogfood-Einstellung verwendet werden.
Vorteile:
- Keine falsch positiven Ergebnisse
- Erkennt zusätzliche Klassen von Fehlern, die ASan nicht erkennen kann (Stacknutzung nach Rückgabe)
- Niedrigere Rate falsch negativer Ergebnisse als MTE (1 von 256 gegenüber 1 von 16)
- Geringerer Arbeitsspeicheraufwand als bei ASan, der nächstgelegenen Alternative
Nachteile:
- Erhebliche CPU- (~100 %), Codegröße (~50 %) und Arbeitsspeicher (10–35 %)
- Bis API 34 und NDK r26 muss ein mit HWASan kompatibles Image geflasht werden.
- Funktioniert nur mit 64-Bit-Apps
MTE
Die Speicher-Tagging-Erweiterung, auch als MTE bezeichnet, ist eine kostengünstigere Alternative zu HWASan. Zusätzlich zu den Debugging- und Testfunktionen kann sie verwendet werden, um Speicherschäden in der Produktion zu erkennen und zu mindern. Wenn Sie die Hardware zum Testen von MTE-Builds haben, sollten Sie diese aktivieren.
Vorteile:
- Der Aufwand ist gering genug, um in der Produktion für viele Apps vertretbar zu sein.
- Keine falsch positiven Ergebnisse
- Erfordert keinen Neuerstellung von Code zum Erkennen von Heap-Fehlern (aber zur Erkennung von Stackfehlern)
Nachteile:
- Es gibt keine im Handel erhältlichen Geräte, bei denen MTE 2024 standardmäßig aktiviert ist. In der Dokumentation von Arm wird jedoch erläutert, wie MTE für Tests auf Pixel 8/Pixel 8 Pro aktiviert wird.
- Falsch negative Rate 1 von 16 im Vergleich zu HWASans 1 von 256
- Nur für 64-Bit-Apps verfügbar
- Erfordert das Erstellen separater Bibliotheken für die Ausrichtung auf MTE-fähige und nicht MTE-fähige Geräte
Asan
Address Sanitizer, auch als ASan bezeichnet, ist das älteste und am weitesten verbreitete der verfügbaren Tools. Dies ist nützlich, um beim Testen und Debuggen von Problemen Arbeitsspeicherfehler zu erkennen, die nur alte Geräte betreffen, auf denen keines der anderen Tools verfügbar ist. Wenn möglich, solltest du HWASan bevorzugen.
Vorteile:
- Weit verbreitet. Funktioniert möglicherweise auf Geräten, die so alt sind wie KitKat.
- Keine falsch positiven oder negativen Ergebnisse bei richtiger Anwendung
Nachteile:
- Schwer zu erstellen und richtig zu verpacken
- Höchster Overhead aller Optionen: ~100% CPU, ~50% Codegröße, ~100% Arbeitsspeichernutzung
- Nicht mehr unterstützt
- Hat bekannte Fehler, die nicht behoben werden