Gli arresti anomali SIGSEGV con codice 9 (SEGV_MTESERR) o codice 8 (SEGV_MTEAERR) sono errori di tagging della memoria. Memory Tagging Extension (MTE) è una funzionalità Armv9 supportata in Android 12 e versioni successive. MTE è un'implementazione hardware della memoria con tag. Fornisce una protezione della memoria granulare per il rilevamento e la mitigazione dei bug di sicurezza della memoria.
In C/C++, un puntatore restituito da una chiamata a malloc() o all'operatore new() o a funzioni simili può essere utilizzato solo per accedere alla memoria entro i limiti di quell'allocazione e solo finché l'allocazione è attiva (non è stata liberata o eliminata). MTE viene utilizzato in Android per rilevare violazioni di questa regola, indicate nei report sugli arresti anomali come "Overflow del buffer"/"Underflow del buffer" e problemi di "Uso dopo svuotamento".
MTE ha due modalità: sincrona (o "sync") e asincrona (o "async"). Il primo è più lento, ma fornisce una diagnostica più accurata. Quest'ultimo è più veloce, ma può fornire solo dettagli approssimativi. Le tratteremo entrambe separatamente, poiché la diagnostica è leggermente diversa.
MTE in modalità sincrona
Nella modalità sincrona ("sync") di MTE, SIGSEGV si arresta in modo anomalo con il codice 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)
Tutti i report sugli arresti anomali di MTE contengono il solito dump del registro e il backtrace per il punto in cui è stato rilevato il problema. La riga "Causa:" per un errore rilevato da MTE conterrà "[MTE]" come nell'esempio precedente, insieme a ulteriori dettagli. In questo caso, il tipo specifico di errore rilevato è stato un "utilizzo dopo il rilascio" e "0 byte in un'allocazione di 32 byte in 0x7ae92853a0" indica le dimensioni e l'indirizzo dell'allocazione, nonché l'offset nell'allocazione a cui abbiamo provato ad accedere.
I report sugli arresti anomali di MTE includono anche backtrace aggiuntivi, non solo quello dal punto di rilevamento.
Gli errori "Uso dopo svuotamento" aggiungono le sezioni "deallocata da" e "allocata da" al dump dell'arresto anomalo, mostrando le tracce dello stack al momento della deallocazione di questa memoria (prima che venisse utilizzata) e il momento in cui è stata allocata in precedenza. Ti indicano anche quale thread ha eseguito l'allocazione/deallocazione. In questo semplice esempio, i tre thread di rilevamento, di allocazione e di deallocazione sono uguali, ma in casi reali più complessi non è necessariamente così e sapere che sono diversi può essere un indizio importante per trovare un bug correlato alla concorrenza.
Gli errori "Overflow del buffer" e "Underflow del buffer" forniscono solo un canale aggiuntivo della traccia dello stack "allocato da", poiché per definizione non sono ancora stati deallocati (oppure apparirebbero come "Uso dopo svuotamento"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Nota l'uso della parola "destra" qui: significa che ti stiamo dicendo quanti byte oltre la fine dell'allocazione sono stati oggetto dell'accesso errato. In caso di sottoflusso, viene visualizzato il messaggio "sinistra" e viene indicato un numero di byte prima dell'inizio dell'allocazione.
Più cause potenziali
A volte i report SEGV_MTESERR contengono la seguente riga:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Questo accade quando ci sono diversi candidati validi per l'origine dell'errore e non possiamo dire quale sia la causa effettiva. Stampiamo fino a tre candidati di questo tipo in ordine approssimativo di probabilità e lasciamo all'utente l'analisi.
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...]Nell'esempio riportato sopra, abbiamo rilevato due allocazioni recenti nello stesso indirizzo di memoria che potrebbero essere stati il bersaglio previsto dell'accesso alla memoria non valido. Questo può accadere quando le allocazioni riutilizzano la memoria libera, ad esempio se hai la sequenza nuova, libera, nuova, libera, nuova, libera, accesso. L'allocazione più recente viene stampata per prima.
Euristiche dettagliate per la determinazione della causa
La "Causa" di un arresto anomalo dovrebbe mostrare l'allocazione della memoria da cui è stato originariamente derivato il puntatore a cui è stato eseguito l'accesso. Purtroppo, l'hardware MTE non ha modo di tradurre da un puntatore con un tag non corrispondente a un'allocazione. Per spiegare un arresto anomalo SEGV_MTESERR, Android analizza i seguenti dati:
- L'indirizzo dell'errore (incluso il tag del cursore).
- Un elenco di allocazioni dell'heap recenti con tracce dello stack e tag di memoria.
- Le allocazioni attuali (live) nelle vicinanze e i relativi tag di memoria.
Qualsiasi memoria deallocata di recente all'indirizzo dell'errore in cui il tag della memoria corrisponde al tag dell'indirizzo dell'errore è una potenziale causa di "uso dopo sblocco".
Qualsiasi memoria attiva nelle vicinanze in cui il tag della memoria corrisponde al tag dell'indirizzo dell'errore è una potenziale causa di "Overflow del buffer" (o "Underflow del buffer").
Le allocazioni più vicine all'errore, in termini di tempo o spazio, sono considerate più probabili di quelle lontane.
Poiché la memoria deallocata viene spesso riutilizzata e il numero di valori dei tag diversi è ridotto (meno di 16), non è raro trovare diversi candidati probabili e non esiste un modo per trovare automaticamente la causa reale. Questo è il motivo per cui a volte i report MTE elencano più potenziali cause.
Lo sviluppatore di app è invitato a esaminare le potenziali cause, iniziando dalla più probabile. Spesso è facile escludere le cause non correlate in base alla traccia dello stack.
MTE in modalità asincrona
Nella modalità asincrona ("async") di MTE, SIGSEGV si arresta in modo anomalo con il codice 8 (SEGV_MTEAERR).
Gli errori SEGV_MTEAERR non si verificano immediatamente quando un programma esegue un accesso alla memoria non valido. Il problema viene rilevato poco dopo l'evento e il programma viene terminato in quel momento. In genere questo punto è la chiamata di sistema successiva, ma può anche essere un'interruzione del timer, in breve qualsiasi transizione dallo spazio utente al kernel.
Gli errori SEGV_MTEAERR non mantengono l'indirizzo di memoria (viene sempre visualizzato come "-------"). La backtrace corrisponde al momento in cui è stata rilevata la condizione (ad es. alla chiamata di sistema successiva o a un altro cambio di contesto) e non al momento in cui è stato eseguito l'accesso non valido.
Ciò significa che il backtrace "principale" in un arresto anomalo MTE asincrono in genere non è pertinente. Di conseguenza, gli errori in modalità asincrona sono molto più difficili da eseguire il debug rispetto agli errori in modalità sincrona. È meglio considerarli come indicatori dell'esistenza di un bug di memoria nel codice nelle vicinanze del thread in questione. I log nella parte inferiore del file tombstone possono fornire un indizio su cosa è successo. In caso contrario, il corso di azione consigliato è riprodurre l'errore in modalità di sincronizzazione e utilizzare la diagnostica migliore offerta da questa modalità.
Argomenti avanzati
Sotto il cofano, il tagging della memoria funziona assegnando un valore di tag casuale di 4 bit (0..15) a ogni allocazione dell'heap. Questo valore viene memorizzato in una regione di metadati speciale che corrisponde alla memoria heap allocata. Lo stesso valore viene assegnato al byte più significativo del puntatore all'heap restituito da funzioni come malloc() o operator new().
Quando il controllo dei tag è attivato nel processo, la CPU confronta automaticamente il byte superiore del puntatore con il tag di memoria per ogni accesso alla memoria. Se i tag non corrispondono, la CPU segnala un errore che causa un arresto anomalo.
A causa del numero limitato di possibili valori dei tag, questo approccio è probabilistico. Qualsiasi posizione di memoria a cui non deve essere eseguito l'accesso con un determinato puntatore, ad esempio fuori intervallo o dopo la deallocazione ("puntatore inutilizzato"), ha probabilmente un valore del tag diverso e causa un arresto anomalo. Esiste una probabilità del 7% circa di non rilevare alcuna occorrenza di un bug. Poiché i valori dei tag vengono assegnati in modo casuale, esiste una probabilità indipendente del 93% di rilevare il bug la volta successiva che si verifica.
I valori dei tag sono visibili nel campo dell'indirizzo dell'errore e nel dump del registro, come evidenziato di seguito. Questa sezione può essere utilizzata per verificare che i tag siano impostati in modo corretto, nonché per vedere altre allocazioni di memoria nelle vicinanze con lo stesso valore del tag, in quanto potrebbero essere potenziali cause dell'errore oltre a quelle elencate nel report. Ci aspettiamo che questa funzionalità sia utile principalmente per le persone che si occupano dell'implementazione dell'MTE stesso o di altri componenti di sistema di basso livello, piuttosto che per gli sviluppatori.
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
Nel report sugli arresti anomali viene visualizzata anche una sezione speciale "Tag memoria" che mostra i tag memoria intorno all'indirizzo dell'errore. Nell'esempio seguente, il tag del cursore "4" non corrisponde al tag della memoria "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
Le sezioni di una pietra tombale che mostrano i contenuti della memoria intorno a tutti i valori dei registri mostrano anche i valori dei tag.
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 ..'.}...........