Des documents divulgués révèlent que Google avait prévu, puis supprimé, une fonctionnalité de sécurité essentielle du Pixel 11 pour GrapheneOS

GrapheneOS, la version dérivée d’Android renforcée en matière de confidentialité et exclusivement installée sur les téléphones Pixel de Google depuis des années, indique qu’elle ne peut pas prendre correctement en charge la nouvelle série Pixel 11. Après une semaine passée à tenter de forcer la portabilité, l’équipe a constaté que la puce Tensor G6 du Pixel 11 ne disposait pas de la prise en charge matérielle d’une fonctionnalité appelée « Memory Tagging Extension » (MTE), une fonctionnalité de sécurité dont toutes les puces Pixel sont dotées depuis le Pixel 8 en 2023.

Voici en gros le fonctionnement de la technologie MTE : la mémoire de votre téléphone est une immense grille composée de petites cases de stockage. De nombreuses failles de sécurité consistent à tromper une application pour qu’elle lise ou écrive dans la mauvaise case, celle qu’elle n’était pas censée toucher. La technologie MTE empêche cela en apposant un post-it invisible sur chaque bloc de mémoire de 16 octets et sur chaque pointeur autorisé à y accéder. Si les post-its ne correspondent pas lorsqu’un programme tente de lire ou d’écrire, la puce freine brusquement, mettant fin au processus au lieu de laisser l’exploit passer inaperçu. GrapheneOS utilise la technologie MTE dans l’ensemble de son système d’exploitation et affirme qu’elle élimine des catégories entières de tentatives de piratage à distance avant même qu’elles ne puissent commencer. L’équipe affirme que Google semble avoir supprimé la technologie MTE du Pixel 11 pour faire des économies ; Google n’a pas fait de commentaire à ce sujet. GrapheneOS conseille désormais aux utilisateurs de ne pas acheter le Pixel 11 et d’opter plutôt pour un Pixel 8, 9 ou 10 s’ils souhaitent utiliser GrapheneOS.

Un article de recherche rédigé par des chercheurs de l’UT Austin, de l’UC Berkeley, de Google et d’Ampere Computing (arXiv:2601.11786) nous donne une idée du coût de mise en œuvre du MTE sur du matériel réel, ce qui nous indique également les économies qu’une entreprise réalise en s’en passant.

Les « sticky notes » elles-mêmes sont assez petites : 4 bits pour 16 octets de mémoire, soit environ 3,125 % de surcoût. Le cahier des charges d’ARM ne précise pas où les fabricants de puces doivent stocker ces « sticky notes », mais seulement qu’elles doivent exister quelque part. C’est pourquoi les entreprises procèdent différemment. La conception de référence d’ARM réserve un bloc dédié de RAM et effectue deux accès mémoire distincts en cas d’échec de mise en cache, l’un pour les données et l’autre pour la note adhésive correspondante. Ampere, qui fabrique des puces pour serveurs, intègre quant à lui les notes adhésives aux bits normalement utilisés pour la correction d’erreurs et récupère les données et la note en une seule opération. Aucune de ces deux approches n’est plus correcte que l’autre ; ARM a intégré cette flexibilité à dessein.

Le coût le plus important ne réside pas dans les 3,125 % de mémoire supplémentaire nécessaires sur la puce, mais dans le travail supplémentaire que celle-ci doit effectuer à chaque accès à la mémoire. Chaque fois que votre téléphone accède à la mémoire, il doit vérifier cette petite balise, ce qui nécessite des circuits de comparaison dédiés. L’attribution aléatoire des étiquettes, afin que les attaquants ne puissent pas les prédire, nécessite un générateur de nombres aléatoires intégré à la puce ; or, il est difficile d’en construire un rapide et doté d’une entropie suffisante sans faire de compromis. Quelques instructions spéciales destinées à l’écriture des étiquettes nécessitent leur propre voie de circulation au sein de la puce, plutôt que de réutiliser le chemin habituel.

