[gull] Above Meltdown & Spectre

[Daniel Cordey]

Hy guys,

On 13. 01. 18 09:43, Dominik Madon wrote:
> Globalement, pour éliminer Spectre et Metdown (un cas particulier de Spectre), il faudrait que les fabricants de processeurs invalident toute entrée en cache chargée sur une prédiction de branchement erronée. On parle de changer la valeur d’un bit en cache. Cela dit, ce comportement était souhaité par les architectes (raison pour laquelle on le trouve sur des processeurs de fabricants différents) dans la mesure où le chargement en cache erroné conduit quand même à une augmentation des performances du CPU, les données (ou instructions) étant parfois utilisées ensuite.

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 ? 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...

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.

> Une bonne idée pour aller plus vite est détournée.

Quel est le vrai impact de cette "bonne idée" ? 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é. Ce n'est pas un jeu d'instructions conçu à partir de la 
mesure de performances. 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 ? Les "misprediction" coûtent très cher en exécution 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.

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. :-)

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... :-)

dc