Une faille de plus sur les processeurs AMD comme Intel : les spectres des muOPs mortes sont de retour !

Avec la tonitruante découverte des vulnérabilités Meltdown et Spectre, un grand pan de la microarchitecture moderne a volé en éclat. En effet, alors que l’on considérait jusqu’alors que la spéculation sur des données non vérifiées ne posait aucun problème, voilà que des scientifiques ont prouvé le contraire en extrayant à partir des traces restantes d’exécutions annulées des informations allant jusqu’au... contenu complet de la RAM. Suivant cette méthode d’abus du processeur en entraînant à tort la prédiction afin de charger spéculativement tout et n’importe quoi, de nombreux autres travaux ont vu le jour, changeant principalement le canal auxiliaire par lequel fuitent les informations, ainsi que la méthode de spéculation.

Le travail du jour se place dans la même veine : réalisé par des chercheurs de l’University of Virginia et l’University of California, San Diego, cette faille nommée « I See Dead μops » consiste cette fois-ci à abuser du cache des micro-Ops. De quoi s’agit-il, exactement ? En interne, les processeurs doivent décoder une à une les instructions x86 composant un programme en micro-Ops (ou µOPs) : une opération coûteuse du fait de l’ancienneté de la chose, et de choix de design qui se sont révélés malheureux par la suite. Heureusement, ces problèmes sont la plupart du temps masqué par une mise en cache des instructions déjà décodées, qui se retrouve — chez Intel comme chez AMD — dans un µOP cache, parfois appelé Loop Stream Buffer (du fait que les µOPs décodées ne sont réutilisées... que dans le cas de boucles).

Le comptoir des profa facile vous accueille tous les trolldredi, à Kotte-Le-Zoute !

Un des soucis réside dans le fait que la politique de remplacement de ce cache est optimisée pour les performances : les µOPs conservées en priorité sont celles des boucles exécutées le plus grand nombre de fois, et non les dernières récupérées. Rajoutez une histoire d’inclusivité avec les caches parents (L1-I et I-TLB) permettant de retirer pour sûr des instructions du cache en remplissant l’un des parents, et vous obtenez une situation propice à la transmission d’informations par canal auxiliaire : deux threads peuvent se passer des informations via l’état du µOP cache ; et, dans le cas d’AMD seulement, deux hyperthreads partageant le même cœur physique — chez Intel, ce cache est divisé de manière statique entre les deux cœurs logiques : aucune information ne peut fuiter. Nos vecteurs d’attaques étant définis, il ne reste qu’à utiliser une mauvaise prédiction pour charger conditionnellement certaines µOPs dans le cache en fonction d’une donnée mémoire protégée, et utiliser votre méthode de « réception » d’information pour en déduire sa valeur.

Avec un accès décomposé bit par bit, mais pourtant une vitesse 3 fois plus grande que celle des failles originales (notamment du fait d’une latence bien plus faible du µOP cache par rapport au cache de données utilisé dans les Spectre et Meltdown initiaux), la faille a de quoi faire froid dans le dos, d’autant plus qu’une rustine risque de coûter lourd en performance, puisque limitant la spéculation ou vidant le µOP cache lors d’accès mémoires protégés. Par contre, un doublement de ce cache afin de séparer les µOP protégées des µOPs non protégé pourrait être effectué à l’avenir, limitant ainsi grandement les risques sans pour autant les annuler totalement... et en réduisant le taux d’utilisation du cache.

Cependant, gardez en tête que ces mécanismes ne peuvent être utilisés que si l’attaquant possède les droits d’exécution sur votre machine, ce qui n’est plus possible si vous utilisez un navigateur web à jour du fait d’un timer rendu volontairement suffisamment imprécis pour éviter toute exploitation en JavaScript de ces attaques. Reste que, pour les serveurs et les VM en location, une telle faille n’est clairement pas souhaitable... Un argument de plus pour vendre du matériel mis à jour ?