Imaginez un cœur de processeur « out-of-order » comme une cuisine où plusieurs cuisiniers travaillent en parallèle sur différentes parties d’une commande, pas nécessairement dans l’ordre où celle-ci a été reçue, tant que rien ne dépend d’un élément qui n’est pas encore prêt. C’est généralement ainsi qu’un cœur moderne à exécution désordonnée conserve sa rapidité : il n’attend pas ; il traite tout ce qu’il peut pendant que les étapes plus lentes rattrapent leur retard.

Le mode SYNC strict de MTE vient perturber une partie de cette cuisine : l’écriture en mémoire. Normalement, un cœur peut écrire des données en mémoire et continuer à traiter les instructions suivantes pendant que cette écriture s’achève en arrière-plan. Mais en mode SYNC de MTE, chaque écriture doit d’abord faire vérifier et valider sa petite balise ; tant que cette vérification n’est pas validée, le cœur n’est pas autorisé à passer à l’écriture suivante. Ce n’est pas que toute la cuisine s’arrête net : la préparation (lectures, calculs, branchements, etc.) se poursuit sans problème hors ordre. C’est spécifiquement l’étape consistant à « poser l’assiette terminée » qui doit désormais se dérouler une par une, dans l’ordre, en attendant à chaque fois la vérification de l’étiquette. Le code qui écrit en mémoire de manière répétée dans une boucle serrée en subit constamment les conséquences, ce qui explique précisément pourquoi certains benchmarks ont vu leurs performances ralentir jusqu’à 6,64 fois. Le code qui effectue principalement des lectures, des calculs ou des branchements ne s’en rend pratiquement pas compte, car la partie du pipeline qui a ralenti n’est pas celle sur laquelle il s’appuie.

Même en mode allégé de MTE, le cœur « Big » standard a tout de même subi des ralentissements pouvant atteindre 1,82 fois la vitesse normale, et c’est précisément ce mode que la fonctionnalité Advanced Protection de Google utilise aujourd’hui. En revanche, la puce serveur d’Ampere et le nouveau M5 d’Apple n’ont pratiquement pas remarqué que le MTE était activé, avec une surcharge moyenne de seulement 2 à 3 %, et un ralentissement maximal de 10 %. Cet écart prouve que ces ralentissements ne relèvent pas d’une loi inévitable de la physique ; ils reflètent la qualité (ou la médiocrité) de la mise en œuvre de cette fonctionnalité par les ingénieurs d’une puce donnée. Et connaissant Tensor, nous n’en attendons pas grand-chose.

Si vous recherchez les mêmes éléments dans le bootloader du Pixel 11, vous n’obtiendrez rien. Pas la moindre trace. C’est une différence assez significative : si Google s’était contenté d’actionner un commutateur pour désactiver MTE, on s’attendrait tout de même à trouver ces noms de fonctions et ces messages dans le code, même s’ils n’étaient pas utilisés. Leur absence totale suggère que le code a été entièrement supprimé, et pas simplement désactivé. Cela corrobore exactement ce qu’a déclaré GrapheneOS après avoir renoncé à son portage.

Par ailleurs, GrapheneOS est en train de finaliser un accord avec Motorola afin d'intégrer pour la première fois ce système d'exploitation à un téléphone autre qu'un Pixel, tandis que Qualcomm a commencé à ajouter la prise en charge de la technologie MTE à ses dernières puces, notamment le Snapdragon 8 Elite Gen 5.

NotebookCheck a appris que Motorola travaille sur un téléphone phare dont le nom de code interne est « Wukong », conçu autour de la prochaine puce phare de Qualcomm, le Snapdragon 8 Elite Extreme Gen 6 (SM8975), qui devrait être dévoilée dans son intégralité lors du Snapdragon Summit le 22 septembre. À l’heure actuelle, il s’agit du seul appareil Motorola prévu autour de cette puce. Si « Wukong » devient finalement le smartphone de lancement de GrapheneOS chez Motorola, ce sera le premier à combiner une prise en charge MTE complète, une puce phare de Qualcomm et la prise en charge de GrapheneOS, ce que vous ne pouvez actuellement pas obtenir sur un Pixel 11, quel que soit le prix que vous soyez prêt à payer.

