HWAddressSanitizer

Voir Comprendre les rapports HWASan pour plus d'informations sur la façon de lire les plantages HWASan !

Hardware-assisted AddressSanitizer (HWASan) est un outil de détection d'erreur de mémoire similaire à AddressSanitizer . HWASan utilise beaucoup moins de RAM que ASan, ce qui le rend adapté à la désinfection de l'ensemble du système. HWASan est uniquement disponible sur Android 10 et supérieur, et uniquement sur le matériel AArch64.

Bien que principalement utile pour le code C/C++, HWASan peut également aider à déboguer le code Java qui provoque des plantages en C/C++ utilisé pour implémenter les interfaces Java. C'est utile car il détecte les erreurs de mémoire lorsqu'elles se produisent, vous dirigeant directement vers le code responsable.

Vous pouvez flasher des images HWASan prédéfinies sur les appareils Pixel pris en charge à partir de ci.android.com ( instructions de configuration détaillées ).

Par rapport à l'ASan classique, HWASan a :

• Surcharge CPU similaire (~ 2x)
• Frais généraux de taille de code similaire (40 à 50 %)
• Surcharge de RAM beaucoup plus petite (10% - 35%)

HWASan détecte le même ensemble de bogues qu'ASan :

• Débordement/débordement de tampon de pile et de tas
• Utilisation du tas après la libération
• Utilisation de la pile en dehors du champ d'application
• Double libre/sauvage libre

De plus, HWASan détecte l'utilisation de la pile après le retour.

HWASan (identique à ASan) est compatible avec UBSan , les deux peuvent être activés sur une cible en même temps.

Détails et limitations de la mise en œuvre

HWASan est basé sur l'approche d'étiquetage en mémoire , où une petite valeur d'étiquette aléatoire est associée à la fois à des pointeurs et à des plages d'adresses mémoire. Pour qu'un accès mémoire soit valide, le pointeur et les balises mémoire doivent correspondre. HWASan s'appuie sur la fonctionnalité ARMv8 top byte ignore (TBI), également appelée étiquetage d'adresse virtuelle , pour stocker l'étiquette de pointeur dans les bits les plus élevés de l'adresse.

Vous pouvez en savoir plus sur la conception de HWASan sur le site de documentation de Clang.

De par sa conception, HWASan n'a pas les zones rouges de taille limitée d'ASan pour détecter les débordements ou la quarantaine à capacité limitée d'ASan pour détecter l'utilisation après la libération. Pour cette raison, HWASan peut détecter un bogue, quelle que soit l'ampleur du débordement ou depuis combien de temps la mémoire a été désallouée. Cela donne à HWASan un gros avantage sur ASan.

Cependant, HWASan a un nombre limité de valeurs de balises possibles (256), ce qui signifie qu'il y a une probabilité de 0,4 % de manquer un bogue lors d'une exécution du programme.

Exigences

Les versions récentes (4.14+) du noyau Android commun prennent en charge HWASan prêt à l'emploi. Les branches spécifiques à Android 10 ne prennent pas en charge HWASan.

La prise en charge de l'espace utilisateur pour HWASan est disponible à partir d' Android 11 .

Si vous travaillez avec un noyau différent, HWASan exige que le noyau Linux accepte les pointeurs balisés dans les arguments d'appel système. La prise en charge de cela a été implémentée dans les ensembles de correctifs en amont suivants :

• arm64 tagged adresse ABI
• arm64 : décode les pointeurs utilisateur transmis au noyau
• mm : évitez de créer des alias d'adresses virtuelles dans brk()/mmap()/mremap()
• arm64 : validez les adresses balisées dans access_ok() appelées à partir des threads du noyau

Si vous construisez avec une chaîne d'outils personnalisée, assurez-vous qu'elle inclut tout jusqu'à la validation LLVM c336557f .

Utilisation de HWASan

Utilisez les commandes suivantes pour créer l'intégralité de la plate-forme à l'aide de HWASan :

