Estensione del tagging della memoria ARM (MTE)

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

Importante: MTE è uno dei tanti strumenti disponibili per il debugging e la mitigazione della memoria. Consulta Debug e mitigazione degli errori di memoria per una panoramica di tutti gli strumenti.

Perché MTE?

I bug di sicurezza della memoria, ovvero errori nella gestione della memoria nei linguaggi di programmazione nativi, sono problemi comuni del codice. Portano a vulnerabilità di sicurezza e a problemi di stabilità.

Armv9 ha introdotto la funzionalità MTE (Memory Tagging Extension) di Arm, un'estensione hardware che consente di rilevare i bug use-after-free e di overflow del buffer nel codice nativo.

Verificare la presenza di assistenza

A partire da Android 13, alcuni dispositivi supportano MTE. Per verificare se il dispositivo è in esecuzione con MTE abilitato, esegui il seguente comando:

adb shell grep mte /proc/cpuinfo

Se il risultato è Features : [...] mte, il tuo dispositivo è in esecuzione con MTE attivo.

Alcuni dispositivi non attivano MTE per impostazione predefinita, ma consentono agli sviluppatori di riavviare il dispositivo con MTE abilitato. Si tratta di una configurazione sperimentale non consigliata per l'uso normale in quanto potrebbe ridurre le prestazioni o la stabilità del dispositivo, ma può essere utile per lo sviluppo di app. Per accedere a questa modalità, vai a Opzioni sviluppatore > Estensione di tagging della memoria nell'app Impostazioni. Se questa opzione non è presente, il tuo dispositivo non supporta l'attivazione di MTE in questo modo.

Dispositivi con supporto MTE

I seguenti dispositivi sono noti per supportare MTE:

• Pixel 8 (Shiba)
• Pixel 8 Pro (Husky)
• Pixel 8a (Akita)
• Pixel 9 (Tokay)
• Pixel 9 Pro (Caiman)
• Pixel 9 Pro XL (Komodo)
• Pixel 9 Pro Fold (Comet)
• Pixel 9a (Tegu)

Modalità di funzionamento del MTE

MTE supporta due modalità: SYNC e ASYNC. La modalità SYNC fornisce informazioni di diagnostica migliori ed è quindi più adatta per scopi di sviluppo, mentre la modalità ASYNC ha prestazioni elevate che consentono di attivarla per le app rilasciate.

Modalità sincrona (SYNC)

Questa modalità è ottimizzata per il debug rispetto alle prestazioni e può essere utilizzata come strumento di rilevamento preciso dei bug, quando è accettabile un sovraccarico delle prestazioni più elevato. Se abilitata, MTE SYNC funge anche da misura di mitigazione della sicurezza.

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

Questa modalità è utile durante i test come alternativa più rapida a HWASan che non richiede la ricompilarzione del codice o in produzione, quando la tua app rappresenta una superficie di attacco vulnerabile. Inoltre, quando la modalità ASYNC (descritta di seguito) ha rilevato un bug, è possibile ottenere un report accurato utilizzando le API di runtime per passare all'esecuzione in modalità SYNC.

Inoltre, quando viene eseguito in modalità SYNC, l'allocatore Android registra l'analisi dello stack di ogni allocazione e deallocazione e le utilizza per fornire report sugli errori migliori che includono la spiegazione di un errore di memoria, come use-after-free o overflow del buffer, e le analisi dello stack degli eventi di memoria pertinenti (per ulteriori dettagli, consulta Informazioni sui report MTE). Questi report forniscono informazioni più contestuali e consentono di rilevare e correggere più facilmente i bug rispetto alla modalità ASYNC.

Modalità asincrona (ASYNC)

Questa modalità è ottimizzata per le prestazioni rispetto all'accuratezza dei report di bug e può essere utilizzata per il rilevamento a basso overhead dei bug di sicurezza della memoria. In caso di mancata corrispondenza dei tag, il processore continua l'esecuzione fino all'elemento del kernel più vicino (ad esempio un sistema di chiamata di sistema o un'interruzione del timer), dove termina il processo con SIGSEGV (codice SEGV_MTEAERR) senza registrare l'indirizzo o l'accesso alla memoria con errore.

