Informazioni sui report HWASan

Quando lo strumento HWASan rileva un bug di memoria, il processo viene terminato con abort(). viene stampato un report in stderr e logcat. Come per tutti gli arresti anomali nativi su Android, gli errori HWASan possono essere trovato in /data/tombstones.

Rispetto ai normali arresti anomali nativi, HWASan trasporta informazioni aggiuntive nel campo "Interrompi messaggio" vicino alla parte superiore della lapide. Guarda un esempio di arresto anomalo basato su heap riportato di seguito (per gli stack bug, consulta la nota seguente per le sezioni specifiche dello stack).

Report di esempio

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/flame_hwasan/flame:Tiramisu/MASTER/7956676:userdebug/dev-keys'
Revision: 'DVT1.0'
ABI: 'arm64'
Timestamp: 2019-04-24 01:13:22+0000
pid: 11154, tid: 11154, name: sensors@1.0-ser  >>> /vendor/bin/hw/android.hardware.sensors@1.0-service <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: '

[...]

[0x00433ae20040,0x00433ae20060) is a small unallocated heap chunk; size: 32 offset: 5








[ … regular crash dump follows …]

Questo risultato è molto simile a quello di un report AddressSanitizer. A differenza di questi, quasi tutti i bug HWASan sono "tag-mismatch", ovvero un accesso alla memoria in cui un tag puntatore non corrisponde al tag di memoria corrispondente. Potrebbe essere uno di

  • accesso fuori dai limiti su stack o heap
  • usare dopo senza costi su heap
  • da utilizzare dopo il ritorno sullo stack

Sezioni

Di seguito è riportata la spiegazione di ciascuna delle sezioni del report HWASan:

Errore di accesso

Contiene informazioni sull'accesso errato alla memoria, tra cui:

  • Tipo di accesso ("READ" e "WRITE")
  • Dimensioni di accesso (quanti byte è stato tentato di accedere)
  • Numero di thread dell'accesso
  • Tag puntatore e di memoria (per il debug avanzato)

Accedi all'analisi dello stack

Analisi dello stack dell'accesso alla memoria non valido. Consulta la sezione sulla simbolizzazione per simbolizzare.

Causa

La potenziale causa dell'accesso non valido. Se ci sono più candidati, sono elencate in ordine decrescente di probabilità. Precede le informazioni dettagliate sul causa potenziale. HWASan può diagnosticare le seguenti cause:

  • uso-dopo-senza costi
  • stack tag-mismatch: può essere stack use-after-return / use after-scope oppure fuori intervallo
  • overflow del buffer
  • overflow-globale

Informazioni sulla memoria

Descrive cosa sa HWASan della memoria a cui si accede e può differire in base alla tipo di bug.

Tipo di insetto Causa Formato del report
mancata corrispondenza dei tag uso-dopo-senza costi 
<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:
overflow del buffer Tieni presente che può trattarsi anche di un flusso insufficiente. 
<address> is located N bytes to the right of M-byte region [<start>, <end>)
  allocated here:
mancata corrispondenza del tag stack I report sullo stack non fanno distinzione tra overflow/underflow e e i bug use-after-return. Nella Inoltre, per trovare l'allocazione dello stack che ha dato origine all'errore, offline il passaggio di simbolizzazione è obbligatorio. Consulta la sezione Informazioni sui report sullo stack. di seguito.
non valido-libero uso-dopo-senza costi Questo è un doppio bug senza costi. Se ciò si verifica alla chiusura del processo, potrebbe significare Violazione ODR. 
<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:
impossibile descrivere l'indirizzo O Wild Free (privo di memoria che non era mai stata allocata in precedenza) o doppio senza costi dopo che la memoria allocata è stata rimossa dal buffer libero di HWASan.
0x... è la memoria d'ombra di HWAsan. Si tratta sicuramente di un'offerta totalmente senza costi, perché l'app stava tentando che è a HWASan.

Analisi dello stack di deallocation

Analisi dello stack della posizione in cui è stata collocata la memoria. Presenti solo dopo l'uso o bug non validi. Consulta la sezione Simbolizzazione per simbolizzare.

Analisi dello stack di allocazione

Analisi dello stack di dove è stata allocata la memoria. Consulta la sezione Simbolizzazione per simbolizzare.

Debug avanzato Informazioni

Il report HWASan presenta anche alcune informazioni di debug avanzate, tra cui: (in ordine):

  1. L'elenco di thread nel processo
  2. L'elenco di thread nel processo
  3. Il valore dei tag di memoria vicini alla memoria con errori
  4. Il dump dei registri nel punto di accesso alla memoria

Dump dei tag di memoria

Il dump della memoria dei tag può essere utilizzato per cercare allocazioni di memoria nelle vicinanze con lo stesso tag come il puntatore del tag. Potrebbero puntare a un accesso fuori dai limiti con un offset elevato. Un tag corrisponde a 16 byte di memoria; il tag puntatore è i primi 8 bit dell'indirizzo. Il dump della memoria dei tag può dai suggerimenti, della ad esempio un overflow del buffer a destra: 

tags: ad/5c (ptr/mem)
[...]
Memory tags around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: 0e  0e  0e  57  20  20  20  20  20  2e  5e  5e  5e  5e  5e  b5
=>0x006f33ae2000: f6  f6  f6  f6  f6  4c  ad  ad  ad  ad  ad  ad [5c] 5c  5c  5c
  0x006f33ae2010: 5c  04  2e  2e  2e  2e  2e  2f  66  66  66  66  66  80  6a  6a
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: ab  52  eb  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
=>0x006f33ae2000: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. [..] ..  ..  ..
  0x006f33ae2010: ..  5c  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
