Les plantages de SIGSEGV avec le code 9 (SEGV_MTESERR) ou le code 8 (SEGV_MTEAERR) sont des erreurs de taggage de la mémoire. Memory Tagging Extension (MTE) est une Fonctionnalité Armv9 compatible avec Android 12 et versions ultérieures. MTE est une implémentation matérielle de mémoire. Il fournit une protection ultraprécise de la mémoire pour détecter et atténuer les bugs de sécurité liés à la mémoire.
En C/C++, un pointeur renvoyé par un appel à malloc() ou à l'opérateur new() ou à des fonctions similaires peut être utilisé uniquement pour accéder à la mémoire dans les limites de cette allocation, et uniquement lorsque est active (ni libérée ni supprimée). MTE est utilisé dans Android pour détecter les cas de non-respect des cette règle, appelée dans les rapports d'erreur "Buffer Overflow"/"Buffer Underflow" et "Utiliser After Free" les problèmes de performances.
MTE dispose de deux modes: synchrone (ou "sync") et asynchrone (ou "async"). Le premier est plus mais fournit des diagnostics plus précis. Cette dernière est plus rapide, mais ne peut donner des informations approximatives. Nous aborderons ces deux aspects séparément, car les diagnostics sont légèrement différents.
MTE en mode synchrone
En mode synchrone ("synchronisation") de MTE, SIGSEGV plante avec le code 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)
Tous les rapports d'erreur MTE contiennent les données de dump et de trace arrière habituelles pour le point où a été détecté. La « Cause : » pour une erreur détectée par MTE contient "[MTE]". comme dans l'exemple ci-dessus et plus de détails. Dans ce cas, le type spécifique d’erreur détecté était une "utilisation après libération" et la valeur "0 octet dans une allocation de 32 octets à 0x7ae92853a0" nous indique la taille et l'adresse de l'allocation, et le décalage dans l'allocation à laquelle nous avons essayé d'accéder.
Les rapports d'erreur MTE incluent également des traces arrière supplémentaires, en plus de celle du point de détection.
"Utiliser After Free" les erreurs ajoutent "deallocated by" (distribué par) et "allouée par" dans le fichier de crash dump, affichant les traces de la pile au moment où cette mémoire a été désaffectée (avant son utilisation) et l'heure à laquelle elle a été précédemment allouée. Ils vous indiquent également quel fil de discussion a l'allocation/déallocation. les trois phases de détection, d'allocation et d'allocation ; sont identiques dans cet exemple simple, mais dans des cas concrets plus complexes, il ne s'agit pas vraisemblablement vrais, et savoir qu'ils diffèrent peut être un indice important pour trouver bug lié à la simultanéité.
"Dépassement de la mémoire tampon" et « dépassement de la mémoire tampon » les erreurs ne fournissent qu'une valeur "allocated by" de pile, car, par définition, ils n'ont pas encore été désaffectés (ou ils apparaissent en tant que "Utiliser après 0 €"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Notez l'utilisation du mot « droit ». ici: cela signifie que nous vous indiquons le nombre d'octets après la fin de l'allocation était l'accès incorrect ; un dépassement indiquerait « gauche » et être un certain nombre octets avant le début de l'allocation.
Plusieurs causes potentielles
Les rapports SEGV_MTESERR contiennent parfois la ligne suivante:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Cela se produit lorsqu'il existe plusieurs candidats appropriés pour l'origine de l'erreur et que nous ne pouvons pas dire qui est la cause réelle. Nous imprimons jusqu'à 3 candidats de ce type dans l'ordre de probabilité approximatif, et laisser l'analyse à l'utilisateur.
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...]
Dans l'exemple ci-dessus, nous avons détecté deux allocations récentes à la même adresse mémoire qui pourraient ont été la cible prévue de l'accès non valide à la mémoire. Cela peut se produire lorsque les allocations réutilisent mémoire disponible : par exemple, si vous avez la séquence telle que new, free, new, free, new, free, y accéder. L'allocation la plus récente est imprimée en premier.
Heuristique détaillée de la détermination de la cause
La "Cause" d'un plantage devrait indiquer l'allocation de mémoire dont le pointeur consulté a été dérivé. Malheureusement, le matériel MTE n'a aucun moyen de convertir un pointeur avec une balise non concordante en allocation. Pour expliquer un plantage SEGV_MTESERR, Android analyse les données suivantes:
- Adresse d'erreur (y compris la balise de pointeur).
- Liste des allocations récentes de segments de mémoire avec les traces de la pile et les tags de mémoire.
- Allocations actuelles (en direct) à proximité et leurs tags de mémoire.
Toute mémoire récemment désaffectée à l'adresse de défaut où la balise mémoire correspond à la balise d'adresse de défaut constitue une possibilité d'utilisation après libération. la cause.
Toute mémoire active à proximité où la balise mémoire correspond à la balise d'adresse de défaut peut potentiellement être un "dépassement de mémoire tampon". (ou "dépassement de mémoire tampon").
Les allocations les plus proches de la défaillance, dans le temps ou dans l'espace, sont considérées comme plus probables que celles qui sont éloignées.
Étant donné que la mémoire désaffectée est souvent réutilisée et que le nombre de valeurs de tags différentes est faible (moins de 16), il n'est pas rare de trouver plusieurs candidats probables. Il n'existe aucun moyen d'identifier automatiquement la véritable cause. C'est pourquoi les rapports sur les événements majeurs sur la route répertorient parfois plusieurs causes potentielles.
Nous recommandons au développeur de l'application d'examiner les causes potentielles, en commençant par la plus probable. Il est souvent facile de filtrer les causes non liées en fonction de la trace de la pile.
MTE en mode asynchrone
En mode asynchrone ("async") de MTE, SIGSEGV plante avec le code 8 (SEGV_MTEAERR).
Les erreurs SEGV_MTEAERR ne se produisent pas immédiatement lorsqu'un programme effectue un accès non valide à la mémoire. Le problème est détecté peu de temps après l'événement, puis le programme s'arrête. Ce point correspond généralement à l'appel système suivant, mais il peut aussi s'agir d'une interruption du minuteur, c'est-à-dire d'une transition entre l'espace utilisateur et le noyau.
Les erreurs SEGV_MTEAERR ne conservent pas l'adresse mémoire (elle est toujours affichée sous la forme "-------"). La trace arrière correspond au moment où la condition a été détectée (c'est-à-dire lors du prochain appel du système ou d'un autre changement de contexte), et non au moment où l'accès non valide a été effectué.
Cela signifie que la partie "principale" trace arrière dans un plantage MTE asynchrone n'est généralement pas pertinent. Les échecs en mode asynchrone sont donc beaucoup plus difficiles à déboguer que ceux en mode synchronisation. Ils indiquent l'existence d'un bug de mémoire dans le code à proximité du thread donné. Les journaux au bas du fichier tombstone peuvent donner un indice de ce qui s'est réellement passé. Sinon, nous vous recommandons de reproduire l'erreur en mode de synchronisation et d'utiliser les meilleurs diagnostics fournis par ce mode.
Rubriques avancées
En arrière-plan, l'ajout de tags à la mémoire consiste à attribuer une valeur de tag aléatoire de 4 bits (0 à 15) à chaque allocation de segments de mémoire. Cette valeur est stockée dans une région de métadonnées spéciale qui correspond à la mémoire du tas de mémoire alloué. La même valeur est attribuée à l'octet le plus significatif du pointeur de segment de mémoire renvoyé par des fonctions telles que malloc() ou l'opérateur new().
Lorsque la vérification des tags est activée, le processeur compare automatiquement l'octet supérieur du pointeur avec le tag de mémoire pour chaque accès à la mémoire. Si les tags ne correspondent pas, le processeur signale une erreur qui entraîne un plantage.
En raison du nombre limité de valeurs de balises possibles, cette approche est probabiliste. Tout emplacement de mémoire à qui il est interdit d'accéder avec un pointeur donné (par exemple, hors limites ou après la désallocation ("pointeur flottant") peut avoir une valeur de balise différente, ce qui peut entraîner un plantage. Il y a environ 7% de chances que l'occurrence d'un bug ne soit pas détectée une seule fois. Les valeurs des balises étant attribuées de manière aléatoire, il y a environ 93% de chances de détecter le bug la prochaine fois qu'il se produira.
Les valeurs de balise sont visibles dans le champ de l'adresse de défaut ainsi que dans le fichier de dump du registre, comme indiqué ci-dessous. Cette section peut être utilisée pour vérifier que les balises sont définies de manière saine et pour voir d'autres allocations de mémoire à proximité avec la même valeur de balise, car elles peuvent être des causes d'erreur autres que celles indiquées dans le rapport. Nous nous attendons à ce que cette fonctionnalité soit surtout utile aux personnes qui travaillent sur l'implémentation de MTE elle-même ou à d'autres composants système de bas niveau, plutôt qu'aux développeurs.
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
Un "Tags mémoire" spéciaux apparaît également dans le rapport d'erreur qui affiche les tags de mémoire autour de l'adresse de défaut. Dans l'exemple ci-dessous, la balise de pointeur "4" ne correspond pas à la balise de mémoire "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
Les sections d'un tombstone qui affichent le contenu de la mémoire autour de toutes les valeurs de registre affichent également leurs valeurs de 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 ..'.}...........