Diese Seite wurde von der Cloud Translation API übersetzt.

ARM-Speicher-Tagging-Erweiterung (MTE)

Warum MTE?

Arbeitsspeichersicherheitsfehler, also Fehler bei der Speichernutzung in nativen Programmiersprachen, sind häufige Probleme mit dem Code. Sie führen zu Sicherheitslücken und Stabilitätsproblemen.

Armv9 hat die Arm Memory Tagging Extension (MTE) eingeführt, eine Hardwareerweiterung, mit der sich Fehler nach der Verwendung und Pufferüberlauf im nativen Code erkennen lassen.

Support kontaktieren

Ab Android 13 unterstützen ausgewählte Geräte MTE. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihr Gerät mit aktiviertem MTE ausgeführt wird:

adb shell grep mte /proc/cpuinfo

Wenn das Ergebnis Features : [...] mte ist, wird auf dem Gerät MTE aktiviert.

Auf einigen Geräten wird MTE nicht standardmäßig aktiviert, Entwickler können jedoch bei aktiviertem MTE neu starten. Dies ist eine experimentelle Konfiguration, die nicht für die normale Verwendung empfohlen wird, da sie die Geräteleistung oder -stabilität beeinträchtigen kann, aber für die App-Entwicklung nützlich sein kann. Du kannst auf diesen Modus zugreifen, indem du in den Einstellungen zu Entwickleroptionen > Erweiterung für Arbeitsspeicher-Tagging gehst. Wenn diese Option nicht angezeigt wird, unterstützt dein Gerät die Aktivierung von MTE auf diese Weise nicht.

MTE-Betriebsmodi

MTE unterstützt zwei Modi: SYNC und ASYNC. Der SYNC-Modus bietet bessere Diagnoseinformationen und eignet sich daher besser für Entwicklungszwecke. Der ASYNC-Modus bietet eine hohe Leistung, sodass er für veröffentlichte Anwendungen aktiviert werden kann.

Synchroner Modus (SYNC)

Dieser Modus ist auf die Debug-Fähigkeit statt auf die Leistung ausgelegt und kann als präzises Tool zur Fehlererkennung verwendet werden, wenn ein höherer Leistungsaufwand akzeptabel ist. Wenn MTE SYNC aktiviert ist, dient es auch zur Abschwächung der Sicherheit.

Bei einer Tag-Nichtübereinstimmung beendet der Prozessor den Prozess bei der entsprechenden Lade- oder Speicheranweisung mit SIGSEGV (mit si_code SEGV_MTESERR) und vollständigen Informationen über den Arbeitsspeicherzugriff und die fehlerhafte Adresse.

Dieser Modus ist nützlich beim Testen als schnellere Alternative zu HWASan, bei der Sie Ihren Code nicht neu kompilieren müssen, oder in der Produktion, wenn Ihre Anwendung eine anfällige Angriffsfläche darstellt. Wenn außerdem der ASYNC-Modus (siehe unten) einen Fehler gefunden hat, können Sie einen genauen Fehlerbericht abrufen. Dazu verwenden Sie die Laufzeit-APIs, um die Ausführung in den SYNC-Modus zu wechseln.

Darüber hinaus zeichnet der Android-Allocator beim Ausführen im SYNC-Modus den Stacktrace jeder Zuweisung und Freigabe auf und verwendet diese, um bessere Fehlerberichte zu liefern, die eine Erklärung von Speicherfehlern wie „use-after-free“ oder „buffer_overflow“ enthalten, und die Stacktraces der relevanten Speicherereignisse. Weitere Informationen finden Sie unter Informationen zu MTE-Berichten. Solche Berichte bieten mehr Kontextinformationen und erleichtern das Verfolgen und Beheben von Fehlern als im ASYNC-Modus.

Asynchroner Modus (ASYNC)

Dieser Modus ist für die Leistung statt für die Genauigkeit von Fehlerberichten optimiert und kann für die Erkennung von Arbeitsspeichersicherheitsfehlern mit geringem Aufwand verwendet werden. Bei einer Tag-Nichtübereinstimmung fährt der Prozessor bis zum nächsten Kernel-Eintrag fort (z. B. Systemaufruf oder Timer-Interrupt), wo er den Prozess mit SIGSEGV (Code SEGV_MTEAERR) beendet, ohne die fehlerhafte Adresse oder den Arbeitsspeicherzugriff aufzuzeichnen.

Dieser Modus eignet sich zur Minderung von Sicherheitslücken im Arbeitsspeicher in der Produktion auf gut getesteten Codebasen, bei denen die Dichte der Arbeitsspeichersicherheitsfehler als gering bekannt ist. Dies wird mithilfe des SYNC-Modus während des Tests erreicht.