(nota l'esecuzione di 6 × 16 = 96 byte di tag "ad" sulla sinistra che corrispondono al tag puntatore).

Se la dimensione di un'allocazione non è un multiplo di 16, il resto della dimensione sarà archiviato come il di memoria e il tag verrà archiviato come short dei granuli. Nell'esempio precedente, subito dopo l'allocazione in grassetto dell'annuncio, noi hai un 5 × 16 + 4 = allocazione di 84 byte del tag 5c.

Un tag di memoria zero (ad es. tags: ad/00 (ptr/mem)) di solito indica una bug stack-use-after-return.

Registra dump

Il dump del registro nei report HWASan corrisponde all'istruzione effettiva che ha eseguito non valido memoria l'accesso. È seguito da un altro dump del registro dal normale gestore di segnali Android - ignora il la seconda, viene presa quando HWASan chiama abort() e non è pertinente il bug.

Simbolizzazione

Per ottenere nomi di funzioni e numeri di riga nelle analisi dello stack (e ottenere nomi di variabili per use-after-scope ), è necessario un passaggio di simbolizzazione offline.

Configurazione iniziale: installa llvm-symbolizer

Per simbolizzare, nel sistema deve essere installato llvm-symbolizer e accessibile da $PATH. In Debian puoi installarlo utilizzando sudo apt install llvm.

Ottenere i file di simboli

Per la simbolizzazione, sono necessari file binari non sottoposti a striping contenenti simboli. La posizione in cui è possibile trovarli dipende sul tipo di build:

Per le build locali, i file di simboli sono disponibili in out/target/product/<product>/symbols/.

Per le build AOSP (ad esempio eseguite in flash da Flashstation), la classe sono disponibili in CI per Android. Nella sezione "Artefatti" per creare, ci sarà un file ${PRODUCT}-symbols-${BUILDID}.zip.

Per le build interne della tua organizzazione, consulta la documentazione dell'organizzazione per ricevere assistenza recuperare i file di simboli.

Simboleggia

hwasan_symbolize –-symbols <DECOMPRESSED_DIR>/out/target/product/*/symbols < crash

Informazioni sui report sullo stack

Per i bug che si verificano con le variabili stack, il report HWASan conterrà dettagli come questo: 

Cause: stack tag-mismatch
Address 0x007d4d251e80 is located in stack of thread T64
Thread: T64 0x0074000b2000 stack: [0x007d4d14c000,0x007d4d255cb0) sz: 1088688 tls: [0x007d4d255fc0,0x007d4d259000)
Previously allocated frames:
  record_addr:0x7df7300c98 record:0x51ef007df3f70fb0  (/apex/com.android.art/lib64/libart.so+0x570fb0)
  record_addr:0x7df7300c90 record:0x5200007df3cdab74  (/apex/com.android.art/lib64/libart.so+0x2dab74)
  [...]

Per consentire la comprensione degli stack bug, HWASan tiene traccia degli stack frame che si sono verificati in passato. Attualmente, HWASan non trasforma questi contenuti in contenuti comprensibili per l'utente nella segnalazione di bug. richiede un ulteriore passaggio di simbolizzazione.

Violazioni ODR

Alcuni bug segnalati dopo l'uso e segnalati da HWASan possono anche indicare una violazione delle regole ODR (One Definition Rules). Una violazione ODR si verifica quando la stessa variabile viene definita più volte nello stesso programma. Ciò significa anche che la variabile viene distrutta più volte, il che potrebbe portare alla errore use-after-free.

Dopo la simbolizzazione, le violazioni ODR mostrano un uso-after-free con __cxa_finalize, sia sullo stack di accesso non valido sia su "libero qui" stack. Il campo "In precedenza allocato qui" lo stack contiene __dl__ZN6soinfo17call_constructorsEv e dovrebbe puntare alla posizione del programma che definisce la variabile più in alto nell'elenco.

Un motivo per cui l'ODR può essere violato è l'utilizzo di librerie statiche. Se una libreria statica che definisce un C++ globale è collegata a più librerie condivise oppure eseguibili, più definizioni dello stesso simbolo potrebbero essere già presenti nello stesso indirizzo spazio di archiviazione, il che provocherà un errore ODR.

Risoluzione dei problemi

HWAddressSanitizer non può descrivere l'indirizzo in modo più dettagliato

A volte HWASan può esaurire lo spazio per le informazioni sulle allocazioni di memoria passate. In questo caso, il report conterrà solo un'analisi dello stack per l'accesso immediato alla memoria, seguita da una nota:

  HWAddressSanitizer can not describe address in more detail.

In alcuni casi, il problema può essere risolto eseguendo il test più volte. Un'altra opzione è aumentare HWASan dimensioni della cronologia. Ciò può essere fatto a livello globale build/soong/cc/sanitize.go (cerca hwasanGlobalOptions) o nel tuo ambiente di processo (prova adb shell echo $HWASAN_OPTIONS per visualizzare le impostazioni correnti).

Questo può accadere anche se la memoria a cui si accede non è mappata o allocata da un utente non consapevole di HWASan allocatore. In questo caso, il tag mem elencato nell'intestazione dell'arresto anomalo di solito sarà 00. Se hai accesso alla lapide completa, potrebbe essere utile consultare il il dump delle mappe di memoria per scoprire a quale mappatura (se presente) appartiene l'indirizzo.

Bug nidificato nello stesso thread

Ciò significa che si è verificato un bug durante la generazione del report sugli arresti anomali di HWASan. Questo è solitamente dovuto a un bug del runtime HWASan, segnala un bug e fornisci istruzioni su come riprodurre il problema, se possibile.