Questa modalità è utile per mitigare le vulnerabilità di sicurezza della memoria in produzione su codebase ben testate in cui la densità di bug di sicurezza della memoria è nota per essere bassa, il che si ottiene utilizzando la modalità SYNC durante i test.

Attivare MTE

Per un singolo dispositivo

Per la sperimentazione, le modifiche alla compatibilità delle app possono essere utilizzate per impostare il valore predefinito dell'attributo memtagMode per un'applicazione che non specifica alcun valore nel file manifest (o specifica "default").

Puoi trovarli in Sistema > Avanzate > Opzioni sviluppatore > Modifiche alla compatibilità delle app nel menu delle impostazioni globali. L'impostazione NATIVE_MEMTAG_ASYNC o NATIVE_MEMTAG_SYNC attiva l'MTE per una determinata applicazione.

In alternativa, puoi impostarlo 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

In Gradle

Puoi attivare 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. In questo modo, memtagMode del file manifest verrà sostituito con la sincronizzazione per le build di debug.

In alternativa, puoi attivare MTE per tutte le build di un buildType personalizzato. Per farlo, crea il tuo buildType e inserisci il codice XML in app/src/<name of buildType>/AndroidManifest.xml.

Per un APK su qualsiasi dispositivo compatibile

MTE è disattivato per impostazione predefinita. Le app che vogliono utilizzare MTE possono farlo impostando android:memtagMode nel tag <application> o <process> nel AndroidManifest.xml.

Attenzione: le applicazioni che attivano l'MTE devono essere testate a fondo su un dispositivo compatibile con l'MTE prima di essere inviate al Play Store. In caso contrario, i bug critici potrebbero essere rilevati solo su dispositivi compatibili con MTE, il che potrebbe danneggiare l'usabilità dell'app.

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

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

Crea con la misurazione

Importante: le app create con la misurazione MTE sono solo per scopi di debug.

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

L'attivazione di MTE, come spiegato in precedenza, aiuta a rilevare bug di corruzione della memoria nell'heap nativo. Per rilevare la corruzione della memoria nello stack, oltre ad attivare la MTE per l'app, il codice deve essere ricostruito con la misurazione. L'app risultante verrà eseguita solo sui dispositivi compatibili con MTE.

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

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

ndk-build

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

CMake

Per ogni target in 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 MTE, utilizza e testa la tua app come di consueto. Se viene rilevato un problema di sicurezza della memoria, l'app si arresta in modo anomalo con un messaggio simile al seguente (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 Informazioni sui report MTE nella documentazione AOSP. Puoi anche eseguire il debug dell'app con Android Studio e il debugger si arresta sulla riga che causa l'accesso alla memoria non valido.

Utenti avanzati: utilizzo di MTE nel tuo allocator

Nota: se non sai di utilizzare allocatori personalizzati, puoi saltare questa sezione.

Per utilizzare MTE per la memoria non allocata tramite gli allocatori di sistema normali, devi modificare l'allocatore per taggare la memoria e i 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 di 16 byte (noti anche come granuli).

Poi, prima di restituire un puntatore, devi utilizzare l'istruzione IRG per generare un tag casuale e memorizzarlo nel puntatore.

Segui le istruzioni riportate di seguito per taggare la memoria sottostante:

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

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

• STZG: esegui il tagging e l'inizializzazione a zero di un singolo granulo di 16 byte
• STZ2G: contrassegna e inizializza a zero due granuli di 16 byte
• DC GZVA: tagga e inizializza a zero la riga della cache con lo stesso tag

Tieni presente che queste istruzioni non sono supportate sulle CPU meno recenti, quindi devi eseguire queste istruzioni in modo condizionale quando MTE è attivato. Puoi verificare se la funzionalità MTE è attivata per la tua procedura:

#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;
}

Potresti trovare utile l'implementazione dello scudo come riferimento.

Scopri di più

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