Cela faisait un certain temps que nous n’avions plus vu passer de failles liées à l’exécution spéculative de la série Meltdown et Spectre, c’est-à-dire des attaques abusant de la capacité du CPU à traiter des données avant d’être certain de leur exactitude. Découvertes en 2017, ces familles de faille n’ont cessé de se multiplier au fur et à mesure que des nouvelles traces de l’exécution spéculative étaient trouvées à divers endroits du CPU.
Avec le temps, nous aurions pu croire que tout avait été découvert : il n’en est rien ! En effet, des chercheurs de l’Université de Californie à San Diego ont découvert un moyen plus retors encore d’exploiter Spectre-V2 (Branch Target Injection, pour être précis), nommé « Indirector », publiée à la conférence USENIX Security Symposium, qui se déroulera en août prochain. Touchant a minima les processeurs Raptor Lake et Alder Lake, son principe réside dans la connaissance du fonctionnement interne d’une des mémoires cache utilisée dans la prédiction de branchement. Il devient alors possible de créer un processus malicieux injectant des adresses pourries dans ce cache depuis l’autre cœur logique d’un CPU HyperThreadé, permettant ainsi de casser les protections interprocessus en obtenant des informations normalement inaccessibles : pas cool !
Intel, de son côté, a accusé réception de la chose, mais juge que les protections en place sont suffisamment solides pour ne pas avoir à modifier quoi que ce soit — la méthodologie d’attaque étant trop complexe pour être utilisée en pratique. À l’inverse, les chercheurs appellent à utiliser de manière automatique le correctif IBPB visant à vider les buffers susceptible de fuiter des informations à chaque changement de contexte… ce qui n’est pas le cas sous Linux du fait d’un coût prohibitif en performance. En ce qui concerne les designs futurs, il faudra rajouter des informations au système de prédictions de branchement afin de pouvoir contrôler les permissions d’accès des zone mémoires chargées spéculativement et, ainsi, éviter les accès interdits. (Source : Tom’s Hardware)
Par ici pour le site crée pour l’occasion !
Toutes ces attaques plus théorique que pratique vont disparaitre avec la suppression du SMT, prenez des notes AMD 😀
Vu le coût prohibitif d'une telle idée, pas certains que ça en vaille la peine. Le SMT apporte de plus gros gain encore que leur fameux 3DVCache. Surtout en appli, pour le coup.
Mieux vaudrait peut-être une architecture hybrid, avec des cœurs dédié à la sécurité, sans spéculation aucune, ni smt, mais pour des tâches spécifiques, clairement identifiées critiques.
d’âpres les chiffres d’Intel le gain a surface égale n'est pas si fabuleux surtout avec tous les patchs de sécurité.
C'est du 20 à 30% généralement. Mais 0 en jeu. Là où le VCache compte pour 15 à 20% en jeu, mais négatif (-5) en appli, du fait de la perte en fréquences.
Intel sort les chiffres qui l'arrange, pour justifier ses choix. Et sur mobile effectivement, c'est des compromis à faire entre différent facteurs. Sur bureau cependant, aucun compromis à faire, ya que les perfs qui comptent.
(d'ailleurs même sur mobile, je ne comprends pas trop la logique à contenir la surface, sauf pour des raisons de prix)
Nan, ça c'est la version naïve de la sécurité hardware, complètement balayée par les scientifiques et qui sert d'argument peu constructif sur comment éviter une attaque.
Déjà, parce que les attaques par canaux auxiliaires ne dépendent pas forcément du SMT, l’infiltration par le SMT est une des attaques possibles parmi tant d'autres. Même débat sur la spéculation, le ratio sécurité/perte de performance est impossible à faire si tu te base sur de la pure et simple élimination de la source.
Ce qu'il faut vraiment faire par contre, c'set revoir les architectures, avec des outils pour mitiger (rendre plus difficiles) les attaques, puisque de toute façon on en trouve toujours des nouvelles. On en avait déjà discuté ici, mais couper des fonctionnalités pour la "sécurité", c'est plus une solution de la flemme qu'une vrai réflexion.
Des cœurs plus simples, moins complexes, pensés dès les premières lignes pour la sécurité, avant les performances (avec dans le cas présent, un IBPB forcée, peu importe les coûts). Et à l'OS de les sélectionner lorsqu'il a un thread sensible à faire tourner (manipulation de mot de passe, de données chiffrés, etc.., peut-être prévoir de nouveaux mots-clé dans les langages pour tagger les variables et sections critiques...).
Le SMT et la spéculation ajoute de la complexité, et les ingénieures dans le domaine ont prouvé avec le temps leur total incapacité à rendre ces choses-là totalement sécurisé. Tôt ou tard, de nouvelles failles sont découvertes. Alors ça devrait être les premières choses à dégager. Mais pas à n'importe quel prix. Pour des tâches lambda, sur des cœurs mainstream, leur gains est trop précieux. Là ça devrait rester.
Des processeurs plus simples sont d'autant plus simples à attaquer. Là où tu vas perdre les possibilités d'attaques par le partage, tu renforce les possibilités par l'écoute, comme déjà dit, t'as pas de solution magique, encore moins en dégageant des unités.
L'unique solution est d'utiliser des architectures fiables et résilientes, mais c'est pas si simple à mettre en oeuvre, qu'importe la complexité du CPU. Autre point important, Spectre tout le monde en parle, mais l'attaque est extrêmement difficile à exploiter en dehors d'un labo, donc bon l'intérêt de virer ces optimisations, c'est joli sur le papier, c'est actuellement inutile, et probablement que ça ne sera qu'une supposition théorique à jamais (à force que les attaques soient mitigées petit à petit).
De l'écoute, avec un seul processus, et un clear complet des états entre les changements de contextes? C'est encore possible, ça, sans avoir l'oreille collé directement sur le proc?
Une conception plus simple dans l'exécution signifie aussi qu'il est plus facile d'anticiper tous les chemins d'exécution, et avec eux, toutes les attaques potentielles, et ainsi les prévenir et les colmater. Quit à complexifier l'implémentation. Mais pour la sécurité cette fois, et non pour prendre des raccourcis pour obtenir des résultats plus rapidement.
Et c'est certains, ça, que tous les patchs de mitigation de Spectre, grevant les perfs de 10 ou 15%, personnes ne les a appliqué? Pas même sur les serveurs?
Tout dépend ce que tu vois dans l'écoute, mais globalement les Side Channel Attacks sont de plus en plus étudiées, avec des modèles d'attaque de plus en plus complexe et via des points différents. Avoir un système simple, c'est le rendre plus facile à reverse ou à attaquer, à l'inverse nos pires modèles d'attaque généralement sont ceux ou le CPU, même avec des vulnérabilités, est bourré d'unités secondaires, de systèmes qui tournent en parallèle etc...
Quant aux patchs, si, ils ont été appliqués bien entendu, ce qui a justement grandement amoindri (voire rendu quasi nul) les attaques Spectre facile à appliquer, ajd les seuls vraiment utilisables demandent des modèles d'attaques clairement impossible dans un contexte réaliste. Attention, ces failles sont bien présentes et dangereuses, toutefois il faut bien identifier si les scénario sont réalistes. Beaucoup de papiers dans la sécurité informatique spécifient le contexte et le modèle d'attaque, et bien souvent ils sont loin d'être exploitables facilement dans une grosse baie de serveur pour plein de raisons : connaissances à avoir sur la cible, isolation logique, bruit de fond des gros systèmes HPC...
Il faut aussi que les données récupérées soient potentiellement exploitables au point d'avoir un contrôle ou un accès à l'intégralité de ce qui se passe à l'aveugle sur une serveur distant. Et là aussi, entre théorie et pratique, c'est parfois très compliqué.
Je me préoccupe des attaques à distance, avec du code malicieux, pas des intrusions physiques sur la machine, si c'était ta question.
Que reste-t-il du "Side Channel", si tout est parfaitement cloisonné/purgé entre les changements de contextes? Le Out-of-Order et l'exécution multiple me parait (à mon niveau de profane) assez bien maîtrisé/prédictif. Ça ça ne serait pas à jeter. Il ne s'agirait pas non plus de revenir 50 ans en arrière, à des cœurs complètement basique de niveau académique.