À partir d'Android 11, toutes les allocations de segments de mémoire pour les processus 64 bits une balise définie par l'implémentation définie dans l'octet supérieur du pointeur sur les appareils avec Prise en charge du noyau pour ARM Top-byte Ignore (TBI). Toute application qui modifie se termine lorsqu'il est vérifié lors de la désallocation. C'est nécessaire pour le futur matériel grâce à la compatibilité avec ARM Memory Tagging Extension (MTE).
Ignorer le top-octet
La fonctionnalité Ignorer top-octet d'ARM est disponible pour le code 64 bits dans tout le matériel Armv8 AArch64. Cette fonctionnalité signifie que le matériel ignore l'octet supérieur d'un pointeur lorsque qui accède à la mémoire.
La méthode de TAI nécessite un modèle noyau qui gère correctement les pointeurs tagués transmis depuis l'espace utilisateur. Les noyaux Android courants à partir de la version 4.14 (Pixel 4) et les versions ultérieures disposent des TBI requises. correctifs.
Les appareils avec la prise en charge de la technique TBI dans le noyau sont détectés dynamiquement à l'heure de début du processus, et un tag dépendant de l'implémentation est inséré dans la partie supérieure du pointeur pour toutes les allocations de segments de mémoire. Ensuite, une vérification est exécutée pour vous assurer que le tag n'a pas été tronqué lors de la désallocation de la mémoire.
Disponibilité des extensions de taggage de mémoire
L'extension MTE (Memory Tagging Extension) d'ARM permet de résoudre les problèmes de sécurité de la mémoire. MTE fonctionne en taguant les bits d'adresse 56 à 59 bits de chaque mémoire. l'allocation sur la pile, le tas de mémoire et les éléments généraux. Matériel et ensemble d'instructions vérifie automatiquement que le bon tag est utilisé à chaque accès à la mémoire.
Les applications Android qui stockent de manière incorrecte des informations dans l'octet supérieur de la pointeur dont la interruption sur un appareil compatible MTE est garantie. Les pointeurs avec balises facilitent la détection et le refus des utilisations incorrectes de la partie supérieure octet du pointeur avant que les appareils MTE soient disponibles.
Assistance pour les développeurs
Si votre appli a planté et que ce lien s'affiche, cela peut signifier l'une des options suivantes:
- L'application a tenté de libérer un pointeur qui n'a pas été alloué par le l'outil d'allocation de segments de mémoire du système.
- Un élément de votre application a modifié l'octet supérieur d'un pointeur. Le premier octet de le pointeur ne peut pas être modifié et votre code doit être modifié pour résoudre ce problème problème.
Exemples de pointeurs d'octets supérieurs utilisés ou modifiés de manière incorrecte
- Les pointeurs vers un type particulier ont des métadonnées spécifiques à l'application stockées dans les 16 premiers bits d’adresse.
- Un pointeur est converti en double, puis en arrière, en perdant les bits d'adresse inférieurs.
- Code calculant la différence entre les adresses des variables locales à partir de différents blocs de pile comme moyen de mesurer la profondeur de la récursion.
Certaines applications peuvent dépendre de bibliothèques dont le comportement est incorrect lorsque le
l'octet supérieur du pointeur est défini. Nous savons qu'il peut s'agir
difficile de résoudre rapidement ces problèmes
sous-jacents dans les bibliothèques. À ce titre,
applis qui utilisent targetSdkLevel < 30
le pointeur n'est pas activé par défaut. Nous proposons également une fonctionnalité d'échappement
découverte d'applis conçues avec targetSdkLevel >= 30
pour faciliter la transition.
Pour utiliser le mécanisme de sortie, ajoutez le code suivant à votre fichier
Fichier AndroidManifest.xml:
<application android:allowNativeHeapPointerTagging="false"> ... </application>
La fonctionnalité de balisage du pointeur est alors désactivée l'application. Cela ne concerne pas les l'état sous-jacent du code. Ce mécanisme de secours disparaîtra à l'avenir d'Android, car les problèmes de cette nature sont incompatibles MTE