De subtils bogues de mémoire, y compris des dépassements de mémoire tampon et des erreurs de pointeur, créent des bombes à retardement dans vos applications. Des acteurs malveillants peuvent exploiter ces bogues pour exécuter du code non autorisé, prendre le contrôle de systèmes pour les ajouter à des botnets malveillants ou simplement provoquer le blocage d’applications et de systèmes. Le tristement célèbre ver Morris de 1988 était l’un des premiers exemples d’une application malveillante exploitant un débordement de tampon. Les annonces de problèmes de sécurité de la mémoire créant des exploits potentiels arrivent à une fréquence alarmante, provenant soit de chercheurs en sécurité, soit de découvertes en liberté dans la nature.

L’impact sur les utilisateurs peut être considérable. Les applications malveillantes peuvent tirer parti d’une mémoire non sécurisée afin d’accéder à des données sensibles, telles que les informations d’identification et les mots de passe des utilisateurs, permettant d’accéder à des niveaux de privilège plus élevés dans le système. Cela permet à des acteurs malveillants d’accéder à des données confidentielles ou d’intégrer le système à un botnet plus vaste. Ce ne sont pas toujours des forces extérieures qui causent des problèmes – parfois une mémoire non sécurisée entraîne des pannes système imprévisibles en raison de fuites de mémoire et de problèmes connexes, frustrant les utilisateurs. On estime que les deux tiers de toutes les vulnérabilités Android sont dues à des pratiques de mémoire dangereuses.

Armer l’extension de marquage de mémoire

Les solutions logicielles, y compris Address Sanitizer (Asan), aident à atténuer ces problèmes de mémoire en intégrant la détection de corruption de mémoire dans les compilateurs modernes. Cependant, Asan nécessite l’ajout d’une instrumentation logicielle au code d’application, ce qui peut considérablement ralentir l’exécution de l’application et augmenter l’utilisation de la mémoire, particulièrement problématique dans les systèmes mobiles et embarqués.

Ce qu’il faut, c’est une solution pour détecter et minimiser les bogues de mémoire avec un impact minimal sur les performances et l’utilisation de la mémoire. La mise en œuvre correcte d’une méthode basée sur le matériel pour détecter une utilisation de la mémoire potentiellement dangereuse entraîne une utilisation de la mémoire plus petite et de meilleures performances, tout en améliorant la fiabilité et la sécurité du système.

Arm a introduit son extension de marquage de mémoire dans le cadre du jeu d’instructions Armv8.5. MTE est désormais intégré aux processeurs compatibles Armv9 récemment annoncés par Arm, tels que le Cortex-X2, le Cortex-A710 et le Cortex-A510. Les futurs processeurs basés sur Armv9 intégreront également MTE. Ceux-ci incluent tous le marquage de la mémoire en tant que partie de base de l’architecture.

L’idée derrière le balisage de la mémoire est assez simple : ajouter un petit ensemble de bits à des morceaux de mémoire pour les identifier comme sûrs pour l’utilisation des applications. Arm implémente l’étiquetage de mémoire en tant que système à deux phases, connu sous le nom de serrure et clé :

  • Marquage d’adresse. Cela ajoute quatre bits en haut de chaque pointeur dans le processus. Le balisage d’adresses ne fonctionne qu’avec les applications 64 bits, car il utilise le top-byte-ignore, qui est une fonctionnalité Arm 64 bits. Les balises d’adresse agissent comme une « clé » virtuelle.
  • Marquage de la mémoire. Les balises de mémoire se composent également de quatre bits, mais sont liées à chaque région alignée de 16 octets dans l’espace mémoire de l’application. Arm fait référence à ces régions de 16 octets comme baliser les granulés. Ces quatre bits ne sont pas utilisés pour les données d’application et sont stockés séparément. L’étiquette de mémoire est le « cadenas ».

Une étiquette d’adresse virtuelle (clé) doit correspondre à l’étiquette mémoire (cadenas). Sinon, une erreur se produit.


Figure 1. Montre un exemple de serrure et d’accès clé à la mémoire

Étant donné que l’étiquette d’adresse doit correspondre à l’étiquette mémoire, la première chose que vous remarquerez peut-être est que 4 bits ne représentent que 16 variantes. Cela fait de MTE un processus stochastique, ce qui signifie qu’il est possible qu’une clé corresponde de manière incorrecte à une serrure différente. La probabilité que cela se produise est inférieure à 8%, selon Arm.

Étant donné que les balises d’adresse et de mémoire sont fréquemment créées et détruites à la volée, les unités d’allocation de mémoire fonctionnent pour s’assurer que les balises de mémoire séquentielles diffèrent toujours. MTE prend également en charge la génération de balises aléatoires. La combinaison de l’allocateur de mémoire comprenant que les balises séquentielles doivent être différentes et de la fonction de génération de balises aléatoire signifie que la fréquence réelle des conflits de balises est assez faible. De plus, l’exécution de MTE sur une flotte de millions (ou de milliards) d’appareils peut fournir une détection d’erreur robuste pour le système et les logiciels d’application.

