Les plantages de SIGSEGV avec le code 9 (SEGV_MTESERR) ou le code 8 (SEGV_MTEAERR) sont des défauts de marquage de mémoire. Memory Tagging Extension (MTE) est une fonctionnalité Armv9 prise en charge dans Android 12 et versions ultérieures. MTE est une implémentation matérielle de mémoire balisée. Il fournit une protection fine de la mémoire pour la détection et l'atténuation des bogues de sécurité de la mémoire .
En C/C++, un pointeur renvoyé par un appel à malloc() ou à l'opérateur new() ou à des fonctions similaires ne peut être utilisé que pour accéder à la mémoire dans les limites de cette allocation, et uniquement pendant que l'allocation est active (non libérée ou non). supprimé-ed). MTE est utilisé dans Android pour détecter les violations de cette règle, appelées dans les rapports d'erreur problèmes "Buffer Overflow"/"Buffer Underflow" et "Use After Free".
MTE a deux modes : synchrone (ou « sync ») et asynchrone (ou « async »). Le premier fonctionne plus lentement mais fournit des diagnostics plus précis. Ce dernier court plus vite, mais ne peut donner que des détails approximatifs. Nous aborderons les deux séparément, car les diagnostics sont légèrement différents.
MTE en mode synchrone
En mode synchrone (« sync ») 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 le vidage de registre habituel et la trace du point où le problème a été détecté. La ligne « Cause : » d'une erreur détectée par MTE contiendra « [MTE] » comme dans l'exemple ci-dessus, ainsi que plus de détails. Dans ce cas, le type spécifique d'erreur détecté était une "Utilisation après libération" et le "0 octet dans une allocation de 32 octets à 0x7ae92853a0" nous indique la taille et l'adresse de l'allocation, ainsi que le décalage dans l'allocation que nous avons. essayé d'accéder.
Les rapports d'accident MTE incluent également des traces supplémentaires, pas seulement celle du point de détection.
Les erreurs « Utiliser après libération » ajoutent des sections « désallouée par » et « allouée par » au vidage sur incident, affichant les traces de pile au moment où cette mémoire a été libérée (avant qu'elle ne soit utilisée !) et l'heure à laquelle elle a été précédemment allouée. Ceux-ci vous indiquent également quel thread a effectué l'allocation/désallocation. Les trois threads de détection, d'allocation et de désallocation sont identiques dans cet exemple simple, mais dans des cas réels plus complexes, cela n'est pas nécessairement vrai, et savoir qu'ils diffèrent peut être un indice important pour trouver une concurrence. -bug lié.
Les erreurs « Buffer Overflow » et « Buffer Underflow » fournissent uniquement une piste de pile « allouée par » supplémentaire, car par définition, elles n'ont pas encore été libérées (ou elles apparaîtraient comme une « Utilisation après libération ») :
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 combien d'octets après la fin de l'allocation se trouvait l'accès incorrect ; un dépassement inférieur dirait "gauche" et représenterait un nombre d'octets avant le début de l'allocation.
Plusieurs causes potentielles
Parfois, les rapports SEGV_MTESERR contiennent 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 bons candidats pour l’origine de l’erreur et que nous ne pouvons pas déterminer quelle est la cause réelle. Nous imprimons jusqu'à 3 de ces candidats par ordre approximatif de vraisemblance et laissons 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 auraient pu être la cible d'un accès mémoire non valide. Cela peut se produire lorsque les allocations réutilisent la mémoire libre - par exemple, si vous avez la séquence telle que nouveau, libre, nouveau, libre, nouveau, libre, accès. L'allocation la plus récente est imprimée en premier.
Heuristique détaillée de détermination des causes
La "Cause" d'un crash doit indiquer l'allocation de mémoire dont le pointeur accédé est initialement dérivé. Malheureusement, le matériel MTE n'a aucun moyen de traduire un pointeur avec une balise incompatible en une allocation. Pour expliquer un crash SEGV_MTESERR, Android analyse les données suivantes :
- L'adresse du défaut (y compris l'étiquette du pointeur).
- Une liste des allocations de tas récentes avec des traces de pile et des balises mémoire.
- Allocations actuelles (en direct) à proximité et leurs balises mémoire.
Toute mémoire récemment désallouée à l'adresse de défaut où l'étiquette de mémoire correspond à l'étiquette d'adresse de défaut est une cause potentielle « Utilisation après libération ».
Toute mémoire active à proximité où l'étiquette de mémoire correspond à l'étiquette d'adresse de défaut est une cause potentielle de « débordement de tampon » (ou « débordement de tampon inférieur »).
Les allocations les plus proches de la faille – que ce soit dans le temps ou dans l’espace – sont considérées comme plus probables que celles qui en sont éloignées.
Étant donné que la mémoire désallouée est souvent réutilisée et que le nombre de valeurs de balises différentes est faible (moins de 16), il n'est pas rare de trouver plusieurs candidats probables et il n'existe aucun moyen de trouver automatiquement la véritable cause. C'est la raison pour laquelle les rapports MTE répertorient parfois plusieurs causes potentielles.
Il est recommandé 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 mémoire non valide. Le problème est détecté peu de temps après l'événement et le programme est terminé à ce moment-là. Ce point est généralement le prochain appel système, mais il peut également s'agir d'une interruption de minuterie - en bref, de toute transition de l'espace utilisateur au noyau.
Les défauts SEGV_MTEAERR ne préservent pas l'adresse mémoire (elle est toujours affichée par "-------"). La trace correspond au moment où la condition a été détectée (c'est-à-dire lors du prochain appel système ou autre changement de contexte), et non au moment où l'accès non valide a été effectué.
Cela signifie que la trace "principale" dans un crash MTE asynchrone n'est généralement pas pertinente . Les échecs en mode asynchrone sont donc beaucoup plus difficiles à déboguer que les échecs en mode synchronisation. Ils sont mieux compris comme montrant l'existence d'un bug de mémoire dans le code voisin du thread donné. Les journaux au bas du fichier tombstone peuvent fournir une indication de ce qui s'est réellement passé. Sinon, la marche à suivre recommandée consiste à reproduire l’erreur en mode synchronisation et à utiliser les meilleurs diagnostics fournis par le mode synchronisation !
Sujets avancés
Sous le capot, le marquage de la mémoire fonctionne en attribuant une valeur de balise aléatoire de 4 bits (0 à 15) à chaque allocation de tas. Cette valeur est stockée dans une région de métadonnées spéciale qui correspond à la mémoire tas allouée. La même valeur est attribuée à l'octet de poids fort du pointeur de tas renvoyé par des fonctions telles que malloc() ou Operator new().
Lorsque la vérification des balises est activée dans le processus, la CPU compare automatiquement l'octet supérieur du pointeur avec la balise mémoire pour chaque accès mémoire. Si les balises ne correspondent pas, le CPU signale une erreur qui entraîne un crash.
En raison du nombre limité de valeurs de balises possibles, cette approche est probabiliste. Tout emplacement mémoire auquel il ne faut pas accéder avec un pointeur donné - comme hors limites ou après une désallocation ("pointeur suspendu") - est susceptible d'avoir une valeur de balise différente et de provoquer un crash. Il y a environ 7 % de chances de ne détecter aucune occurrence d'un bug. Étant donné que les valeurs des balises sont attribuées de manière aléatoire, il existe une chance indépendante d'environ 93 % de détecter le bogue la prochaine fois qu'il se produira.
Les valeurs des balises peuvent être vues dans le champ d'adresse de défaut ainsi que dans le vidage 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, ainsi que pour voir d'autres allocations de mémoire à proximité avec la même valeur de balise, car elles peuvent être des causes potentielles de l'erreur au-delà de celles répertoriées dans le rapport. Nous espérons que cela sera principalement utile aux personnes travaillant sur l'implémentation de MTE lui-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
Une section spéciale « Balises mémoire » apparaît également dans le rapport d'erreur, qui affiche les balises mémoire autour de l'adresse du défaut. Dans l'exemple ci-dessous, la balise de pointeur « 4 » ne correspondait 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'une pierre tombale qui affichent le contenu de la mémoire autour de toutes les valeurs de registre affichent également leurs valeurs de balise.
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 ..'.}...........