lunch aosp_walleye-userdebug # (or any other product)
export SANITIZE_TARGET=hwaddress
m -j

Pour plus de commodité, vous pouvez ajouter le paramètre SANITIZE_TARGET à une définition de produit, similaire à aosp_coral_hwasan .

Pour les utilisateurs familiers avec AddressSanitizer, une grande partie de la complexité de construction a disparu :

• Pas besoin d'exécuter make deux fois.
• Les builds incrémentiels sont prêts à l'emploi.
• Pas besoin de flasher les données utilisateur.

Certaines restrictions d'AddressSanitizer ont également disparu :

• Les exécutables statiques sont pris en charge.
• Vous pouvez ignorer la désinfection de toute cible autre que libc. Contrairement à ASan, il n'est pas nécessaire que si une bibliothèque est nettoyée, tout exécutable qui la relie doit l'être également.

La commutation entre HWASan et des images régulières au même numéro de build (ou supérieur) peut être effectuée librement. Il n'est pas nécessaire d'essuyer l'appareil.

Pour ignorer la désinfection d'un module, utilisez LOCAL_NOSANITIZE := hwaddress (Android.mk) ou sanitize: { hwaddress: false } (Android.bp).

Désinfection des cibles individuelles

HWASan peut être activé par cible dans une construction normale (non nettoyée), tant que libc.so est également nettoyé. Ajoutez hwaddress: true au bloc de désinfection dans "libc_defaults" dans bionic/libc/Android.bp. Ensuite, faites de même dans la cible sur laquelle vous travaillez.

Notez que la désinfection de la libc permet le marquage des allocations de mémoire de tas à l'échelle du système, ainsi que la vérification des balises pour les opérations de mémoire à l'intérieur libc.so . Cela peut attraper des bogues même dans les binaires sur lesquels HWASan n'a pas été activé si le mauvais accès à la mémoire est dans libc.so (ex. pthread_mutex_unlock() sur un mutex delete() ed).

Il n'est pas nécessaire de modifier les fichiers de construction si toute la plate-forme est construite à l'aide de HWASan.

Flashstation

À des fins de développement, vous pouvez flasher une version d'AOSP compatible HWASan sur un appareil Pixel avec un chargeur de démarrage déverrouillé à l'aide de Flashstation . Sélectionnez la cible _hwasan, par exemple aosp_flame_hwasan-userdebug. Consultez la documentation NDK pour HWASan pour les développeurs d'applications pour plus de détails.

Meilleures traces de pile

HWASan utilise un dérouleur rapide basé sur un pointeur de trame pour enregistrer une trace de pile pour chaque événement d'allocation et de désallocation de mémoire dans le programme. Android active les pointeurs de cadre dans le code AArch64 par défaut, donc cela fonctionne très bien dans la pratique. Si vous avez besoin de vous détendre via du code managé, définissez HWASAN_OPTIONS=fast_unwind_on_malloc=0 dans l'environnement de processus. Notez que les mauvaises traces de pile d'accès mémoire utilisent le dérouleur "lent" par défaut ; ce paramètre affecte uniquement les traces d'allocation et de désallocation. Cette option peut être très gourmande en CPU, selon la charge.

Symbolisation

Voir Symbolisation dans "Comprendre les rapports HWASan".

HWASan dans les applications

Semblable à AddressSanitizer, HWASan ne peut pas voir le code Java, mais il peut détecter les bogues dans les bibliothèques JNI. Jusqu'à Android 14, l'exécution d'applications HWASan sur un appareil non HWASan n'était pas prise en charge.

Sur un appareil HWASan, les applications peuvent être vérifiées avec HWASan en créant leur code avec SANITIZE_TARGET:=hwaddress dans Make, ou -fsanitize=hwaddress dans les drapeaux du compilateur. Sur un appareil non HWASan (exécutant Android 14 ou une version plus récente), un paramètre de fichier wrap.sh LD_HWASAN=1 doit être ajouté. Consultez la documentation du développeur d'applications pour plus de détails.