Architecture sous-jacente

Armv8.5 et v9 implémentent un nouveau type de mémoire, qu’Arm dubs Normal Tagged Memory. La CPU peut déterminer la sécurité d’un accès mémoire, en comparant une étiquette d’adresse à l’étiquette mémoire correspondante. Les développeurs peuvent choisir si une incompatibilité de balise entraîne ou non une exception synchrone ou est signalée de manière asynchrone, ce qui permet à l’application de continuer. La figure 2 montre comment MTE est implémenté dans les conceptions de CPU ARM.


Figure 2. Armer la solution de calcul totale (Armv9)

Les détails des discordances asynchrones s’accumulent dans un registre système. Cela signifie que le système d’exploitation peut isoler les incompatibilités avec des threads d’exécution spécifiques et prendre des décisions en fonction des opérations en cours.

Les exceptions synchrones peuvent identifier directement l’instruction de chargement ou de stockage spécifique provoquant des discordances de balises. Arm a ajouté une variété de nouvelles instructions au jeu d’instructions pour manipuler les balises, gérer le pointeur et le marquage de pile, et pour une utilisation système de bas niveau.

Mise en œuvre du bras MTE

MTE est géré dans le matériel ; les instructions de chargement et de stockage ont été modifiées pour vérifier que l’étiquette d’adresse correspond à l’étiquette de mémoire, et l’allocation de mémoire matérielle assure la randomisation de la création d’adresse et d’étiquette de mémoire. Cela a des implications différentes pour les développeurs de systèmes d’exploitation et les programmeurs d’applications pour utilisateurs finaux.

Arm a amélioré son interconnexion cohérente AMBA 5 pour prendre en charge MTE. La logique de vérification des balises est généralement intégrée au cache au niveau du système, la vérification et la mise en cache des balises ayant lieu avant l’interface DRAM. La figure 3 montre un exemple de schéma fonctionnel.


figure 3: Exemple de schéma fonctionnel montrant comment MTE peut être implémenté dans une conception SoC. (Source : Bras)

Les systèmes d’exploitation doivent être modifiés afin de prendre pleinement en charge MTE. Arm a initialement prototypé MTE en créant une version du noyau Linux qui implémentait des balises. Google a exprimé son intention d’ajouter MTE à Android et travaille avec les développeurs de SoC pour assurer la compatibilité.

Les développeurs d’applications pour utilisateurs finaux ont un peu plus de facilité à supposer la prise en charge du système d’exploitation pour MTE. Étant donné que MTE se produit dans les coulisses du système d’exploitation et du matériel, les applications ne nécessitent aucune modification du code source. Le marquage MTE pour la mémoire de tas ne nécessite aucun effort supplémentaire. Cependant, le marquage de la mémoire sur les runtimes existants à l’aide de la mémoire de la pile nécessite la prise en charge du compilateur, les binaires existants doivent donc être recompilés. C’est simple, car les développeurs d’applications mobiles publient de toute façon fréquemment des mises à jour. La figure 4 montre le calendrier de développement du logiciel lors de la mise en œuvre du MTE.


Figure 4 : Calendrier de développement logiciel avec MTE

S’assurer que la mémoire est protégée peut nécessiter l’alignement des objets mémoire sur le Tag Granule (alignement sur 16 octets). Cela peut augmenter l’utilisation de la pile et de la mémoire, bien que l’impact semble être assez minime.

Pourquoi utiliser Arm MTE ?

MTE propose plusieurs améliorations de la qualité de vie pour les développeurs. MTE permet aux programmeurs de trouver rapidement les bogues liés à la mémoire, accélérant ainsi le processus de débogage et de développement des applications. Étant donné que les bogues de mémoire peuvent être détectés et annulés plus tôt, les problèmes tels que les fuites de mémoire, les conditions de concurrence de mémoire et d’autres plantages liés à la mémoire deviennent plus rares. Cela améliore à son tour l’expérience de l’utilisateur final.

Les bogues de sécurité de la mémoire représentent environ les deux tiers de tous les bogues courants de vulnérabilité et d’exposition (CVE), donc MTE permet aux entreprises de livrer des applications plus rapidement avec moins de bogues. Les utilisateurs finaux peuvent souvent être réticents à passer à un nouveau matériel ou logiciel de système d’exploitation, mais MTE leur donne des raisons tangibles de mettre à niveau, notamment une stabilité et une sécurité globale améliorées.

Informations complémentaires

Vous pouvez trouver des informations plus détaillées sur les extensions de marquage de mémoire d’Arm dans diverses sources.