Niezainicjowana pamięć w językach C i C++ jest częstą przyczyną problemów z niezawodnością, błędów związanych z bezpieczeństwem pamięci i wycieków informacji. Aby uniknąć tych problemów, Android inicjuje jak najwięcej pamięci.
Wyzeruj zainicjowaną pamięć przestrzeni użytkownika
Od wersji Androida 12 pamięć stosu jest inicjowana zerem we wszystkich natywnych kodach platformy (w tym JNI), a pamięć sterty jest inicjowana zerem we wszystkich procesach natywnych platformy (takich jak netd ), ale nie w zygote ani w aplikacjach.
Zdecydowanie zaleca się, aby aplikacje własne i aplikacje innych firm zbudowane przy użyciu NDK korzystały z flagi kompilatora -ftrivial-auto-var-init=zero w celu inicjowania zerem lokalnych zmiennych stosu. Kompilator optymalizuje wszelkie niepotrzebne zerowania. Na przykład, gdy zmienna lokalna jest jawnie inicjowana (np. int x = 123; zmienna x jest inicjowana tylko raz). Jeśli program ma duży bufor stosu w punkcie aktywnym wydajności, programista może wyłączyć inicjalizację za pomocą atrybutu kompilatora:
__attribute__((__uninitialized__)) char buf[BUFSIZ]; Aplikacje mogą również wyrazić zgodę na inicjowanie zerowej sterty przy użyciu atrybutu manifestu android:nativeHeapZeroInitialized . Alternatywnie, inicjalizacją zera sterty można sterować w czasie wykonywania za pomocą:
int mallopt(M_BIONIC_ZERO_INIT, level)Gdzie poziom wynosi 0 lub 1.
Zero zainicjowanej pamięci jądra
Stos jądra i sterta są inicjowane zerem dla jąder GKI, co jest zdecydowanie zalecane przez CDD .
Do inicjalizacji stosu GKI używa konfiguracji CONFIG_INIT_STACK_ALL_ZERO , co skutkuje zbudowaniem jądra przy użyciu flagi kompilatora -ftrivial-auto-var-init=zero . Do inicjalizacji sterty GKI używa CONFIG_INIT_ON_ALLOC_DEFAULT_ON , co powoduje, że wszystkie alokacje sterty stron, SLAB i SLUB są inicjowane zerem podczas ich tworzenia. Ta opcja jest w rzeczywistości podobna do przekazywania init_on_alloc=1 jako opcji uruchamiania jądra.
Zgłaszanie błędów
Nasze narzędzia generują wnikliwe raporty o błędach, które zawierają dodatkowe informacje pomocne w debugowaniu. Dodatkowe śledzenie stosu alokacji i dezalokacji pomaga lepiej zrozumieć cykl życia danej alokacji i znacznie szybciej prowadzi do błędów związanych z bezpieczeństwem pamięci powodujących rootowanie.
Podczas opracowywania dostawcy powinni monitorować obecność błędów, sprawdzając /data/tombstones i logcat pod kątem natywnych awarii. Aby uzyskać więcej informacji na temat debugowania natywnego kodu Androida, zobacz informacje tutaj .