[gull] Above Meltdown & Spectre

Tue Jan 16 18:43:42 CET 2018

> Ou, je vois... mais il il faut donc combiner Spectre et Meltdown pour faire vraiment des dégats. J'utilise Spectre pour exécuter du code qui va me permettre de modifier le bit de protection d'éxécution privilégié qui va ensuite me permettre de lire n'importe quelle adresse. Est-ce bien ça ?

Oui. L’anneau d’exécution ne revient à son niveau utilisateur qu’à la fin de l’exécution spéculative du code. La ligne chargée en cache l’est donc avec des droits supérieurs.

> Néanmoins, il n'est pas facile d'assurer que mon code sera exécuté dans ce mode "spéculatif" puisque ce type d'exécution est non-déterminé... non ? Il dépend entre autre de l'état de la cache à un instant T…

Au contraire, c’est un jeu d'enfant: On fait exécuter plusieurs fois le chemin avec un saut pris. L’exécution suivante, on sait que la spéculation ira dans le sens du saut pris mais le déterminant est changé.

> Le problème est sans doute amplifié par les processeurs avec une valeur de pipeline importante; comme l'architecture Kaby-Lake qui a un pipeline compris entre 14 et 18.

Oui, car avec 4 instructions en parallèle, on peut avoir une cinquantaine d’instructions en cours de traitement dans l’entier du pipeline.

> Quel est le vrai impact de cette "bonne idée » ?

Gigantesque en terme de performance. En 20 ans, la vitesse d’accès au premier octet en mémoire centrale n’a pas vraiment changé. On était proche de 100ns. On a pas doublé la vitesse d'accès. Seule la bande passante a été démultipliée pour alimenter des caches de plus en plus grandes. Les processeurs eux ont gagné un ordre de grandeur en terme de temps de cycle (1n pour 1GHz de fréquence d’horloge). Avec un processeur à 3GHz, 12 instructions entrent dans le pipeline toutes les 1 ns (avec 4 instruction en parallèle) alors que pour lire le premier octet de la première instruction en mémoire, il aura fallu attendre au moins 50ns ! Sans exécution spéculative et grosses caches, nos processeurs n’iraient pas beaucoup plus vite qu’il y a 10.

> Le jeu d'instruction IA-32 n'est de loin pas un modèle d'efficacité mais plutôt une gigantesque marmite où l'on trouve les dernières technologies à côté d'instructions archaïques que l'on doit conserver pour des raisons de compatibilité.

Pas tout à fait juste. Depuis le Pentium, la plupart des instructions IA-32 sont converties en micro-instructions de type RISC. Le pipeline des CPU intel exécute en fait des instructions qui lui sont propres et sont d'un grain plus fin que celle du jeu d’instruction IA-32.

> Ce n'est pas un jeu d'instructions conçu à partir de la mesure de performances.

C’est juste, il est très ancien. C’est pour cela que les micro-instructions ont été introduites par Intel.

> Gageons que jamais personne n'a fait de mesure à ce sujet mais que l'on ne sait pas donné la peine d'invalider ces instructions dans la cache par simple flemme (travail supplémentaire), en se disant que ça pourrait servir dans certains cas (à priori pas faux)... Quel impact de cette "bonne idée" sur le CPI réel d'une application ?

De nouveau, on s’est posé la question. Invalider une entrée propre de la cache pour autre chose qu’un remplacement par d’autres données ou instructions utiles diminue les performances. C’est la raison pour laquelle personne n’a pensé à cette façon de voler des données. Ne pas le faire eut été montrer des performances moindre. A la course au meilleur benchmark, c’est suicidaire. Chaque fois qu’on fait un cache flush, on paie un prix considérable en terme de données à charger depuis la mémoire à la vitesse d’un escargot comparativement à la vitesse d’accès de la cache de niveau 1.

> Les "misprediction" coûtent très cher en exécution

C’est faux, ils ne coûtent rien puisque ne pas prédire c’est ne rien faire (le processeur attend d’avoir le résultat pour continuer en se tournant les bits) et que c’est la pénalité maximum pour le CPU: autant faire entrer des instructions qu’on exécute dans le doute.

S’il est 14h et qu’à 15h on te dit que tu auras une heure pour rédiger un composition sur les pommes ou les poires mais que tu ne sauras pas avant 15h s'il s'agira des pommes ou des poires, il vaut mieux commencer à rédiger tout de suite quelque chose sur les poires sans attendre, quitte à le refaire sur les pommes dès 15h. Si les pommes et les poires sont équiprobables, une fois sur deux, tu "exécutes" ta composition en temps nul. C’est d’autant mieux lorsque tu as des indices qui te permettent de prédire 90 à 95% du temps si ça sera pommes ou poires. Prédire juste à 90-95%, c’est être bien meilleur en terme de performance comparativement à ne pas spéculer du tout.

> et il y a bien des cas où cela "pourrait" être utile de conserver une ligne d'instruction dans la cache, mais on ne peut simplement spéculer sur un tel impact lorsque l'on connait la complexité du problème entre pipeline-icache-RAM. En l'absence de mesure et d'analyse solide on ne peut conclure de manière sûre que cela aura un effet positif, et mesurable, sur le CPI (Cycle Per Instruction) sur les application et surtout sur l'ensemble du système lui-même.

Pas d’accord. Des analyses et des mesures solides, il y en a pléthore ! Tous les articles sur l’architecture des ordinateurs vont dans le même sens. On peut discuter de la représentativité des benchmark qu’on utilise pour mesurer les performance, ce qui veut dire qu’on peut se disputer pour savoir si le gain est, dans la réalité plus proche de tel ou tel benchmarks lorsqu’on met en place un élément de l’architecture ou un autre, mais on ne discute plus de l’intérêt de ces dispositifs. On ne trouve plus de processeur sur le marché de la performance qui ne fasse pas du spéculatif. 

> Il faut rajouter à cette problématique le fait d'avoir plusieurs "cores" avec "N" canaux pour accéder à la RAM. Ce qui fait que le fonctionnement de l'exécution spéculative dépendra du type de processeur et des autres processus exécutés en même temps, avec le doux mélange de la complexité du contenu des caches L1, L2 et L3 de chaque core, ainsi que de l'occupation du bus mémoire à l'instant T. :-)

Oui, et de nouveau, on peut exploiter une cache de niveau 3 entre processeurs différents sur le même silicium pour pomper des informations entre threads ou processus ! L’article de Liu et Yarom (Last-Level Cache Side-Channel Attacks are Practical) est très clair la dessus. La complexité est l’ami des hackers car ils en exploitent la mauvaise maîtrise de leur architectes.

> Ce qui me fait penser que le succès de l'exécution de Spectre est peut-être plus aléatoire qu'on ne le pense (sans enlever sa dangerosité potentielle !). Mais peut-être suis-je complètement à côté de la plaque... :-)

Je dirai que cette affirmation est très spéculative :-)

Il y a déjà des proofs of concepts qui existent, notamment sur github.

Dom