Estensione del tagging della memoria ARM (MTE)

Nota: questo documento riguarda l'esecuzione delle app Android in MTE. Per informazioni sull'utilizzo di MTE per lo sviluppo della piattaforma Android, consulta l'AOSP documentazione.

Importante: MTE è uno dei numerosi strumenti disponibili per il debug della memoria e mitigazione dei rischi. Consulta Debug e mitigazione degli errori di memoria per un panoramica di tutti gli strumenti.

Perché MTE?

Bug di sicurezza della memoria, ovvero errori nella gestione della memoria nella programmazione nativa lingue, sono problemi comuni legati al codice. Producono vulnerabilità di sicurezza e di stabilità.

Armv9 ha introdotto l'estensione Arm Memory Tagging (MTE), un hardware che consente di rilevare bug use-after-free e buffer-overflow in il codice nativo.

Verifica la presenza di assistenza

A partire da Android 13, alcuni dispositivi supportano la funzionalità MTE. Per verificare se sul dispositivo è in esecuzione la funzionalità MTE abilitata, esegui questo comando: :

adb shell grep mte /proc/cpuinfo

Se il risultato è Features : [...] mte, il dispositivo è in esecuzione con MTE in un bucket con il controllo delle versioni attivo.

Alcuni dispositivi non abilitano la funzionalità MTE per impostazione predefinita, ma consentono agli sviluppatori di riavviare con Funzionalità MTE attivata. Questa è una configurazione sperimentale non consigliata per utilizzo normale, in quanto potrebbero peggiorare le prestazioni o la stabilità del dispositivo, ma possono è utile per lo sviluppo di app. Per accedere a questa modalità, vai a Opzioni sviluppatore > estensione per il tagging della memoria nell'app Impostazioni. Se questo non è presente, il dispositivo non supporta l'attivazione di MTE in questo modo.

Modalità operative degli MTE

MTE supporta due modalità: SYNC e ASYNC. La modalità SYNC offre una diagnostica migliore ed è quindi più adatta per lo sviluppo, mentre la modalità ASYNC offre prestazioni elevate che ne consentono l'attivazione per le app rilasciate.

Modalità sincrona (SYNC)

Questa modalità è ottimizzata per il debug rispetto alle prestazioni e può essere utilizzato come strumento preciso per il rilevamento di bug, quando si verifica un overhead delle prestazioni superiore accettabile. Se abilitata, la funzionalità MTE SYNC agisce anche come mitigazione della sicurezza.

In caso di mancata corrispondenza dei tag, il processore termina il processo sul carico offensivo o istruzione del negozio con SIGSEGV (con si_code SEGV_MTESERR) e informazioni complete sull'accesso alla memoria e sull'indirizzo in errore.

Questa modalità è utile durante i test come alternativa più rapida a HWASan, che non richiede la ricompilazione del codice, né in produzione, rappresenta una superficie di attacco vulnerabile. Inoltre, quando la modalità ASYNC (descritta sotto) ha rilevato è possibile ottenere una segnalazione di bug accurata utilizzando le API runtime per in modalità SYNC.

Inoltre, quando è in esecuzione in modalità SYNC, l'allocatore Android registra dell'analisi dello stack di ogni allocazione e deallocation e le utilizza per fornire report sugli errori che includono la spiegazione di un errore di memoria, come use-after-free o buffer-overflow e le analisi dello stack della memoria eventi (consulta Informazioni sui report MTE per ulteriori dettagli). Tale i report forniscono informazioni più contestuali e semplificano l'individuazione dei bug risolvere il problema rispetto alla modalità ASYNC.

Modalità asincrona (ASYNC)

Questa modalità è ottimizzata per le prestazioni piuttosto che per l'accuratezza delle segnalazioni di bug e può essere utilizzata per il rilevamento dell'overhead ridotto dei bug di sicurezza della memoria. In caso di mancata corrispondenza dei tag, continua l'esecuzione fino alla voce del kernel più vicina (come una richiesta syscall o timer), in cui termina il processo con SIGSEGV (codice SEGV_MTEAERR) senza registrare l'indirizzo o l'accesso alla memoria con errori.

Questa modalità è utile per mitigare le vulnerabilità di sicurezza della memoria su codebase ben testati dove la densità dei bug di sicurezza della memoria che è nota essere bassa, ottenuta usando la modalità SYNC durante il test.

Abilita MTE

Per un singolo dispositivo

Per gli esperimenti, è possibile usare le modifiche relative alla compatibilità delle app per impostare il valore predefinito valore dell'attributo memtagMode per un'applicazione che non specifica qualsiasi valore nel file manifest (o specifica "default").

Puoi trovarli in Sistema > Avanzate > Opzioni sviluppatore > Per app Modifiche di compatibilità nel menu delle impostazioni globali. Impostazione di NATIVE_MEMTAG_ASYNC o NATIVE_MEMTAG_SYNC attiva la funzionalità MTE per una determinata applicazione.

In alternativa, può essere impostato utilizzando il comando am come segue:

• Per la modalità SYNC: $ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
• Per la modalità ASYNC: $ adb shell am compat enable NATIVE_MEMTAG_ASYNC my.app.name

A Gradle

