COMPTOIR
register

Composé par ————— —— 15114 vues

Meltdown sur AMD : une faille découverte chez les rouges ?

Si vous ne connaissez pas Meltdown, il s’agit d’une chaîne de bars bien branchés orientée jeux vidéos et pop culture, dont la succursale parisienne date de 2012. Une entreprise visionnaire, puisque son nom a été par la suite propagé et popularisé par une série de failles désormais longue comme le bras visant à altérer un état microarchitectural afin d’un faire un canal de communication imprévu. Si cela peut être tout bonnement inutile, il suffit qu’un programme sensible y laisse des traces pour que la chose devienne sérieuse, ce qui peut aller jusqu’à la mise à mal de toute la sécurité d’un système.

 

Jusqu’à présent, l’entreprise la plus touchée est sans aucun doute Intel, non pas que ses produits soient significativement moins sécurisés que les autres, mais plutôt du fait des implémentations encore trop basse performance d’ARM pour être concernée, et d’un AMD en retrait sur le plan des parts de marchés, et donc sur la recherche en cybersécurité. Pour autant, les cartes sont constamment rebattues, et voilà que les tendances s’inversent, avec une croissance progressive des rouges sur les datacenters... et donc sur la recherche qui y est associée. Est-ce donc vraiment une surprise de voir une nouvelle faille de la série Meltdown sur matériel rouge uniquement ? La réponse se situe dans la question ; et c’est ainsi davantage dans le coût au niveau performance qu’il faut se plonger.

 

amd broken logo

 

Revenons d’abord sur la vulnérabilité en elle-même : découverte par deux chercheurs de l’École polytechnique royale de Dresde et reconnue par AMD, la nouvelle venue est également répertoriée sur la base de données CVE, à la place 2020-12965. Son exploitation se base sur le système de pagination de la mémoire, qui n’effectue dans un premier temps qu’une vérification sur les 48 premiers bits d’une adresse, chargeant ainsi spéculativement une adresse potentiellement invalide, en laissant de sales traces aux endroits habituels, cache L1D en particulier. Néanmoins, le composant responsable se nomme TLB, et est vidé lors des changements de contexte entre processus : le seul scénario d’attaque concerne un programme faisant tourner plusieurs threads, dans lequel l’un d’entre eux, vérolé, pourrait accéder à des zones privées des autres threads.. un endroit peu utilisé en programmation pour stocker des informations critiques. Pas du plus effrayant dit comme cela, d’autant plus que les chercheurs n’ont pas trouvé de cas applicables en pratique, en particlieur pas dans le noyau Linux.

 

Exploitée artificiellement sur des processeurs Zen et Zen2, la faille a tout de même permis de soutirer 125 octets par secondes : pas beaucoup, certes, mais suffisant pour chouraver une clef cryptographique sans être repéré. Notez que les CPU Intel vulnérables au Microarchitectural Data Sampling sont également touchés, mais la faille est encore moins intéressante de leur côté du fait d’autres vulnérabilités plus faciles à exploiter.

 

Au niveau des correctifs, AMD conseille aux programmeurs de « vérifier leur code » à la recherche d’applications possibles de cette technique, et d’y pallier selon un guide déjà tout prêt depuis les précédentes vulnérabilités — ou une barrière mémoire. Une solution potentiellement coûteuse en performances, et l’on imagine difficilement une entreprise distribuer spécifiquement des binaires patchés AMD et non Intel... Cependant, vu la difficulté d’exploitation, il est fort probable que rien ne change, tout du moins pour le moment : ouf ! (Source : Tom’s Hardware)

 

Par ici pour l’article de recherche complet !
Un poil avant ?

Et chez ViewSonic, 2 nouveaux VX 4K UHD avec HDMI 2.1 et un overclocking de folie

Un peu plus tard ...

Le nouveau Myst dans un test RT, DLSS et FSR

Les 23 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Kannagi en Provence-Alpes-Côte d'Azur, le Dimanche 05 Septembre 2021 à 14h20  
Cela sera avec grand plaisir de discuter de ça sur Discord , la micro architecture est un sujet qui me passionne.
Merci , le projet n'est pas mon travail actuellement , il le sera dans un futur proche je l'espère, je compte le modifié un peu ce que j'ai fait pour qu'il soit compatible pour de l'embarqué haute performance donc sûrement réduction des unités de calcul (et donc là aussi modifié un peu les I/O , vu que ceux d'un nano/mini ordinateur sont assez conséquent et surtout coûteux).