La mise en garde habituelle s’impose : à ce stade précoce du développement, les spécifications et même le nom de code « Wukong » proviennent de documents internes et sont susceptibles d’évoluer avant toute annonce officielle. Motorola n’a pas confirmé l’existence de ce téléphone.

Pour le consommateur lambda qui achète un Pixel 11, je ne pense pas que la perte de la protection MTE soit la catastrophe que cet article pourrait laisser croire.

La protection MTE repose sur des probabilités, ce n’est pas une garantie absolue. Il y a une chance sur seize qu’un accès hors limites donné échappe totalement au contrôle des balises, et les recherches citées dans le même article (TikTag) a réussi à compromettre la confidentialité des balises sur du matériel Pixel réel en utilisant l’exécution spéculative, ce qui signifie que même la protection qu’elle offre n’est pas, dans la pratique, aussi fiable que le suggère le rapport « 15/16 ». Et, surtout, la quasi-totalité des failles dont un propriétaire de téléphone lambda doit réellement se préoccuper ne sont pas, au départ, des bogues liés à la sécurité de la mémoire. Hameçonnage, autorisations d’applications malveillantes, échange de carte SIM, logiciels de harcèlement et prises de contrôle de compte : rien de tout cela ne relève de ce contre quoi le MTE protège. Même GrapheneOS admet que la couverture des applications tierces est facultative et rarement utilisée ; Signal ne l’active pas.

C’est dans le modèle de menace pour lequel GrapheneOS a été conçu que la technologie MTE prend tout son sens : des chaînes d’exploits « zéro clic » coûteuses et dépendantes de la fiabilité, du type de celles vendues pour des millions de dollars et utilisées presque exclusivement contre des journalistes, des dissidents et des cibles gouvernementales, et non contre le consommateur lambda. Il s’agit là d’un cas d’utilisation réel et important. Il est simplement très restreint. Un téléphone qui plante plutôt que d’être discrètement piraté est véritablement crucial si vous êtes une cible à haut risque surveillée par un acteur étatique. Cela a beaucoup moins d’importance si votre risque réel consiste à perdre votre téléphone dans un bar ou à cliquer sur un lien malveillant dans un SMS. Adopter de bonnes pratiques d’OPSEC, utiliser des mots de passe uniques, éviter les codes QR aléatoires et ne pas disséminer vos informations personnelles sur tous les sites web qui vous les demandent constituent, pour la plupart des gens, une protection bien plus efficace dans la vie réelle que ne le fera jamais n’importe quelle fonctionnalité de sécurité de la mémoire au niveau du silicium.

Cela ne signifie pas pour autant que la régression au niveau du silicium du Pixel 11 soit sans importance. La base d’utilisateurs de GrapheneOS correspond exactement au public pour lequel cela compte le plus, et la perte de la prise en charge de toute une génération de Pixel constitue un coup dur légitime pour ce projet. Mais il faut reconnaître honnêtement que la technologie MTE s’apparente davantage à une mesure d’atténuation de grande valeur destinée aux entreprises ou aux utilisateurs à haut risque, qui s’est retrouvée par hasard dans des puces grand public, qu’à une fonctionnalité dont l’absence sera remarquée par l’utilisateur lambda qui achète un Pixel 11. Et il y a une certaine ironie dans la manière dont Google en est arrivé là : c’est l’entreprise qui a, à l’origine, fait entrer le MTE dans le courant dominant, en l’intégrant à Tensor avant presque tout le monde sous Android, en finançant la recherche dans ce domaine et en construisant tout un mode de sécurité autour de cette technologie. Or, ses propres documents internes suggèrent qu’elle a intégré le MTE dans sa puce suivante, qu’elle l’a décrit en détail, puis qu’elle l’a discrètement supprimé avant le lancement. Personne n’a surpassé Google sur ce coup-là. C’est Google qui s’est lui-même privé de cette fonctionnalité.