Błędy SIGSEGV z kodem 9 (SEGV_MTESERR) lub kodem 8 (SEGV_MTEAERR) to błędy oznaczenia pamięci. Rozszerzenie oznaczania pamięci (MTE) to funkcja Armv9 obsługiwana w Androidzie 12 i nowszych. MTE to sprzętowa implementacja tagowanej pamięci. Zapewnia ona szczegółową ochronę pamięci w celu wykrywania i minimalizowania ryzyka związanego z błędami w zabezpieczeniach pamięci.
W języku C/C++ wskaźnik zwracany przez wywołanie malloc() lub operator new() lub podobnych funkcji może być używany tylko do uzyskiwania dostępu do pamięci w ograniczeniach tego przydziału i tylko przez czas jego istnienia (nie może być zwolniony ani usunięty). MTE jest używany w Androidzie do wykrywania naruszeń tej reguły, które w raportach o awariach są określane jako problemy „Przepełnienie bufora”/„Niedopełnienie bufora” i „Użycie po zwolnieniu”.
MTE ma 2 tryby: synchroniczny (lub „sync”) i asynchroniczny (lub „async”). Pierwsza z nich działa wolniej, ale zapewnia dokładniejsze informacje diagnostyczne. Ta druga jest szybsza, ale może podać tylko przybliżone informacje. Omówimy je osobno, ponieważ diagnostyka jest nieco inna.
MTE w trybie synchronicznym
W trybie synchronicznym (synchronizacja) MTE SIGSEGV ulega awarii z kodem 9 (SEGV_MTESERR).
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<< uid: 0 tagged_addr_ctrl: 000000000007fff3 signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000 backtrace: #00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) deallocated by thread 13935: #00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) allocated by thread 13935: #00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
Wszystkie raporty o zawieszeniu MTE zawierają standardowy zrzut rejestru i zrzut z wykryciem miejsca, w którym wykryto problem. W wierszu „Przyczyna:” błędu wykrytego przez MTE pojawi się wartość „[MTE]”, jak w przykładzie powyżej, wraz ze szczegółowymi informacjami. W tym przypadku wykryty błąd to „Użyj po użyciu”, a „0 bajtów w przydziale 32-bajtowym pod adresem 0x7ae92853a0” mówi nam o rozmiarze i adresie przydziału oraz przesunięciu w przydziale, do którego próbowaliśmy uzyskać dostęp.
Raporty o awariach MTE zawierają też dodatkowe ścieżki śledzenia, a nie tylko tę z miejsca wykrycia.
Błędy „Use After Free” powodują dodanie do zrzutu pamięci po awarii sekcji „deallocated by” (przydzielone przez) i „allocated by” (przydzielone przez), które zawierają ścieżki stosu w momencie odzyskania pamięci (przed jej użyciem) oraz w momencie jej wcześniejszego przydzielenia. Te informacje wskazują również, który wątek przydzielił lub zwolnił pamięć. W tym prostym przykładzie wszystkie 3 wątki (detekcji, przydzielania i zwalniania) są takie same, ale w bardziej złożonych przypadkach w rzeczywistych warunkach niekoniecznie tak jest. Wiedza o tym, że różnią się one od siebie, może być ważną wskazówką przy znajdowaniu błędów związanych z współbieżnością.
Błędy „Przepełnienie bufora” i „Przepełnienie bufora w dół” zapewniają tylko dodatkową ścieżkę śledzenia stosu „przydzielone przez”, ponieważ z definicji nie zostały jeszcze zwolnione (w przeciwnym razie byłyby wyświetlane jako „Użycie po zwolnieniu”).
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Zwróć uwagę na użycie słowa „right” (po prawej stronie): oznacza to, że informujemy, ile bajtów po zakończeniu alokacji było nieprawidłowych. W przypadku przepełnienia podajemy liczbę bajtów przed rozpoczęciem alokacji.
Wiele możliwych przyczyn
Czasami raporty SEGV_MTESERR zawierają ten wiersz:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Dzieje się tak, gdy istnieje kilka prawdopodobnych przyczyn błędu i nie możemy określić, która z nich jest rzeczywistą przyczyną. Wyświetlamy do 3 takich kandydatów w przybliżonym porządku prawdopodobieństwa, a analizę pozostawiamy użytkownikowi.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x400007b43063db5
backtrace:
[stack...]
Note: multiple potential causes for this crash were detected, listing them in decreasing order of probability.
Cause: [MTE]: Use After Free, 5 bytes into a 10-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]
Cause: [MTE]: Use After Free, 5 bytes into a 6-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]W powyższym przykładzie wykryliśmy 2 niedawne alokacje w tym samym adresie pamięci, który mógł być docelowym celem nieprawidłowego dostępu do pamięci. Może się tak zdarzyć, gdy alokacje ponownie używają wolnej pamięci – na przykład, jeśli masz sekwencję new, free, new, free, new, free, access. Nowsza alokacja jest drukowana jako pierwsza.
Szczegółowe heurystyki określania przyczyny
W polu „Przyczyna” informacji o awarii powinna być widoczna alokacja pamięci, z której pochodzi wskazywany wskaźnik. Niestety sprzęt MTE nie może przekształcić wskaźnika z niepasowanym tagiem w przydział. Aby wyjaśnić awarię SEGV_MTESERR, Android analizuje te dane:
- Adres miejsca wystąpienia błędu (w tym znacznik wskaźnika).
- Lista ostatnich alokacji stosu z wykresami ścieżek wywołań i tagami pamięci.
- bieżące (aktywne) alokacje w pobliżu i ich tagi pamięci;
Każda niedawno zwolona pamięć w adresie błędu, której tag pamięci jest zgodny z tagiem adresu błędu, może być potencjalną przyczyną „użycia po zwolnieniu”.
Każda aktywna pamięć w pobliżu, której tag pasuje do tagu adresu błędu, jest potencjalną przyczyną „przepełnienia bufora” (lub „niedopełnienia bufora”).
Przypisania, które są bliższe błędowi (pod względem czasu lub przestrzeni), są uważane za bardziej prawdopodobne niż te, które są daleko.
Ponieważ pamięć zwalna jest często używana ponownie, a liczba różnych wartości tagów jest niewielka (mniej niż 16), często można znaleźć kilka prawdopodobnych kandydatów, ale nie ma możliwości automatycznego znalezienia prawdziwej przyczyny. Z tego powodu raporty MTE mogą zawierać kilka możliwych przyczyn.
Deweloperowi aplikacji zalecamy, aby zaczął od najprawdopodobniejszej przyczyny. Na podstawie ścieżki śledzenia często łatwo odfiltrować niezwiązane przyczyny.
MTE w trybie asynchronicznym
W trybie asynchronicznym (ang. „async”) MTE powoduje awarię SIGSEGV z kodem 8 (SEGV_MTEAERR).
Błędy SEGV_MTEAERR nie występują natychmiast, gdy program wykonuje nieprawidłowy dostęp do pamięci. Problem jest wykrywany wkrótce po zdarzeniu i w tym momencie program jest zamykany. Jest to zwykle kolejny wywołanie systemu, ale może to być też przerwanie zegara – krótko mówiąc, dowolne przejście z przestrzeni użytkownika do jądra.
Błędy SEGV_MTEAERR nie zachowują adresu pamięci (zawsze jest on wyświetlany jako „-------”). Zrzut stosu odpowiada momentowi wykrycia warunku (czyli następnemu wywołaniu systemowemu lub innej zmianie kontekstu), a nie chwili, w której wykonano nieprawidłowy dostęp.
Oznacza to, że „główny” ślad wsteczny w przypadku awarii asynchronicznej MTE zwykle nie jest istotny. Dlatego błędy w trybie asynchronicznym są znacznie trudniejsze do debugowania niż błędy w trybie synchronicznym. Najlepiej interpretować je jako wskazujące na błąd pamięci w pobliższym kodzie w danym wątku. Dzienniki u dołu pliku sekcji mogą wskazywać, co się stało. W przeciwnym razie zalecamy odtworzenie błędu w trybie synchronizacji i skorzystanie z lepszej diagnostyki, którą zapewnia ten tryb.
Zaawansowane tematy
Tagowanie pamięci działa poprzez przypisywanie losowej wartości tagu 4-bitowego (0..15) do każdej alokacji stosu. Ta wartość jest przechowywana w specjalnym regionie metadanych, który odpowiada zarezerwowanej pamięci stosu. Ta sama wartość jest przypisywana do najbardziej znaczącego bajtu wskaźnika stosu zwracanego przez funkcje takie jak malloc() lub operator new().
Gdy w procesie jest włączone sprawdzanie tagów, procesor automatycznie porównuje najwyższy bajt wskaźnika z tagiem pamięci przy każdym dostępie do pamięci. Jeśli tagi się nie zgadzają, procesor sygnalizuje błąd, który powoduje awarię.
Ze względu na ograniczoną liczbę możliwych wartości tagów to podejście jest oparte na prawdopodobieństwie. Każda lokalizacja pamięci, do której nie powinien być uzyskiwany dostęp za pomocą danego wskaźnika (np. poza zakresem lub po zwolnieniu pamięci – „wiszący wskaźnik”) prawdopodobnie ma inną wartość tagu i może spowodować awarię. Istnieje około 7% szansa, że nie zostanie wykryty żaden przypadek błędu. Wartości tagów są przypisywane losowo, więc istnieje niezależne 93% szansa na wykrycie błędu przy następnym jego wystąpieniu.
Wartości tagów można zobaczyć w polu adresu błędu oraz w pliku zrzutu rejestru, jak pokazano poniżej. W tej sekcji możesz sprawdzić, czy tagi są prawidłowo skonfigurowane, a także zobaczyć inne przyległe przydzielenia pamięci z tą samą wartością tagu, które mogą być potencjalnymi przyczynami błędów oprócz tych wymienionych w raporcie. Spodziewamy się, że ta funkcja będzie przydatna głównie dla osób pracujących nad implementacją MTE lub innych niskiego poziomu komponentów systemu, a nie deweloperów.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
W raporcie o awarii pojawia się też specjalna sekcja „Tagi pamięci”, która zawiera tagi pamięci wokół adresu błędu. W przykładzie poniżej tag wskaźnika „4” nie pasuje do tagu pamięci „a”.
Memory tags around the fault address (0x0400007b43063db5), one tag per 16 bytes: 0x7b43063500: 0 f 0 2 0 f 0 a 0 7 0 8 0 7 0 e 0x7b43063600: 0 9 0 8 0 5 0 e 0 f 0 c 0 f 0 4 0x7b43063700: 0 b 0 c 0 b 0 2 0 1 0 4 0 7 0 8 0x7b43063800: 0 b 0 c 0 3 0 a 0 3 0 6 0 b 0 a 0x7b43063900: 0 3 0 4 0 f 0 c 0 3 0 e 0 0 0 c 0x7b43063a00: 0 3 0 2 0 1 0 8 0 9 0 4 0 3 0 4 0x7b43063b00: 0 5 0 2 0 5 0 a 0 d 0 6 0 d 0 2 0x7b43063c00: 0 3 0 e 0 f 0 a 0 0 0 0 0 0 0 4 =>0x7b43063d00: 0 0 0 a 0 0 0 e 0 d 0 [a] 0 f 0 e 0x7b43063e00: 0 7 0 c 0 9 0 a 0 d 0 2 0 0 0 c 0x7b43063f00: 0 0 0 6 0 b 0 8 0 3 0 0 0 5 0 e 0x7b43064000: 0 d 0 2 0 7 0 a 0 7 0 a 0 d 0 8 0x7b43064100: 0 b 0 2 0 b 0 4 0 1 0 6 0 d 0 4 0x7b43064200: 0 1 0 6 0 f 0 2 0 f 0 6 0 5 0 c 0x7b43064300: 0 1 0 4 0 d 0 6 0 f 0 e 0 1 0 8 0x7b43064400: 0 f 0 4 0 3 0 2 0 1 0 2 0 5 0 6
Sekcje nagrobka, które pokazują zawartość pamięci wokół wszystkich wartości rejestrów, zawierają też ich wartości tagów.
memory near x10 ([anon:scudo:primary]): 0000007b4304a000 7e82000000008101 000003e9ce8b53a0 .......~.S...... 0700007b4304a010 0000200000006001 0000000000000000 .`... .......... 0000007b4304a020 7c03000000010101 000003e97c61071e .......|..a|.... 0200007b4304a030 0c00007b4304a270 0000007ddc4fedf8 p..C{.....O.}... 0000007b4304a040 84e6000000008101 000003e906f7a9da ................ 0300007b4304a050 ffffffff00000042 0000000000000000 B............... 0000007b4304a060 8667000000010101 000003e9ea858f9e ......g......... 0400007b4304a070 0000000100000001 0000000200000002 ................ 0000007b4304a080 f5f8000000010101 000003e98a13108b ................ 0300007b4304a090 0000007dd327c420 0600007b4304a2b0 .'.}......C{... 0000007b4304a0a0 88ca000000010101 000003e93e5e5ac5 .........Z^>.... 0a00007b4304a0b0 0000007dcc4bc500 0300007b7304cb10 ..K.}......s{... 0000007b4304a0c0 0f9c000000010101 000003e9e1602280 ........."`..... 0900007b4304a0d0 0000007dd327c780 0700007b7304e2d0 ..'.}......s{... 0000007b4304a0e0 0d1d000000008101 000003e906083603 .........6...... 0a00007b4304a0f0 0000007dd327c3b8 0000000000000000 ..'.}...........