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
_______________________________________________
gull mailing list
[email protected]
http://forum.linux-gull.ch/mailman/listinfo/gull