MTE aktivieren

Für ein einzelnes Gerät

Zu Testzwecken können Sie die App-Kompatibilitätsänderungen verwenden, um den Standardwert des memtagMode-Attributs für eine App festzulegen, die keinen Wert im Manifest angibt (oder "default" angibt).

Diese findest du im globalen Einstellungsmenü unter „System“ > „Erweitert“ > „Entwickleroptionen“ > „App-Kompatibilitätsänderungen“. Wenn Sie NATIVE_MEMTAG_ASYNC oder NATIVE_MEMTAG_SYNC festlegen, wird MTE für eine bestimmte Anwendung aktiviert.

Alternativ kann dies mit dem Befehl am so festgelegt werden:

Für den SYNC-Modus: $ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
Für den ASYNC-Modus: $ adb shell am compat enable NATIVE_MEMTAG_ASYNC my.app.name

In Gradle

Sie können MTE für alle Debug-Builds Ihres Gradle-Projekts aktivieren, indem Sie

<?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. Dadurch wird die memtagMode deines Manifests mit der Synchronisierung für Builds zur Fehlerbehebung überschrieben.

Alternativ können Sie MTE für alle Builds eines benutzerdefinierten „buildType“ aktivieren. Dazu erstellen Sie Ihren eigenen „buildType“ und fügen den XML-Code in app/src/<name of buildType>/AndroidManifest.xml ein.

Für ein APK auf einem beliebigen kompatiblen Gerät

MTE ist standardmäßig deaktiviert. Für Anwendungen, die MTE verwenden möchten, legen Sie android:memtagMode unter dem <application>- oder <process>-Tag in AndroidManifest.xml fest.

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

Wenn es für das Tag <application> festgelegt ist, wirkt es sich auf alle von der Anwendung verwendeten Prozesse aus und kann für einzelne Prozesse durch Festlegen des Tags <process> überschrieben werden.

App ausführen

Nachdem Sie MTE aktiviert haben, können Sie Ihre App wie gewohnt verwenden und testen. Wenn ein Sicherheitsproblem mit dem Speicher erkannt wird, stürzt die App mit einem Tombstone-Element ab, das ungefähr so aussieht (beachten Sie die SIGSEGV mit SEGV_MTESERR für SYNC oder SEGV_MTEAERR für 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

Weitere Informationen finden Sie in der AOSP-Dokumentation unter Grundlegendes zu MTE-Berichten. Sie können auch Fehler in Ihrer App mit Android Studio beheben. Der Debugger wird dann an der Zeile gestoppt, die den ungültigen Arbeitsspeicherzugriff verursacht.

Fortgeschrittene Nutzer: MTE in Ihrem eigenen Zuweis verwenden

Wenn Sie MTE für Arbeitsspeicher verwenden möchten, der nicht über die normalen System-Allocators zugewiesen ist, müssen Sie den Allocator so ändern, dass Arbeitsspeicher und Zeiger mit Tags versehen werden.

Die Seiten für den Allocator müssen mithilfe von PROT_MTE im Flag prot von mmap (oder mprotect) zugewiesen werden.

Alle getaggten Zuweisungen müssen auf 16 Byte ausgerichtet sein, da Tags nur für Blöcke mit 16 Byte (auch als Granulen bezeichnet) zugewiesen werden können.

Bevor Sie einen Zeiger zurückgeben, müssen Sie dann die Anweisung IRG verwenden, um ein zufälliges Tag zu generieren und im Zeiger zu speichern.

Gehen Sie so vor, um die zugrunde liegende Erinnerung zu taggen:

STG: eine einzelne 16-Byte-Granule taggen
ST2G: Zwei 16-Byte-Granulen taggen
DC GVA: Cache-Zeile des Tags mit demselben Tag

Alternativ können Sie mit den folgenden Anweisungen ebenfalls den Speicher mit Null initialisieren:

STZG: Eine einzelne 16-Byte-Granule taggen und null initialisieren
STZ2G: Zwei 16-Byte-Granulen taggen und null initialisieren
DC GZVA: Tag und Null-Initialisierung der Cacheline mit demselben Tag

Beachten Sie, dass diese Anweisungen auf älteren CPUs nicht unterstützt werden. Sie müssen sie also bei aktivierter MTE bedingt ausführen. Sie können prüfen, ob MTE für Ihren Prozess aktiviert ist:

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

Als Referenz kann die Implementierung von Scudo hilfreich sein.

Weitere Informationen

Weitere Informationen finden Sie im MTE-Nutzerhandbuch für das Android-Betriebssystem von Arm.