Q1 — Depuis 2022, qu’est-ce qui a vraiment changé en sécurité microarchitecturale ?
Maria Mushtaq : Le champ s’est élargi et structuré. Il ne se limite plus aux canaux auxiliaires basés sur les caches — ces mémoires ultra-rapides qui conservent temporairement les données les plus utilisées mais laissent aussi des indices exploitables. Le tableau général montre des fuites diffuses, qui exploitent la complexité de plusieurs sous‑systèmes à la fois. Aujourd’hui les regards se portent sur des composants microarchitecturaux comme les prédicteurs de branchement, qui devinent la suite d’un programme, l’exécution spéculative, qui calcule en avance pour gagner du temps mais laisse des informations résiduelles, ou les unités de pré‑chargement d’instructions. À cela s’ajoutent des composants liés à la mémoire comme le TLB (Translation Lookaside Buffer) et le row‑buffer de la DRAM (mémoire vive dynamique), nous y reviendrons. L’ensemble de ces mécanismes est désormais étudié avec des modèles formels et des simulateurs afin de repérer des vulnérabilités plus tôt.
Q2 — En 2018, les attaques Spectre et Meltdown ont marqué le domaine de la sécurité des processeurs. Comment ont-elles ouvert la voie aux failles suivantes ?
M. M. : Spectre manipule les prédicteurs de branchement pour exécuter des instructions hors de leur cadre normal et laisser des traces. Meltdown, de son côté, exploite un défaut d’isolation entre mémoire du noyau et applications pour lire des données protégées. Leur impact a été majeur sur la recherche systématique de vulnérabilités, l’analyse formelle, et l’étude des mécanismes de défense à la fois aux niveaux matériel et logiciel. Même si la couverture médiatique a diminué, la dynamique créée au sein de la communauté scientifique n’a pas faibli. Et de nombreuses autres attaques ont été révélées depuis, parmi lesquelles : Downfall, qui détourne des instructions de traitement vectoriel, Zenbleed, qui touche la microarchitecture AMD Zen 2 [ndlr : une classe de processeurs lancée par le fabricant AMD en 2019] et permet d’en récupérer des informations sensibles, ou encore, dans le domaine des navigateurs, iLeakage, capable d’extraire des informations sensibles depuis Safari, et les offensives via WebGPU. Toutes rappellent que la menace reste vive, jusque dans les usages quotidiens.
Q3 — Quels sont les composants vulnérables à surveiller aujourd’hui ?
M. M. : Plusieurs éléments nécessitent une analyse approfondie. J’ai parlé du TLB par exemple, qui agit comme un carnet d’adresses qu’utilise le processeur à chaque accès mémoire. Sa manière de répondre, plus ou moins rapidement, est révélatrice d’habitudes exploitables. Également, le row-buffer de la DRAM fonctionne comme une page déjà ouverte : si la prochaine requête vise la même page, l’accès est immédiat ; sinon, un délai apparaît. Ces différences créent un canal de fuite. À l’intérieur du cœur, le mécanisme de transmission entre écritures et lectures successives, appelé store-to-load forwarding, optimise la rapidité mais, mal exploité, ouvre la voie à des exfiltrations. Enfin, une vigilance accrue est portée aux canaux entre fils d’exécution ou entre cœurs, du fait qu’ils utilisent un état partagé – des zones communes du processeur où plusieurs programmes accèdent aux mêmes ressources et laissent aussi des traces exploitables.
Q4 — Dans quels environnements ces failles sont-elles les plus préoccupantes : navigateurs, cloud, edge… ?
M. M. : À vrai dire, le risque est PARTOUT. Les navigateurs, via JavaScript ou WebAssembly [ndlr : des langages de programmation], offrent des surfaces d’attaque exploitables directement depuis une page web. Mais les environnements mutualisés comme le cloud et la virtualisation sont particulièrement sensibles, car l’isolation matérielle est moins garantie, plusieurs utilisateurs partagent la même machine : une faiblesse microarchitecturale est plus à même de franchir ces frontières logiques pourtant censées isoler les usages. De même pour les systèmes embarqués et edge, dont la diversité de briques matérielles, combinée à des contraintes fortes de performance, ajoute à la difficulté.
Q5 — Pourquoi faut-il raisonner « de bout en bout » entre matériel et logiciel ?
M. M. : La plupart des attaques repose sur un décalage entre ce que fait le matériel et ce que suppose le logiciel. Les compilateurs (programmes qui traduisent le code écrit par les développeurs en instructions compréhensibles par le processeur) intègrent par exemple des techniques comme les « retpolines » (return trampolines), qui modifient les sauts, autrement dit la façon dont le programme décide quelle instruction exécuter ensuite, afin de contrer certaines variantes de Spectre. Une autre approche est la programmation dite « en temps constant », qui vise à exécuter chaque instruction en un temps identique pour éviter de révéler des informations sensibles. Concrètement, cela consiste à uniformiser la durée des calculs et des accès mémoire, même lorsque certains traitements pourraient aller plus vite, afin de ne pas donner d’indices mesurables sur la nature des données manipulées. Mais ces méthodes n’ont d’effet que si le processeur adopte un comportement prévisible. Et, un correctif matériel n’est utile que si le système et les outils logiciels l’activent correctement. De même pour les enclaves matérielles, comme Intel SGX (Software Guard Extensions) ou Arm TrustZone, qui sont conçues pour renforcer l’isolation : elles améliorent la protection mais présentent des vulnérabilités et doivent être complétées par des évaluations et des correctifs continus. C’est pourquoi il est indispensable de penser la sécurité à travers l’ensemble de la pile informatique, de la puce au logiciel.
Q6 — Comment protéger concrètement la sécurité de la pile informatique ?
M. M. : Les chercheurs disposent aujourd’hui d’outils variés. Certaines mesures – comme la programmation en temps constant ou les enclaves pour les ressources matérielles partagées – sont bien établies mais pas toujours appliquées de manière homogène. Par ailleurs, certaines caractéristiques des processeurs modernes obligent à repenser les modèles de menace, en particulier pour les systèmes multi‑utilisateurs ou temps réel. Plusieurs approches sont prometteuses. Le fuzzing, par exemple, automatise la génération de séquences d’instructions inhabituelles pour observer comment réagit le processeur et mettre en évidence des fuites jusque-là insoupçonnées. Des recherches comme Osiris ont fait leurs preuves en s’appuyant sur cette méthode. D’autres travaux utilisent des plateformes de simulation tels que gem5, pour créer des bancs de test automatisés pour les fuites microarchitecturales. Elles permettent de comparer des variantes de processeurs, d’ajouter des compteurs de performance, et de tester des hypothèses. Enfin, des moniteurs d’exécution installés sur les machines observent en continu des indicateurs comme les compteurs matériels et peuvent signaler une fuite en situation réelle. Ces techniques restent en développement actif mais laissent entrevoir un potentiel d’adoption plus large.
Q7 — L’intelligence artificielle est-elle une alliée ou une nouvelle menace pour la sécurité microarchitecturale ?
M. M. : Les deux à la fois. L’apprentissage automatique sert déjà à classer des empreintes de fuites, à détecter des comportements anormaux et à prédire des séquences fragiles dans des systèmes trop complexes pour être analysés à la main. Mais l’essor des accélérateurs pour l’IA introduit aussi de nouvelles aires d’attaque. Certains travaux montrent que l’usage intensif de ces unités favorise des fuites temporelles exploitables. Et si demain des prédicteurs de branchement enrichis par l’IA sont manipulés par un attaquant, ils pourraient contourner la spéculation du processeur. Le sujet exige donc une collaboration étroite entre spécialistes de l’IA et de la microarchitecture, et reflète le fait que les attaques sont en constante évolution et deviennent plus transversales. C’est pourquoi nous avons élargi le programme de la Winter School 2025 autour de ces thématiques, afin d’offrir aux participants une vision complète du champ de menaces.
