Awarie SIGSEGV z kodem 9 (SEGV_MTESERR) lub kodem 8 (SEGV_MTEAERR) są błędami znakowania pamięci. Rozszerzenie tagowania pamięci (MTE) to funkcja Armv9 obsługiwana w systemie Android 12 i nowszych wersjach. MTE to sprzętowa implementacja pamięci znacznikowej. Zapewnia drobnoziarnistą ochronę pamięci w celu wykrywania i łagodzenia błędów związanych z bezpieczeństwem pamięci .
W C/C++ wskaźnik zwrócony przez wywołanie funkcji malloc() lub operatora new() lub podobnych funkcji może być używany tylko w celu uzyskania dostępu do pamięci w granicach tej alokacji i tylko wtedy, gdy alokacja jest aktywna (nie jest zwolniona ani usunięto). MTE jest używane w systemie Android do wykrywania naruszeń tej zasady, określanych w raportach o awariach jako problemy „Przepełnienie bufora”/„Niedopełnienie bufora” i „Użyj po zwolnieniu”.
MTE ma dwa tryby: synchroniczny (lub „synchronizowany”) i asynchroniczny (lub „asynchroniczny”). Ten pierwszy działa wolniej, ale zapewnia dokładniejszą diagnostykę. Ten ostatni działa szybciej, ale może podać jedynie przybliżone szczegóły. Omówimy oba osobno, ponieważ diagnostyka jest nieco inna.
Tryb synchroniczny MTE
W trybie synchronicznym („sync”) 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 awariach MTE zawierają zwykły zrzut rejestru i ślad wsteczny dla punktu, w którym wykryto problem. Linia „Przyczyna:” dotycząca błędu wykrytego przez MTE będzie zawierać „[MTE]”, jak w powyższym przykładzie, wraz z dodatkowymi szczegółami. W tym przypadku konkretnym rodzajem wykrytego błędu było „Użyj po zwolnieniu”, a „0 bajtów w 32-bajtowej alokacji pod adresem 0x7ae92853a0” mówi nam o rozmiarze i adresie alokacji oraz przesunięciu w alokacji, które mamy próbowałem uzyskać dostęp.
Raporty o awariach MTE zawierają także dodatkowe ślady, nie tylko te z punktu wykrycia.
Błędy „Użyj po zwolnieniu” dodają sekcje „cofnięte przez” i „przydzielone przez” do zrzutu awaryjnego, pokazując ślady stosu w momencie zwolnienia tej pamięci (zanim została użyta!) oraz czas, w którym została wcześniej przydzielona. Informują one również, który wątek dokonał alokacji/cofnięcia alokacji. Wszystkie trzy wątki: wątek wykrywający, wątek alokujący i wątek zwalniający alokację są takie same w tym prostym przykładzie, ale w bardziej złożonych przypadkach w świecie rzeczywistym niekoniecznie jest to prawdą, a wiedza o tym, że się różnią, może być ważną wskazówką w znalezieniu współbieżności -błąd związany.
Błędy „Przepełnienie bufora” i „Niedopełnienie bufora” zapewniają jedynie dodatkową ścieżkę stosu „przydzieloną przez”, ponieważ z definicji nie zostały jeszcze cofnięte (lub pojawiłyby się jako „Użyj 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 tutaj słowa „prawo”: oznacza to, że informujemy, ile bajtów po zakończeniu alokacji miał nieprawidłowy dostęp; niedopełnienie oznaczałoby „w lewo” i oznaczałoby 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 istnieje kilka dobrych kandydatów na źródło błędu i nie możemy określić, która jest rzeczywistą przyczyną. Drukujemy do 3 takich kandydatów w przybliżonej kolejności 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 dwie ostatnie alokacje pod tym samym adresem pamięci, które mogły być zamierzonym celem nieprawidłowego dostępu do pamięci. Może się to zdarzyć, gdy alokacje ponownie wykorzystują wolną pamięć - na przykład, jeśli masz sekwencję taką jak nowy, wolny, nowy, wolny, nowy, wolny, dostęp. Najpierw drukowana jest nowsza alokacja.
Szczegółowe heurystyki ustalania przyczyn
„Przyczyna” awarii powinna wskazywać alokację pamięci, z której pierwotnie pochodził wskaźnik, do którego uzyskano dostęp. Niestety sprzęt MTE nie ma możliwości przetłumaczenia wskaźnika z niedopasowanym znacznikiem na alokację. Aby wyjaśnić awarię SEGV_MTESERR, Android analizuje następujące dane:
- Adres błędu (w tym znacznik wskaźnika).
- Lista ostatnich alokacji sterty ze śladami stosu i znacznikami pamięci.
- Pobliskie aktualne (na żywo) przydziały i ich znaczniki pamięci.
Jakakolwiek ostatnio zwolniona pamięć pod adresem błędu, w której znacznik pamięci odpowiada znacznikowi adresu błędu, jest potencjalną przyczyną „Użyj po zwolnieniu”.
Każda pobliska pamięć czynna, w której znacznik pamięci odpowiada znacznikowi adresu błędu, jest potencjalną przyczyną „przepełnienia bufora” (lub „niedopełnienia bufora”).
Przydziały znajdujące się bliżej uszkodzenia – zarówno w czasie, jak i w przestrzeni – są uważane za bardziej prawdopodobne niż te, które są daleko.
Ponieważ zwolniona pamięć jest często ponownie wykorzystywana, a liczba różnych wartości znaczników jest niewielka (mniej niż 16), nierzadko zdarza się znaleźć kilku prawdopodobnych kandydatów i nie ma możliwości automatycznego znalezienia prawdziwej przyczyny. Z tego powodu czasami raporty MTE wymieniają wiele potencjalnych przyczyn.
Zaleca się, aby twórca aplikacji sprawdził potencjalne przyczyny, zaczynając od najbardziej prawdopodobnej. Często łatwo jest odfiltrować niepowiązane przyczyny na podstawie śladu stosu.
Tryb asynchroniczny MTE
W trybie asynchronicznym („asynchronicznym”) MTE SIGSEGV ulega awarii z kodem 8 (SEGV_MTEAERR).
Błędy SEGV_MTEAERR nie pojawiają się natychmiast, gdy program wykonuje nieprawidłowy dostęp do pamięci. Problem zostaje wykryty wkrótce po zdarzeniu i w tym momencie program zostaje zakończony. Ten punkt jest zazwyczaj następnym wywołaniem systemowym, ale może to być również przerwanie czasowe - w skrócie dowolne przejście z przestrzeni użytkownika do jądra.
Błędy SEGV_MTEAERR nie zachowują adresu pamięci (jest on zawsze wyświetlany jako „-------”). Ślad zwrotny odpowiada momentowi wykrycia warunku (tj. przy następnym wywołaniu systemowym lub innym przełączeniu kontekstu), a nie momencie wykonania nieprawidłowego dostępu.
Oznacza to, że „główny” ślad w asynchronicznej awarii MTE zwykle nie jest istotny . Awarie trybu asynchronicznego są zatem znacznie trudniejsze do debugowania niż awarie trybu synchronizacji. Najlepiej rozumieć je jako pokazujące istnienie błędu pamięci w pobliskim kodzie w danym wątku. Dzienniki znajdujące się na dole pliku nagrobka mogą stanowić wskazówkę dotyczącą tego, co faktycznie się wydarzyło. W przeciwnym razie zalecanym sposobem działania jest odtworzenie błędu w trybie synchronizacji i skorzystanie z lepszej diagnostyki, jaką zapewnia tryb synchronizacji!
Zaawansowane tematy
Pod maską tagowanie pamięci działa poprzez przypisanie losowej 4-bitowej (0..15) wartości znacznika do każdej alokacji sterty. Ta wartość jest przechowywana w specjalnym obszarze metadanych, który odpowiada przydzielonej pamięci sterty. Ta sama wartość jest przypisana do najbardziej znaczącego bajtu wskaźnika sterty zwracanego przez funkcje takie jak malloc() lub operator new().
Gdy w procesie włączone jest sprawdzanie znaczników, procesor automatycznie porównuje górny bajt wskaźnika ze znacznikiem pamięci przy każdym dostępie do pamięci. Jeśli tagi nie są zgodne, procesor sygnalizuje błąd, który prowadzi do awarii.
Ze względu na ograniczoną liczbę możliwych wartości znaczników podejście to jest probabilistyczne. Każda lokalizacja pamięci, do której nie należy uzyskać dostępu za pomocą danego wskaźnika – na przykład poza zakresem lub po dezalokacji („wiszący wskaźnik”) – prawdopodobnie będzie miała inną wartość znacznika i spowoduje awarię. Istnieje ~7% szans na niewykrycie żadnego pojedynczego wystąpienia błędu. Ponieważ wartości znaczników są przypisywane losowo, istnieje niezależna szansa na wykrycie błędu przy następnym wystąpieniu wynosząca ~93%.
Wartości znaczników można zobaczyć w polu adresu błędu, jak również w zrzucie rejestru, jak podkreślono poniżej. W tej sekcji można sprawdzić, czy znaczniki są ustawione w rozsądny sposób, a także zobaczyć inne pobliskie alokacje pamięci o tej samej wartości znacznika, ponieważ mogą one być potencjalnymi przyczynami błędu poza wymienionymi w raporcie. Oczekujemy, że będzie to przydatne głównie dla osób pracujących nad wdrożeniem samego 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
W raporcie o awarii pojawia się także specjalna sekcja „Znaczniki pamięci”, która pokazuje znaczniki pamięci wokół adresu błędu. W poniższym przykładzie znacznik wskaźnika „4” nie pasuje do znacznika 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, wyświetlają również ich wartości znacznikó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 ..'.}...........