Effectivement je pensais aux spéculatives load , une taille de registre plus grand , mais aussi une gestion d'un SPM (ou la tu peux espérer de grande performance, sur certain algo , tu peux meme atteindre les chiffre théorique même en bouffant 1 Go/s si la RAM suit ).

Oui c'est un peu aussi le soucis du VLIW , on gagne rien sur du code purement séquentiel , mais je travail justement à essayé d'extraire le maximum de parallélisme (en émulant à la compilation le buffer d'instruction d'un proc OoO , mais j'en suis pas encore là ).

Certes j'ai un peu confondu les deux , alors si tu fait 50 fetch/decode en même temps par exemple soyons fou , y'a sûrement des choses à gratter, mais en général , tu gagne beaucoup au début, après comme tout , tu vas un moment gagner que des micro %.
Sur une boucle , si je prend du in order comme exemple sur des codes que j'ai pu travaillé, tu unroll deux ou quatre fois et c'est suffisant pour avoir le maximun de parallélisation et de résoudre les conflit de pipeline , bon du coup sur du OoO ton windows doit juste être assez gros pour unroll deux ou quatre fois.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Dimanche 05 Septembre 2021 à 13h05  
par Kannagi en Provence-Alpes-Côte d'Azur le Dimanche 05 Septembre 2021 à 06h28
Alors je ne pense pas avoir le prix Turing pour cela , mais si tu es curieux : un petit lien tout mignon
Joli projet/travail, c'est ton travail ? À l'occasion je te contacterais peut-être sur discord
 
Sinon il y a plusieurs solution pour régler les latences dynamique sur un processeur VLIW in order.
Oui, comme les spéculatives load, et augmenter la taille du banc de registre. Mais les solutions sont assez limité par rapport à la taille du problème.
Le seul intérêt du VLIW ici c'est qu'il est plus petit et dissipe moins d'énergie. Mais cela ne donne pas de gain pour un code séquentiel.
 
Et sinon ,non je ne suis pas d'accord sur ça : "..."
Tu peux avoir 50 étapes de fetch/decode , 1 Read register , 1 execute ,1 write back , et la latence serait quand même de 2-3 cycles , pareil que si tu avais 1 étape de Fetch/decode

La width c'est la largeur du pipeline pas la longueur. Je parle bien d'augmenter le débit de fetch/decode pour alimenter un instruction window plus grand. Si tu as un ILP localement constant, alors avec plus d'instruction dans l'instruction window tu peux extraire plus de parallélisme globalement. Par exemple dans le cas d'un boucle avec des itérations en partie indépendante, si tu peux mettre plus de tour de boucle dans ton instruction window alors tu peux extraire plus de parallélisme.
Cependant je suis d'accord pour dire que le gain n'est pas proportionnel à la taille de l'instruction window.
par Kannagi en Provence-Alpes-Côte d'Azur, le Dimanche 05 Septembre 2021 à 06h28  
Je vais être court vu que les commentaire et l'ergonomie du site me dérange un peu ah ah

Oui c'est très bien que tu as pu détailler le fonctionnement du Cortex A-53 et je suis globalement d'accord.

Alors comme dit , je préfère éviter le débat Superscalaire OoO vs VLIW in order , comme dit cela n'engage que moi et mon expérience personnel , mais tu as plusieurs personne (même des personnes bossant sur Intel ) qui le pense aussi.

Alors je ne pense pas avoir le prix Turing pour cela , mais si tu es curieux :
un petit lien tout mignon

Sinon il y a plusieurs solution pour régler les latences dynamique sur un processeur VLIW in order.

Et sinon ,non je ne suis pas d'accord sur ça :
"De plus il n'y a pas vraiment de "limite logique" à l'augmentation de l'IPC pour la parallélisation des instructions. Car même avec un programme avec un ILP fixe, en augmentant l'instruction window et l'instruction fetch&decode width tu peux toujours gratter un peu plus d'IPC."
le fetch/decode ne réduit pas les latences , c'est la partie back end qui l'est.
Tu peux avoir 50 étapes de fetch/decode , 1 Read register , 1 execute ,1 write back , et la latence serait quand même de 2-3 cycles , pareil que si tu avais 1 étape de Fetch/decode

Par contre pour les branchement , ça réduit évidemment les latences, mais seulement cela réduit seulement le coût du miss prédiction dans le pire des cas, qui est de toute façon bien long quand il arrive,mais tu as déjà sur du OoO toute les instructions sur ton window quand il survient en général.

par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Samedi 04 Septembre 2021 à 23h15  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Samedi 04 Septembre 2021 à 22h00
on a "juste" besoin d'une structure de donnée qui track pour chaque instructions exécutés spéculativement (mais in order) leurs ressources et résultats qui encodent l'état architecturale correspondant à l'exécution de cette instruction. Si la spéculation est correcte alors ces états architecturaux sont commits in-order, sinon ces états sont écrasés. On peut utiliser pour cela une structure similaire au ROB et du checkpointing, comme dans les µarch OoO.
D'ailleurs pour être plus précis: pour le in-order on peut effectivement le faire avec une structure similaire a un ROB en trackant chaque instruction déjà exécuté spéculativement. Mais ça c'est une version non-optimale.
Le plus optimal c'est de tracker/enregistrer l'état avant l'exécution spéculative de chaque jump (ou équivalent), c'est ce que l'on appel un checkpoint. Et si on a un misspredict on retourne sur le checkpoint que l'on avait fait avant le jump. C'est exactement ce qui est fait dans les machines superscalaires OoO. La seule différence c'est que ici c'est plus simple: c'est plutôt des checkpoints de l'état architectural (spéculé ) qui peut être commit directement quand la prédiction est validé, alors que dans une machine superscalaire OoO c'est un état µarchitectural qui est checkpointé et le commit ne sert que à libérer les ressources de checkpointing.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Samedi 04 Septembre 2021 à 22h37  
par Kannagi en Provence-Alpes-Côte d'Azur le Samedi 04 Septembre 2021 à 14h16
C'est pour cela que pour moi l'IPC n'est clairement pas la partie la plus importante à optimiser , pour moi la part le plus gros bottleneck est les latences de la RAM et c'est de mon point de vue le plus gros point à optimiser.
Mais il y a beaucoup de travail aussi sur les µarch de système mémoire. Et cela ne va pas contre le travail sur la µarch du processeur et l'augmentation de l'IPC.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Samedi 04 Septembre 2021 à 22h32  
par Kannagi en Provence-Alpes-Côte d'Azur le Samedi 04 Septembre 2021 à 08h18
La meilleur preuve est probablement le ARM M1 , sur le papier il peut avoir un IPC supérieur qu'un Zen3 et pourtant il n'a pas un IPC supérieur , parce qu'il y'a une limite logique dans la parallélisation des instructions.
Tu as des sources pour affirmer que l'IPC réel du ARM M1 est égale au Zen3 ? Déjà c'est compliqué de comparer des IPC entre différentes arch. Mais en plus il me semble avoir vu des benchs qui semblent montrer le contraire.
De plus il n'y a pas vraiment de "limite logique" à l'augmentation de l'IPC pour la parallélisation des instructions. Car même avec un programme avec un ILP fixe, en augmentant l'instruction window et l'instruction fetch&decode width tu peux toujours gratter un peu plus d'IPC. (Jusqu'à ce que le programme en entier soit dans ton instruction window).

 
L'autre voie qui n'est plus trop populaire,était de faire des processeurs qu'on peut appeler VLIW/EPIC, donc de laisser tout cela la parallélisation des instructions, les conflits de pipeline, les soucis de branchements, l'optimisation du cache, doit se faire de façon statique au niveau de la compilation. Le seul défaut, c'est d'avoir un bon compilo ce qui n'a jamais été le cas, mais justement comparé aux années début 2000 où la modification d'un compilateur était très complexe, ça le devient bien moindre avec du clang/LLVM actuellement.
Il a des raisons pour lesquelles cette option n'est pas populaire pour des programmes avec beaucoup de control flow. Et la difficulté pour "modifier le compilo" est très loin d'être le seul problème pour faire du static scheduling. On a des composants avec des latences dynamiques dans une machine haute perf
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Samedi 04 Septembre 2021 à 22h00  
par Kannagi en Provence-Alpes-Côte d'Azur le Samedi 04 Septembre 2021 à 03h28
Il n'y a pas à ma connaissance d'exécution spéculative sur du Cortex A53
Oui il me semble que le A53 ne fait de la spéculation que pour le front-end (pour fetch/decode les instructions). Il n'exécute pas de chemin spéculativement.
Par contre il n'y a pas vraiment besoin de buffer qui contiennent des instructions "en attente" (donc dans le scheduler) pour faire de l'exécution spéculative dans du in-order, on a "juste" besoin d'une structure de donnée qui track pour chaque instructions exécutés spéculativement (mais in order) leurs ressources et résultats qui encodent l'état architecturale correspondant à l'exécution de cette instruction. Si la spéculation est correcte alors ces états architecturaux sont commits in-order, sinon ces états sont écrasés. On peut utiliser pour cela une structure similaire au ROB et du checkpointing, comme dans les µarch OoO.
 
Pour ma part je pense toujours qu'il faut quitter ce schéma de processeur Superscalaire OoO
C'est la meilleure technique connue pour exécuter du code avec beaucoup de control flow. Si tu trouves mieux alors propose, tu peux chopper un prix Turing pour ça!
Mais à défaut d'avoir mieux pourquoi arrêter de l'utiliser? Le problème semble plutôt être du côté des hypothèses posés concernant l'isolation des threads lorsque les ressources sont partagés.
Si nous n'avions pas mis cette isolation dans nos hypothèses alors on aurait mis un effort pour que les devs/langages/compilers garantissent eux même cette isolation.
PS: D'ailleurs les lib de crypto prennent cela en compte de nos jours, elles sont écrite pour éviter les timing side channel et les cache-based side-channel
par Kannagi en Provence-Alpes-Côte d'Azur, le Samedi 04 Septembre 2021 à 21h23  
Alors oui bien sur qu'il y'a une augmentation entre Zen 2 et Zen 3 , mais il ne dise pas exactement ce qui permet cette augmentation.
Est ce une meilleur gestion du cache L1 ? Est ce une meilleurs gestion pour éviter les pipelines stall , une meilleur prédiction de branchement ? Est ce effectivement une meilleurs parallélisations des instructions ,je n'en sais rien et c'est sûrement un peu tout ça à la fois.
(Juste pour dire que augmenter le nombre d'unité n'est pas forcément suffisante ).

Après je ne bosse pas chez AMD , mais je serais curieux de savoir où sont les plus gros bottleneck chez eux , en totu cas mon avis est seulement ce quej e ferais pour améliorer les perfs chaqu'un fera différemment bien entendu.
L'IPC mesuré est plutôt un IPC global donc difficile de savoir ce que cela veut dire , voilà , c'était juste mon avis sur la question
par _m_, le Samedi 04 Septembre 2021 à 20h45  
Soit, mais Zen 3 n'avait pas augmenté la quantité de cache, ils l'avaient juste unifié. Pourtant CDH avait bien mesuré les gains en applicatif de 10 à 17% en moyenne (suivant les modèles de proc), et de 18 à 22% globalement dans les jeux. La plupart des changements architecturaux avaient justement consisté à améliorer le parallélisme du cœur Zen, soit ajoutant directement des unités d'exécution, soit en améliorant tout ce qu'il y a autour pour les alimenter. Le tout pour un IPC qui était officiellement en hausse de 19% (pas trop mal respecté, d'après les tests du comptoir).

Intel aussi annonce un IPC en hausse de 19% sur son Golden Cove. Il n'est plus très loin. On verra bien quand ils le présenteront quels choix architecturaux ils ont opéré pour arriver à ça, et comment ça se reflètera en pratique dans les tests (une fuite sur cinebench a montré que ça pourrait même avoisiner les +30% en mono, on verra bien).

Mais d'accord pour le SMT. AMD avait déjà parlé d'un SMT4 par le passé, mais ne l'a jamais mis en œuvre. Actuellement ça apporte seulement dans les 20% de perf. Donc c'est un peu comme si on avait deux threads qui exploitait 60% du coeurs, alors qu'en mono, un seul thread aurait probablement pu en exploiter 80% ou 90%, si il avait été seul? L'augmentation du SMT, je le vois uniquement le jour où on aurait tellement d'unités d'exécutions en abondance qu'on arriverait même plus a les alimenter avec un seul flot (ou même deux). Mais on en est pas là aujourd'hui.
par Kannagi en Provence-Alpes-Côte d'Azur, le Samedi 04 Septembre 2021 à 14h16  
Pour la dif disons qu'on a une parallélisation des instructions (en interne) sur des processeurs scalaire ( la pipeline) , tu as aussi des processeurs qui indique à la compilation les instructions à exécuter en parallèle de façon explicite (VLIW/EPIC) ,ou de façon automatique qu'on nomme superscalaire , pour ça que je fais une différence entre tout ces termes.

Alors oui ,tu peux rajouter des ALU ,est ce que là va augmenter l'IPC de façon significatif , je ne pense pas comme expliqué avant.
Il augmente bien sur chaque année "la profondeur d'analyse du thread" , enfin plus concrètement il augmente un buffer interne actuellement sur zen 3 il est de 250 instructions et et de 300 instructions et des poussières chez Apple M1.

Admettons que tu arrive à augmenter l'IPC de façon considérable plus tu le fait , plus tu as besoin de lire en RAM , et plus tu aura de cache miss , il y'aura forcément une limite sur les deux (oui je sais il y'a énormément de prefetch automatique qui permet de gérer cela , mais là aussi le prefetch est bien plus long que l'exécution).

C'est pour cela que pour moi l'IPC n'est clairement pas la partie la plus importante à optimiser , pour moi la part le plus gros bottleneck est les latences de la RAM et c'est de mon point de vue le plus gros point à optimiser.

Augmenter le SMT est une solution , mais elle est plus complexe vu qu'est déjà compliqué avec un SMT que ce thread supplémentaire ne ralentit pas trop le premier , alors avec plus '
par _m_, le Samedi 04 Septembre 2021 à 12h28  
Tu as l'air de distinguer parallélisation des instructions et superscalaire. Qu'est ce que tu entends par là?
Pour la parallélisation, c'est ce qu'ils nous pondent à chaque gen. Golden Cove tout comme Zen 4 vont encore nous rajouter une ou deux ALU ou ports de chargement supplémentaire.
Bien-sûr qu'on sait faire ça depuis des lustres, mais virtuellement ça n'a pas de limite, suffit d'augmenter la profondeur d'analyse du thread en cours d'exécution, pour y dénicher de nouveaux blocs indépendants (ou au pire, augmenter le SMT). C'est une voie d'amélioration encore assez vaste à explorer, ya de quoi faire bucher leurs ingénieurs pendant encore de longues années là-dessus.

Pour le cache, bien-sûr que ça bénéficiera à tous le monde. Mais les Ryzen en ont déjà beaucoup, tout le monde ne profitera sans doute pas de ce surplus de la même manière. Le V-Cache ne vaudra pas de vrais changements [µ]architecturaux. Ils ont claironné du +15% dans les jeux, lors du dernier Computex, mais n'ont pas parlé du reste. Si ils sont resté silencieux sur les autres profils d'utilisations, c'est sans doute qu'ils n'avaient rien d'impressionnant à donner.
par Kannagi en Provence-Alpes-Côte d'Azur, le Samedi 04 Septembre 2021 à 08h30  
Partie 2:

Tu parle du cache , le cache n'est pas bon uniquement pour les jeux , ils est bon pour tout , il évite tout simplement des latences sur la mémoire astronomiques.
En terme d'optimisations des caches là aussi on est au max , tout les caches du Zen 3 sont du 8/16 way (donc le meilleur et les articles scientifique indique qu'augmenter le nombre de voie supérieur à 16 n'augmenter pas significativement les perfs ).
Bon le seul moyen c'est d'augmenter la taille du cache souvent le cache L3 , plus il est gros , plus il est lent (et plus il ralentit les cache L2 et L1).
Bien sur c'est toujours mieux de lire du cache L3 que de lire la RAM , mais cela explique aussi pourquoi les procs Intel s'en sorte mieux quelque fois , comme ils n'ont pas de gros cache , dans certain cas , leur cache miss est bien plus rapide ceux d'AMD. (et je le confirme vu que je l'ai mesuré ).

Pour le superscalaire OoO , ce que je dis n'engage que moi , c'est un vrai débat chez les électroniciens (certain sont pour , d'autre contre).
Le superscalaire OoO est complexe à faire , coûteux à faire (si tu veux un mieux que AMD prépare les milliards de $)et très consommateur en énergie (et il a des failles meltdown et spectre).

L'autre voie qui n'est plus trop populaire,était de faire des processeurs qu'on peut appeler VLIW/EPIC (le CELL et Itanium en tête) , donc de laisser tout cela la parallélisation des instructions , les conflits de pipeline , les soucis de branchements , l'optimisation du cache , doit se faire de façon statique au niveau de la compilation.
Le seul défaut, c'est d'avoir un bon compilo ce qui n'a jamais été le cas , mais justement comparé aux années début 2000 où la modification d'un compilateur était très complexe, ça le devient bien moindre avec du clang//LLVM actuellement.