Puoi abilitare MTE per tutte le build di debug del tuo progetto Gradle inserendo

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application android:memtagMode="sync" tools:replace="android:memtagMode"/>
</manifest>

in app/src/debug/AndroidManifest.xml. Questa operazione andrà a sostituire il valore memtagMode con sincronizzazione per le build di debug.

In alternativa, puoi abilitare MTE per tutte le build di un buildType personalizzato. Da fare Quindi, crea il tuo tipo buildType e metti XML in app/src/<name of buildType>/AndroidManifest.xml.

Per un APK su qualsiasi dispositivo supportato

La funzionalità MTE è disattivata per impostazione predefinita. Le app che vogliono utilizzare MTE possono Per farlo imposta android:memtagMode nel <application> o <process> nel AndroidManifest.xml.

Avviso: le applicazioni che abilitano la funzionalità MTE devono essere testate accuratamente su un dispositivo compatibile con gli MTE prima di essere spedito sul Play Store. In caso contrario, potrebbero essere scoperti solo bug critici sui dispositivi con funzionalità MTE, che potrebbero danneggiare l'usabilità dell'app.

android:memtagMode=(off|default|sync|async)

Se impostato nel tag <application>, l'attributo influisce su tutti i processi utilizzati dall'applicazione e può essere sostituito per i singoli processi impostando il tag <process>.

Crea con la strumentazione

Importante: le app create con la strumentazione MTE solo a scopo di debug.

Nota: il tagging dello stack MTE è disponibile a partire da Android 14 QPR3.

L'attivazione di MTE come spiegato in precedenza consente di rilevare i bug che causano il danneggiamento della memoria nella heap nativo. Per rilevare il danneggiamento della memoria nello stack, oltre ad abilitare MTE per l'app, il codice deve essere ricreato con la strumentazione. La l'app risultante verrà eseguita solo su dispositivi che supportano la funzionalità MTE.

Importante: assicurati di utilizzare un NDK aggiornato per creare il codice.

Per creare il codice nativo della tua app (JNI) con MTE, segui questi passaggi:

build-ndkMarca

Nel file Application.mk:

APP_CFLAGS := -fsanitize=memtag -fno-omit-frame-pointer -march=armv8-a+memtag
APP_LDFLAGS := -fsanitize=memtag -fsanitize-memtag-mode=sync -march=armv8-a+memtag

Per ogni target nel file CMakeLists.txt:

target_compile_options(${TARGET} PUBLIC -fsanitize=memtag -fno-omit-frame-pointer -march=armv8-a+memtag)
target_link_options(${TARGET} PUBLIC -fsanitize=memtag -fsanitize-memtag-mode=sync -march=armv8-a+memtag)

Esegui l'app

Dopo aver attivato la funzionalità MTE, utilizza e testa la tua app come di consueto. Se si verifica un problema di sicurezza della memoria viene rilevato, la tua app ha un arresto anomalo con una tomba simile a questa (nota SIGSEGV con SEGV_MTESERR per SYNC o SEGV_MTEAERR per ASYNC):

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)
Learn more about MTE reports: https://source.android.com/docs/security/test/memory-safety/mte-report

Per ulteriori dettagli, consulta la sezione Informazioni sui report MTE nella documentazione di AOSP. Tu può anche eseguire il debug dell'app con Android Studio e il debugger si ferma nella che causa un accesso alla memoria non valido.

Utenti avanzati: utilizzo di MTE nell'allocatore personale

Nota: se non sai che stai utilizzando allocatori personalizzati, puoi saltare in questa sezione.

Per utilizzare la funzionalità MTE per la memoria non allocata tramite i normali allocatori di sistema, devi devi modificare l'allocatore per taggare memoria e puntatori.

Le pagine per l'allocatore devono essere allocate utilizzando PROT_MTE nel prot flag di mmap (o mprotect).

Tutte le allocazioni con tag devono essere allineate a 16 byte, poiché i tag possono essere assegnati solo per blocchi da 16 byte (noti anche come granuli).

Quindi, prima di restituire un puntatore, devi utilizzare l'istruzione IRG per generano un tag casuale e lo memorizzano nel puntatore.

Segui queste istruzioni per assegnare un tag alla memoria sottostante:

• STG: esegui il tagging di un singolo granulo da 16 byte
• ST2G: tagga due granuli da 16 byte
• DC GVA: tag cacheline con lo stesso tag

In alternativa, anche le seguenti istruzioni inizializzano la memoria a zero:

• STZG: assegna tag e zero-inizializzano un singolo granello da 16 byte
• STZ2G: il tag e lo zero inizializzano due granuli da 16 byte
• DC GZVA: tag e nessuna inizializzazione della cacheline con lo stesso tag

Tieni presente che queste istruzioni non sono supportate su CPU meno recenti, quindi devi eseguirle in modo condizionale quando la funzionalità MTE è abilitata. Puoi verificare se l'MTE è abilitato per il tuo processo:

#include <sys/prctl.h>

bool runningWithMte() {
      int mode = prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0);
      return mode != -1 && mode & PR_MTE_TCF_MASK;
}

L'implementazione Scudo potrebbe esserti utile come riferimento.

Scopri di più

Per saperne di più, consulta la Guida dell'utente di MTE per sistema operativo Android scritta da Arm.