GWP-ASan to natywna funkcja alokacji pamięci, która pomaga wykrywać błędy w przypadku błędów use-after-free i heap-buffer-overflow. Jej nieformalna nazwa to akronim rekurencyjny: „GWP-ASan Will Poiduj lokalizację SAN”. W przeciwieństwie do HWASan i debugowania za pomocą Malloca GWP-ASan nie wymaga źródła ani rekompilacji (tj. działa z gotowymi aplikacjami) i działa zarówno w procesach 32-, jak i 64-bitowych (chociaż w przypadku awarii 32-bitowych mniej danych debugowania jest możliwe). W tym temacie opisujemy działania, które trzeba wykonać, aby włączyć tę funkcję w swojej aplikacji. Narzędzie GWP-ASan jest dostępne w aplikacjach kierowanych na Androida 11 (poziom API 30) lub nowszy.
Przegląd
Narzędzie GWP-ASan jest włączane w niektórych losowo wybranych aplikacjach systemowych i elementach wykonywalnych platformy podczas uruchamiania procesu (lub gdy rozwidla się zygote). Włącz GWP-ASan w swojej aplikacji, aby łatwiej znajdować błędy związane z pamięcią i przygotować aplikację do obsługi rozszerzenia ARM Memory Tagging Extension (MTE). Mechanizmy próbkowania alokacji zapewniają też niezawodność względem zapytań o śmierć.
Po włączeniu GWP-ASan przechwytuje losowo wybrany podzbiór alokacji sterty i umieszcza je w specjalnym regionie, który wychwytuje trudne do wykrycia błędy związane z uszkodzeniem pamięci sterty. Przy wystarczającej liczbie użytkowników nawet tak niska częstotliwość próbkowania znajdzie błędy związane z bezpieczeństwem pamięci sterty, których nie udało się znaleźć podczas regularnych testów. Na przykład zespół GWP-ASan znalazł dużą liczbę błędów w przeglądarce Chrome (wiele z nich nadal znajduje się w widoku z ograniczonym dostępem).
GWP-ASan zbiera dodatkowe informacje o wszystkich przechwytywanych przydziałach. Informacje te są dostępne, gdy GWP-ASan wykryje naruszenie bezpieczeństwa pamięci i są automatycznie umieszczane w raporcie o awariach natywnych, co może znacznie ułatwić debugowanie (patrz przykład).
Narzędzie GWP-ASan nie powoduje znacznego obciążenia procesora. GWP-ASan wprowadza niewielki, stały narzut pamięci RAM po włączeniu. Ten nadmiar jest określany przez system Android i obecnie wynosi około 70 kibibajtów (KiB) dla każdego procesu, którego dotyczy problem.
Włączanie aplikacji
Aplikację GWP-ASan można włączać na poziomie poszczególnych procesów przy użyciu tagu android:gwpAsanMode
w pliku manifestu aplikacji. Obsługiwane są te opcje:
Zawsze wyłączona (
android:gwpAsanMode="never"
): to ustawienie całkowicie wyłącza GWP-ASan w aplikacji i jest domyślnym ustawieniem dla aplikacji niesystemowych.Domyślnie (
android:gwpAsanMode="default"
lub nieokreślony): Android 13 (poziom interfejsu API 33) i niższy – GWP-ASan jest wyłączony. Android 14 (poziom interfejsu API 34) i wyższy – włączona jest opcja Recoverable GWP-ASan.Zawsze włączone (
android:gwpAsanMode="always"
): to ustawienie włącza GWP-ASan w aplikacji, w tym:System operacyjny rezerwuje stałą ilość pamięci RAM na potrzeby operacji GWP-ASan – około 70 KiB na każdy proces, którego dotyczy problem. (Jeśli aplikacja nie jest krytycznie podatna na wzrost wykorzystania pamięci, włącz GWP-ASan).
GWP-ASan przechwytuje losowo wybrany podzbiór alokacji sterty i umieszcza je w specjalnym regionie, który niezawodnie wykrywa naruszenia zasad bezpieczeństwa pamięci.
Jeśli w specjalnym regionie doszło do naruszenia bezpieczeństwa pamięci, GWP-ASan kończy ten proces.
GWP-ASan udostępnia dodatkowe informacje o błędzie w raporcie o awariach.
Aby globalnie włączyć GWP-ASan w aplikacji, dodaj do pliku AndroidManifest.xml
te dane:
<application android:gwpAsanMode="always"> ... </application>
Dodatkowo możesz włączyć lub wyłączyć GWP-ASan w przypadku określonych podprocesów aplikacji. Możesz kierować reklamy na działania i usługi za pomocą procesów, które zostały wyraźnie włączone lub wyłączone z GWP-ASan. Oto przykład:
<application> <processes> <!-- Create the (empty) application process --> <process /> <!-- Create subprocesses with GWP-ASan both explicitly enabled and disabled. --> <process android:process=":gwp_asan_enabled" android:gwpAsanMode="always" /> <process android:process=":gwp_asan_disabled" android:gwpAsanMode="never" /> </processes> <!-- Target services and activities to be run on either the GWP-ASan enabled or disabled processes. --> <activity android:name="android.gwpasan.GwpAsanEnabledActivity" android:process=":gwp_asan_enabled" /> <activity android:name="android.gwpasan.GwpAsanDisabledActivity" android:process=":gwp_asan_disabled" /> <service android:name="android.gwpasan.GwpAsanEnabledService" android:process=":gwp_asan_enabled" /> <service android:name="android.gwpasan.GwpAsanDisabledService" android:process=":gwp_asan_disabled" /> </application>
Odzyskiwanie GWP-ASan
Android w wersji 14 (poziom interfejsu API 34) lub wyższego poziomu obsługuje funkcję Recoverable GWP-ASan, która pomaga programistom znajdować w środowisku produkcyjnym błędy związane z przepełnieniem bufora i używaniem sterty bez obniżania wygody użytkownika. Jeśli właściwość android:gwpAsanMode
nie jest określona w AndroidManifest.xml
, aplikacja używa kodu GWP-ASan z możliwością przywrócenia.
GWP-ASan, który można odzyskać, różni się od GWP-ASan tym, że:
- Funkcja GWP-ASan, którą można przywrócić, jest włączana tylko przy około 1% uruchomień aplikacji, a nie przy każdym uruchomieniu.
- W przypadku wykrycia błędu „heap-use-after-free” lub „przepełnienia bufora sterty” pojawia się on w raporcie o awariach (tombstone). Ten raport o awariach jest dostępny przez interfejs API
ActivityManager#getHistoricalProcessExitReasons
, tak samo jak w przypadku oryginalnej aplikacji GWP-ASan. - Zamiast zamykania po zrzucie raportu o awarii można przywrócić GWP-ASan, aby możliwe było uszkodzenie pamięci, a aplikacja będzie nadal działać. Chociaż ten proces może przebiegać w zwykły sposób, działanie aplikacji nie jest już określone. Z powodu uszkodzenia pamięci aplikacja może ulec awarii w dowolnym momencie w przyszłości lub działać dalej bez negatywnego wpływu na działanie usługi.
- Funkcja odzyskiwania (GWP-ASan) jest wyłączona po zrzucie raportu o awarii. W związku z tym każde uruchomienie aplikacji może otrzymać tylko 1 raport GWP-ASan, który można przywrócić.
- Jeśli w aplikacji jest zainstalowany niestandardowy moduł obsługi sygnałów, nigdy nie jest on wywoływany w celu dostarczenia sygnału SIGSEGV, który wskazuje na możliwe do naprawienia błąd GWP-ASan.
Możliwe do odzyskania awarie GWP-ASan wskazują na prawdziwe przypadki uszkodzenia pamięci na urządzeniach użytkowników, dlatego zdecydowanie zalecamy sklasyfikowanie i naprawienie błędów zidentyfikowanych przez Recoverable GWP-ASan o wysokim priorytecie.
Pomoc dla programistów
W tych sekcjach opisujemy problemy, które mogą wystąpić podczas korzystania z GWP-ASan, oraz sposoby ich rozwiązywania.
Brak śladów alokacji/transakcji
Jeśli diagnozujesz awarię natywną, w której brakuje ramek alokacji/oddzielania, w Twojej aplikacji prawdopodobnie brakuje wskaźników ramek. GWP-ASan używa wskaźników ramek do rejestrowania logów czasu alokacji i transakcji ze względu na wydajność. Nie może cofnąć zrzutu stosu, jeśli ich nie ma.
Wskaźniki ramek są domyślnie włączone na urządzeniach Arm64 i domyślnie wyłączone na urządzeniach Arm32. Ponieważ aplikacje nie mają kontroli nad biblioteką biblioteczną, GWP-ASan nie może zbierać logów czasu alokacji/dealokacji w przypadku 32-bitowych plików wykonywalnych lub aplikacji. Aplikacje 64-bitowe powinny się upewnić, że nie są tworzone z wykorzystaniem protokołu -fomit-frame-pointer
, aby GWP-ASan mógł zbierać zrzuty stosu alokacji i transakcji.
Odtwarzanie naruszeń bezpieczeństwa
Narzędzie GWP-ASan służy do wykrywania naruszeń bezpieczeństwa pamięci sterty na urządzeniach użytkowników. GWP-ASan zapewnia jak najwięcej informacji na temat awarii (zrzut dostępu do danych o naruszeniu, ciąg znaków powodujący oraz ślady przydziału/rozdzielania), ale trudno jest wywnioskować, jak doszło do naruszenia. Niestety rozpoznanie błędu jest bardzo prawdopodobne, dlatego odtworzenie raportu GWP-ASan na urządzeniu lokalnym jest często trudne.
W takich przypadkach, jeśli błąd dotyczy urządzeń 64-bitowych, należy użyć metody HWAddressSanitizer (HWASan). HWASan niezawodnie wykrywa naruszenia zasad bezpieczeństwa pamięci w stosie, stercie i globalnej. Uruchomienie aplikacji przy użyciu HWASan może niezawodnie odtworzyć ten sam wynik co raport GWP-ASan.
Jeśli uruchomienie aplikacji przy użyciu systemu HWASan jest niewystarczające do wywołania głównego błędu, należy spróbować zdezorientować dany kod. Efektywność rozmycia możesz ukierunkować na podstawie informacji z raportu GWP-ASan, który może skutecznie wykryć i wykryć potencjalne problemy ze stanem kodu.
Przykład
W tym przykładowym kodzie natywnym występuje błąd związany ze stertą użycia po wolnym działaniu:
#include <jni.h>
#include <string>
#include <string_view>
jstring native_get_string(JNIEnv* env) {
std::string s = "Hellooooooooooooooo ";
std::string_view sv = s + "World\n";
// BUG: Use-after-free. `sv` holds a dangling reference to the ephemeral
// string created by `s + "World\n"`. Accessing the data here is a
// use-after-free.
return env->NewStringUTF(sv.data());
}
extern "C" JNIEXPORT jstring JNICALL
Java_android11_test_gwpasan_MainActivity_nativeGetString(
JNIEnv* env, jobject /* this */) {
// Repeat the buggy code a few thousand times. GWP-ASan has a small chance
// of detecting the use-after-free every time it happens. A single user who
// triggers the use-after-free thousands of times will catch the bug once.
// Alternatively, if a few thousand users each trigger the bug a single time,
// you'll also get one report (this is the assumed model).
jstring return_string;
for (unsigned i = 0; i < 0x10000; ++i) {
return_string = native_get_string(env);
}
return reinterpret_cast<jstring>(env->NewGlobalRef(return_string));
}
W ramach testu z użyciem powyższego przykładowego kodu aplikacja GWP-ASan wykryła niedozwolone działanie i wygenerowała raport o awariach poniżej. Zespół GWP-ASan automatycznie wzbogacił raport o informacje o typie awarii, metadanych alokacji oraz powiązanych z nimi alokacjach i śladach stosu transakcji.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/sargo/sargo:10/RPP3.200320.009/6360804:userdebug/dev-keys'
Revision: 'PVT1.0'
ABI: 'arm64'
Timestamp: 2020-04-06 18:27:08-0700
pid: 16227, tid: 16227, name: 11.test.gwpasan >>> android11.test.gwpasan <<<
uid: 10238
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x736ad4afe0
Cause: [GWP-ASan]: Use After Free on a 32-byte allocation at 0x736ad4afe0
backtrace:
#00 pc 000000000037a090 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckNonHeapValue(char, art::(anonymous namespace)::JniValueType)+448)
#01 pc 0000000000378440 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+204)
#02 pc 0000000000377bec /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+612)
#03 pc 000000000036dcf4 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::NewStringUTF(_JNIEnv*, char const*)+708)
#04 pc 000000000000eda4 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (_JNIEnv::NewStringUTF(char const*)+40)
#05 pc 000000000000eab8 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (native_get_string(_JNIEnv*)+144)
#06 pc 000000000000edf8 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (Java_android11_test_gwpasan_MainActivity_nativeGetString+44)
...
deallocated by thread 16227:
#00 pc 0000000000048970 /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::AllocationMetadata::CallSiteInfo::RecordBacktrace(unsigned long (*)(unsigned long*, unsigned long))+80)
#01 pc 0000000000048f30 /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::GuardedPoolAllocator::deallocate(void*)+184)
#02 pc 000000000000f130 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (std::__ndk1::_DeallocateCaller::__do_call(void*)+20)
...
#08 pc 000000000000ed6c /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::~basic_string()+100)
#09 pc 000000000000ea90 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (native_get_string(_JNIEnv*)+104)
#10 pc 000000000000edf8 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (Java_android11_test_gwpasan_MainActivity_nativeGetString+44)
...
allocated by thread 16227:
#00 pc 0000000000048970 /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::AllocationMetadata::CallSiteInfo::RecordBacktrace(unsigned long (*)(unsigned long*, unsigned long))+80)
#01 pc 0000000000048e4c /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan::GuardedPoolAllocator::allocate(unsigned long)+368)
#02 pc 000000000003b258 /apex/com.android.runtime/lib64/bionic/libc.so (gwp_asan_malloc(unsigned long)+132)
#03 pc 000000000003bbec /apex/com.android.runtime/lib64/bionic/libc.so (malloc+76)
#04 pc 0000000000010414 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (operator new(unsigned long)+24)
...
#10 pc 000000000000ea6c /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (native_get_string(_JNIEnv*)+68)
#11 pc 000000000000edf8 /data/app/android11.test.gwpasan/lib/arm64/libmy-test.so (Java_android11_test_gwpasan_MainActivity_nativeGetString+44)
...
Więcej informacji
Więcej informacji o implementacji GWP-ASan znajdziesz w dokumentacji LLVM. Więcej informacji o raportach o natywnych awariach Androida znajdziesz w artykule Diagnozowanie awarii natywnych.