Zen 3 : AMD détaille une faille du Predictive Store Forwarding (PSF)
Le 06 avril 2021 à 08h15
1 min
Sciences et espace
Sciences
Comme le rapporte Wccftech, le fabricant a publié un document détaillant cette vulnérabilité de type « side channel », qui n’est donc pas sans rappeler Meltdown/Spectre et leurs nombreux variants.
Dans son document, AMD précise qu’il « ne connaît actuellement aucun code qui serait considéré comme vulnérable en raison du comportement de la PSF », mais il détaille néanmoins les risques et explique comment désactiver cette fonctionnalité.
Enfin, « AMD estime que pour la plupart des applications, le risque de sécurité lié à la PSF est probablement faible », en conséquence de quoi le constructeur recommande de laisser la fonction Predictive Store Forwarding activée par défaut.
Le 06 avril 2021 à 08h15
Commentaires (13)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 06/04/2021 à 11h42
Du coup, il y a un bench sur phoronix, avec et sans PSF. On perd 0,5% de perfs sans…
A quoi il sert ce PSF? Ca fait beaucoup de transistor inutiles :) ? Ou c’est juste les compilos qui ne sont pas prêts?
Le 06/04/2021 à 19h00
Toutes les astuces trouvées par les fabricants de processeurs x86 pour tenter de faire fonctionner les application massivement mono cœur sont en train de tomber les unes après les autres manifestement. A peu près tout ce qui est prédictif entre autre si j’ai bien suivi.
En dehors des tares d’origine de cette architecture
dégeulassetrès discutable (même à l’époque de sa création), il y a les problèmes posés par des millions de lignes de code impératif impossible à paralléliser même quand le langage fait croire que c’est possible (la honte sur python qui sérialise les codes parallèles).L’avenir, selon moi, est aux processeurs massivement multi-cœurs que l’on pourra éviter de surcadencer et aux langages à paradigme fonctionnel qui permettent aux compilateurs de paralléliser quand cela est possible et pas seulement là où s’est prévu explicitement.
Dans les processeurs actuels, les transistors qui font vraiment le travail sont ceux des cœurs et ceux qui permettent aux données d’être échangées avec l’extérieur: ils sont surexploités et entourés d’une multitude d’autres transistors servants à des fonctions de cache, de prédictions et autres bricolages.
Si on transcrivait la situation actuelle dans les processeurs, on pourrait comparer les transistors aux employés d’une entreprise. On aurait donc, pour une entre prise de 100 employés:
Le 07/04/2021 à 07h23
Cette comparaison n’a pas de sens.
Dans tous les domaines, il y a des pièces plus utilisées que d’autres. Ça sera pareil dans un moteur de voiture, et n’importe quel ASIC spécialisé.
Le 06/04/2021 à 22h07
Ce n’est pas limité aux x86, spectre a touché ARM aussi il me semble. Par ailleurs il semble bien que l’Apple M1 se paye une bonne tranche de prédiction/réordonnancement, il ressemble plus à un Crusoé en tard qu’à un ARM. Wild guess: une bonne part est destinée à mapper ce qui sort de rosetta sur un max de coeurs.
Le monocoeur n’est pas mort, car il est compliqué d’alimenter les coeurs en données au delà de 8. Après,on a des coeurs périphériques mal exploités et des coeurs centraux isolés. La plupart des algos sont difficilement parallélisables. Une archi comme les Arm avec des coeurs type graphique intégrés qui ont accès au cache est plus intéressant qu’un CPU à tout faire.
Et je n’irai pas cracher sur le x86, vu ce qu’AMD en sort dernièrement, c’est impressionnant. Quand aux ARM, ils ajoutent instructions et unités tout comme le x86 l’a fait (même si la base est plus saine au vu des opportunités technologiques actuelles)
Pour rappel, en x86 on pouvait faire du calcul décimal sur des nombres décimaux codés binaires et des comparaisons de chaînes une poignée d’instruction. A l’époque, c’était de bons arguments. Maintenant,c’est juste totalement inutile.
Le 07/04/2021 à 07h27
Tu ne dois pas faire beaucoup de bas-niveau.
La parallélisation ça n’est pas gratuit : mémoire partagée, invalidation de caches, transferts de mémoire d’un cœur à l’autre…
Bref, NON on ne fera pas de parallélisation au niveau de la ligne de code, ça n’a aucun sens.
Le 07/04/2021 à 21h23
Coté archi du coeur, avec l’amd64 , on revient aux nombrux registres généreaux comme dans le 68000 et tous les processeurs bien conçus y compris côté microcontrôleurs comme les AVR et bien sûr, les ARM et les R3000. On revient de loin avec l’archi désastreuse du 8086 d’origine.
Côté parallélisation, continuer à utiliser une mémoire unifiée ne permet pas de faire croitre le nombre de coeurs. Perso, j’imagine plus un truc façon transputer mais avec des liaisons sur trois axes soit 6 liaisons au lieu de 4.
Mais il faut pouvoir faire de la prog parallèle, comme je l’ai dit. Et pas mal de choses sont paralélisables en fait. Sauf que, quand une boucle itérative est écrite en C avec un index , le compilateur ne peut pas rattraper le coup.
Le simple fait d’employer des itérateurs dans des languages ayant des syntaxes fonctionnelles permet d’exploser la boucle dès lors que les opérations sont indépendantes comme par exemple les calculs de matrices, les traitements d’images…
Le 07/04/2021 à 21h43
Côté calcul décimal, les micro intelhitoriques (8086, 8051, 8048), n’avaient qu’une instruction d’ajustement décimal après adition ou soustractikn de deux nombres codés en bcd. Sur le 68000 il y avait l’équivalent et enplus l’instruction abcd permettant de réaliser des opérations décimales sur des entiers de taille quelconque.
De mémoire une adition 256 bits tient en trois lignes d’assembleur:
boucle: abcd (a0)+, (a1)+
Et le calcul décimal reste utile et très utlisé pour ceux qui veulent compter juste. C’est le cas avec le type decimal en sql qui est indispensable pour tout ce qui touche à l’argent, de la gestion de coûts aux payes, aux taux de change etc
Perso, je haie les flotants binaires qui font que excel n’est pas foutu de restituer proprement un résultat de calcul propre avec seulement deux chiffres après la virgule. Du coup, je fait des calculs de temps avec des entiers.
Le 08/04/2021 à 13h19
Attention, les ISA ne sont qu’une façade pour les micro instructions derrières. Entre les renommages de registre, le out of order et le prédictif, c’est un peu une soupe derrière ce qu’on voit en assembleur. Et ça date du PPC, en RISC.
Par ailleurs, moi je vois plutôt une ISA différente, avec au lieu de registre des lignes de cache de plusieurs dizaines d’octets. Là on peut se lâcher sur le calcul matriciel.
Si mais pas forcément tout seul. Sur certains compilos fortran, on indiquait simplement quelles variables étaient variables dans la boucle et lesquelles étaient potentiellement différentes, le compilo parallélisait les for tout seul ensuite (SGI, 64 CPU, an 2000 :) )
+1, il est essentiel de connaître la différence en decimal et réel, leur limitations (et que en réels, 10000000+10000000* 0,00000001 n’est pas égal à 100000000+10000000 de fois l’addition de 0,00000001)
Le 08/04/2021 à 16h27
-le décodage , il est bien plus rapide sur le RISC ce qui fait que la pipeline sur ARM est bien plus courte , et donc moins besoin d’avoir un out of order “efficace”
-on peut décodé plus d’instruction par cycle (c’est le cas du Apple M1 qui décode 8 instructions , contre 4 contre Intel et AMD) et ça ni Intel ni AMD n’arrivera à monté plus à cause du x86 justement :)
-moins de registre signifie que le x86 tape plus souvent sur le cache que sur les registres et comme l’accès au cache est bien plus long…
Le 09/04/2021 à 07h02
C’est clair que le x86 a un décodage ultra compliqué. Ca paraît complètement idiot de nos jours, et les nouvelles instructions ne sont pas franchement plus simples.
Mais le out of order est apparu dans le grand public aussi avec les RISC, et il était nécessaire pour les perfs (PowerPC à l’époque). Sauf que qu’il fallait pour optimiser le prévoir dans les compilos, car ce n’est pas le CPU qui s’en chargeait. Et les compilos n’étaient pas prêt.
Quand à la “pureté” du RISC: c’est bien parce que l’idée ne résout pas tout et de loin que les ARM/PowerPC n’arrivent sur le devant de la scène que maintenant: depuis le début des années 90, la révolution RISC n’a pas réussi réellement à faire des machines aussi performantes que les CISC, sauf Apple M1… Qui embarque plus de transistors que les x86.
D’après ce que j’ai lu, il a une ISA RISC, mais il ressemble plus à une espèce de VLIW en interne (mais on ne peut que spéculer).
Quelques articles d’il y a quelques années comparaient des RISC à décodage multiple à du VLIW car en réorganisant “de force” les instructions, on pouvait exécuter des “cascades d’instructions” avec moins de cycle qu’il n’y a d’instructions, bloc par bloc.
En gros ce que faisait transmeta en 2000 (les CPU compatibles x86 à 1W contre 20 pour la consurrence - mais à 2⁄3 des perfs)
C’est un autre façon de penser, plus proche du Cell de la PS3 en fait. Grosses tâches à alimenter. Un peut comme un GPU, mais au lieu de registres, des déplacement sur une ligne plus ou moins grande.
Ca peut coller avec du bytecode Java, puisqu’il déclare d’avance les espaces nécessaires pour une fonction.
Mais mon passé fortran parle :)
Le 09/04/2021 à 07h21
Non , ce n’est pas la raison pour laquelle les procs “RISC” était en retrait , juste que faire un out of order efficace est très complexe, et seul Intel/AMD y arriverai.
Par contre les procs RISC faisait mieux à leur début (les PowerPC était meilleur que la gamme des Pentium ).
Bah , non ça ne fait pas du VLIW en interne :)
Après la comparaison est tout simplement que le VLIW peut être vu comme une version manuelle du Superscalaire , mais en interne , y’a de grosse différence entre eux.
Le CELL n’était pas novateur , vu que le CELL était une copie parfaite de la … PS2 ou plus précisément de l’Emotion engine.
Sinon tu as mal compris le CELL (qui est pour ma part on va dire ma vision du CPU moderne), il n’avait pas de gros registre , il avait des registres de 128 bits au grand max.
C’est un proc relativement basique (donc qui utilise des registres et des instructions très proche d’un RISC ), la seule différence était qu’il était VLIW et qu’il n’avait pas de mémoire cache (mais un scratchpad memory) , et que donc c’était au programmeur de gérer cette mémoire , et la méthode pour bien l’utiliser était de précharger à l’avance les données (et pas forcément les fonctions , mais aussi et surtout les datas ).
Le 09/04/2021 à 07h34
Ca n’a pas tenu très longtemps… Et qu’on ne se méprenne pas: je suis pro-RISC! En fait, j’ai rêvé dès le début d’avoir un acorn Archimedes (je faisais de l’assembleur x86, et c’était déprimant comme la moindre instruction coûtait plus d’un - voir plus de 20 cycles).
Mais les ARM ont vite déçu, les PPC aussi…
Disons que le câblage va favoriser une certaine suite d’instructions, l’étage de réorganisation est censé produire ces suites le plus possible. Si on multiplie ces suites précablées, on se rapproche d’un VLIW.
Je parlais surtout sur la façon de programmer - isoler des boucles dont on sait qu’elles ont une certaine durée. Et c’est une réflexion qui date de fin des années 90 en fait, en regardant le bytecode java et le fait qu’on s’énerve à le coller sur des machines à registres. Google a réglé le problème je crois en faisant un bytecode à registres.
Le 09/04/2021 à 08h04
Oui , mais bon l’OoO est très complexe aussi
Oui , on peut en interne le gérer comme cela , mais cela ne veut pas vraiment dire qu’ils ont l’avantage du VLIW , vu que c’est qu’une petite partie du OoO le dispatch.
Ben justement ,le CELL est un proc à registres donc pas sur que cela soit ta “façon de programmer”.
j’ai programmer sur ce genre de proc , et la façon de programmer et comme je l’ai dit , faut juste le voir comem un ARM mais que tu indique par bloc de deux instructions et que t’as pas de cache , le but du CELL est d’éviter au maximun les caches miss ;)
(Et il est VLIW in order pour réduire au maximun le nombre de transistor).