Nicht initialisierter Speicher in C und C++ verursacht häufig Zuverlässigkeitsprobleme. und Informationslecks. Um diese Probleme zu vermeiden, so viel Speicher wie möglich initialisiert wird.
Null initialisierter Userspace-Arbeitsspeicher
Seit Android 12 ist der Stapelspeicher null initialisiert
im gesamten plattformnativen Code (einschließlich JNI) und im Heap-Speicher ist null
in allen plattformnativen Prozessen initialisiert (z. B. netd)
aber nicht in zygote oder in Apps.
Mit dem NDK erstellte Erst- und Drittanbieter-Apps
wird empfohlen, das Compiler-Flag -ftrivial-auto-var-init=zero zu verwenden, um den Stack lokal auf null zu initialisieren
Variablen. Der Compiler entfernt alle unnötigen Nullwerte.
Wenn z. B. eine lokale Variable explizit initialisiert wird,
(Die int x = 123;-Variable x wird z. B. nur einmal initialisiert.)
Wenn das Programm einen großen Stack-Zwischenspeicher in einer Leistung hat
kann der Entwickler die Initialisierung mithilfe eines Compilers
Attribut:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
Apps können die Heap-Null-Initialisierung auch aktivieren, indem sie die
Manifest-Attribut android:nativeHeapZeroInitialized.
Alternativ kann die Heap-Null-Initialisierung zur Laufzeit gesteuert werden
durch:
int mallopt(M_BIONIC_ZERO_INIT, level)
Wobei die Ebene 0 oder 1 ist.
Null initialisierter Kernel-Arbeitsspeicher
Der Kernel-Stack und Heap sind für GKI-Kernels null initialisiert, was stark vom CDD empfohlen.
Für die Stack-Initialisierung verwendet GKI die
CONFIG_INIT_STACK_ALL_ZERO-Konfiguration, die zum Erstellen der
Kernel mit dem Compiler-Flag -ftrivial-auto-var-init=zero.
Zur Heap-Initialisierung verwendet GKI die
CONFIG_INIT_ON_ALLOC_DEFAULT_ON, wodurch der gesamte Seiten-Heap, SLAB, erstellt wird
und die SLUB-Zuweisungen
bei ihrer Erstellung mit null initialisiert werden. Diese Option ist
ähnlich wie init_on_alloc=1 als Kernel übergeben wird.
die Boot-Time-Option.
Fehlerberichte
Unsere Tools generieren aufschlussreiche Fehlerberichte mit zusätzlichen Informationen bei der Fehlerbehebung helfen. Der zusätzliche Stacktrace für die Zuweisung und die Freigabe den Lebenszyklus einer bestimmten Zuweisung besser verstehen und dadurch wesentlich schneller Sicherheitsfehler im Arbeitsspeicher verursacht.
Während der Entwicklung sollten Anbieter
das Vorhandensein von Fehlern überwachen,
/data/tombstones und
logcat für native Abstürze. Weitere Informationen zu
Informationen zur Fehlerbehebung bei nativem Code in Android finden Sie hier.