Awarie SIGSEGV z kodem 9 (SEGV_MTESERR) lub kodem 8 (SEGV_MTEAERR) to błędy w tagowaniu pamięci. Rozszerzenie Memory Tagging Extension (MTE) to Funkcja Armv9 obsługiwana w Androidzie 12 i nowszych. MTE to sprzętowa implementacja tagów pamięci. Zapewnia szczegółową ochronę pamięci w celu wykrywania i ograniczania błędy związane z bezpieczeństwem pamięci.
W C/C++ wskaźnik zwracany z wywołania Malloc(), operatora new() bądź podobnej funkcji może jest używany do uzyskiwania dostępu do pamięci w granicach tego przydziału i tylko wtedy, gdy przydział jest aktywny (nie został zwolniony ani usunięty). MTE jest używane na Androidzie do wykrywania naruszeń ta reguła, w raportach o awariach nazywana jest „Buffer Overflow”/„Buffer Underflow”. oraz „Użyj po bezpłatnie” problemów.
MTE ma 2 tryby: synchroniczny (lub „synchroniczny”) i asynchroniczny (lub „asynchroniczny”). Poprzedni działa więcej wolniej, ale dostarcza dokładniejszych danych diagnostycznych. To drugie rozwiązanie działa szybciej, ale daje szczegóły przybliżone. Omówimy oba te rodzaje oddzielnie, ponieważ diagnostyka jest nieco inna.
Tryb synchroniczny MTE
W trybie synchronicznym („synchronizacji”) 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 awariach MTE zawierają zwykły zrzut rejestru i ślad wsteczny w miejscu, w którym – wykryto problem. „Przyczyna:” wiersz kodu błędu wykrytego przez MTE będzie zawierać „[MTE]” na przykład przykładu powyżej i przekazać więcej szczegółów. W tym przypadku – typowym rodzajem wykrytego błędu „Użyj po bezpłatnym” i „0 bajtów do przydziału 32 bajtów 0x7ae92853a0”. opowiada nam rozmiar i adres alokacji oraz przesunięcie do alokacji, do której próbowaliśmy uzyskać dostęp.
Raporty o awariach MTE zawierają też dodatkowe ślady, nie tylko te z miejsca wykrycia.
„Użyj po bezpłatnie” Błędy dodaj „przeniesiono przez” i „przydzielone przez” do zrzutu pamięci podręcznej, pokazuje zrzuty stosu w momencie przydzielenia tej pamięci (przed jej użyciem). podczas jego poprzedniego przydziału. Dowiesz się z nich również, który wątek przydzielanie środków. Wszystkie 3 wykrywanie wątku, przydzielanie wątku i przydzielanie alokacji są takie same w tym prostym przykładzie, ale w bardziej złożonych przypadkach koniecznie prawda, a świadomość, że się różnią, może być ważną wskazówką przy wyborze w Google Analytics.
„Buffer Overflow” i „Buffer Underflow” wyświetlają się tylko dodatkowe pola „przydzielone przez” śledzenie stosu, ponieważ z definicji nie zostały jeszcze przypisane (lub byłyby wyświetlane „Użyj po bezpłatnym”):
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 „prawo” tutaj: oznacza to, że podajemy liczbę bajtów po zakończeniu przydziału nieprawidłowego dostępu: niedomiennie oznaczałoby „w lewo” i byłby liczbą bajtów przed rozpoczęciem alokacji.
Wiele potencjalnych przyczyn
Czasami raporty SEGV_MTESERR zawierają następujący wiersz:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Dzieje się tak, gdy jest kilku dobrych kandydatów na źródło błędu i nie możemy określić, co jest prawdziwą przyczyną. Drukujemy maksymalnie 3 takich kandydatów w przybliżonej kolejności według prawdopodobieństwa. a użytkownikom pozostaw zakres analizy.
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 przydziały z tym samym adresem pamięci, były zamierzonym celem nieprawidłowego dostępu do pamięci. Może się tak zdarzyć, gdy przydziały zostaną ponownie użyte wolnej pamięci – jeśli na przykład masz sekwencję „new”, „free”, „new, free”, „new”, „free”, dostęp. Jako pierwszy jest drukowany najnowszy przydział.
Szczegółowa heurystyka do określania przyczyn
„Przyczyna” powinna pokazywać alokację pamięci, z której został pierwotnie uzyskany wskaźnik dostępu. Niestety sprzęt MTE nie ma możliwości przekształcenia go ze wskaźnika z niezgodnym tagiem na przydział. Aby wyjaśnić awarię SEGV_MTESERR, Android analizuje te dane:
- Adres błędu (wraz z tagiem wskaźnika).
- Lista ostatnich alokacji sterty ze zrzutami stosu i tagami pamięci.
- Bieżące (aktywne) przydziały w pobliżu i ich tagi pamięci.
Ostatnio przydzielona pamięć pod adresem błędu, w przypadku którego tag pamięci pasuje do tagu z adresem błędu, może zostać uznana za „Użyj po zwolnieniu” przyczyna.
Każda pobliska aktywna pamięć, w której tag pamięci pasuje do tagu adresu błędu, jest potencjalnym „przepełnieniem bufora” (lub „Niedostateczne bufory”).
Przydziały, które są bliżej błędu – w czasie lub w przestrzeni – są uważane za bardziej prawdopodobne niż te, które są oddalone.
Ponieważ przydzielona pamięć jest często wykorzystywana ponownie, a liczba różnych wartości tagów jest niewielka (poniżej 16), nierzadko zdarza się znaleźć kilka potencjalnych kandydatów i nie ma sposobu na automatyczne znalezienie prawdziwej przyczyny. To dlatego czasami raporty MTE zawierają wiele potencjalnych przyczyn.
Zalecamy, aby deweloper aplikacji sprawdził potencjalne przyczyny, zaczynając od najbardziej prawdopodobnej. Często łatwo jest odfiltrować niepowiązane przyczyny na podstawie zrzutu stosu.
Tryb asynchroniczny MTE
W trybie asynchronicznym MTE SIGSEGV ulega awarii z kodem 8 (SEGV_MTEAERR).
Błędy SEGV_MTEAERR nie występują natychmiast, gdy program wykona nieprawidłowy dostęp do pamięci. Problem zostaje wykryty krótko po wydarzeniu i wtedy program zostaje zakończony. Zazwyczaj jest to następne wywołanie systemowe, ale może to też być przerwa w czasie – w skrócie – każde przejście między przestrzenią użytkownika a jądro.
Błędy SEGV_MTEAERR nie zachowują adresu pamięci (jest on zawsze wyświetlany jako „-------”). Ślad wsteczny odpowiada momentowi wykrycia warunku (tj. przy następnym wywołaniu systemu lub innym przełączeniu kontekstowym), a nie momentowi, w którym wykonano nieprawidłowy dostęp.
Oznacza to, że strona główna śledzenie wsteczne w asynchronicznej awarii MTE jest zwykle nieistotne. Dlatego też błędy trybu asynchronicznego są znacznie trudniejsze do debugowania niż błędy trybu synchronizacji. Najlepiej je rozumieć jako przedstawienie błędu pamięci w pobliskim kodzie w danym wątku. Dzienniki znajdujące się na dole pliku tombstone mogą wskazywać, co rzeczywiście się stało. W przeciwnym razie zalecamy odtworzenie błędu w trybie synchronizacji i skorzystanie z lepszej diagnostyki w trybie synchronizacji.
Tematy zaawansowane
Mechanizm działania tagowania pamięci polega na przypisywaniu losowej 4-bitowej (0..15) wartości tagu do każdego przydziału sterty. Ta wartość jest przechowywana w specjalnym regionie metadanych, który odpowiada przydzielonej pamięci stosu. Ta sama wartość jest przypisywana do najbardziej istotnego bajtu wskaźnika sterty zwróconego przez funkcje takie jak Malloc() lub operator new().
Gdy sprawdzanie tagów jest w tym procesie włączone, procesor automatycznie porównuje górny bajt wskaźnika z tagiem pamięci przy każdym dostępie do pamięci. Jeśli tagi są niezgodne, procesor sygnalizuje błąd, który prowadzi do awarii.
Ze względu na ograniczoną liczbę możliwych wartości tagów ta metoda jest prawdopodobnie bardziej prawdopodobna. Każda lokalizacja pamięci, do której nie należy uzyskiwać dostępu za pomocą danego wskaźnika, np. poza granicami lub po przydzieleniu lokalizacji („zmienny wskaźnik”), prawdopodobnie będzie mieć inną wartość tagu i spowoduje awarię. Prawdopodobieństwo, że nie wykryjemy żadnego wystąpienia błędu, wynosi ok. 7%. Wartości tagów są przypisywane losowo, więc istnieje niezależne 93% szans na wykrycie następnego błędu następnym razem.
Wartości tagów można zobaczyć w polu adresu błędu oraz w zrzucie rejestru, jak zaznaczono poniżej. W tej sekcji możesz sprawdzić, czy tagi są prawidłowo skonfigurowane, a także zobaczyć inne pobliskie przydziały pamięci z tą samą wartością tagu, ponieważ mogą być potencjalnymi przyczynami błędów innych niż wymienione w raporcie. Spodziewamy się, że będzie to przydatne głównie dla osób pracujących nad wdrażaniem MTE lub innych komponentów systemu niskiego poziomu, a nie dla programistó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
Specjalne „Tagi pamięci” jest również widoczna w raporcie o awariach, który 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, w których widać zawartość pamięci wokół wszystkich wartości rejestru, również wyświetlają 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 ..'.}...........