AMD distribue les correctifs pour protéger les processeurs Zen 3 des attaques de type Spectre

Ha, une bonne idée qui laisse le choix mais, par défaut, il aurait été plus sage de la désactiver et laisser le choix à l’utilisateur de l’activer.
Certes, ce correctif est pour ce qui est vendu.
Pourvu que les fournisseurs d’OS la désactive par défaut et ne laissent aux prox que le choix de l’activer à leurs risques et périls.

Du coup ça sert à quoi d’intégrer une techno qui ne fait gagner que maximum 1% (!) de perf?

Vu le nom « Predictive Store Forwarding » (et une recherche rapide qui semble le confirmer) : cette fonctionalité sert à éviter les Load Hit Store (ou Store-to-Load dans le langage Intel) : quand un programme écrit une donnée mémoire puis lit juste à côté immédiatement après, la ligne de cache L1 est invalidée et doit être relue du L2. Ça coûte quelques dizaines de cycles CPU.
Pas aussi pire qu’un cache miss, mais sensible tout de même.

EDIT : le PSF Predictive Store Forwarding est en fait encore plus malin : s’il détecte qu’une écriture va rentrer en collision avec une future lecture, il va utiliser la future-valeur-stoquée avant qu’elle ne soit écrite.

Donner la possibilité aux utilisateurs de désactiver le « predicting store forwarding » c’est bien, mais selon moi c’est plus un « workaround » qu’une solution.

Bon cela dit, si les perfs ne sont effectivement réduites que de 1% (ce dont je doute un peu), il semblerait que ce workaround soit très acceptable pour la plupart des usages

Je partage pleinement ton avis sur ce point. Et si je pousse le raisonnement un peu plus loin, sachant que cette technologie de prédiction se trompe quelques fois, je me demande ce qu’elle fou dans un CPU… Ce qu’on attend d’un calculateur c’est zéro failles de sécurité et zéro erreurs de calcul aussi.

Les tests parlent de 0.5 à 1 % de pertes de performances. Concernant Intel et les patches qu’ils avaient fournis, on perdait 10 % sur les vieux CPU et seulement quelques pour-cents aussi sur les modèles de dernière génération.

Qui parle de faute de calcul ici? Ta réponse montre que tu réagis sans rien comprendre au problème. Ce n’est pas une méthode de calcul qui est en faute, c’est une optimisation.

Sur tous les CPUs x86, les accès mémoire se font par bande de 128 bytes (parfois 256 sur des rares CPU Intel). Le pb initial est lorsqu’un programme écrit une donnée, puis en lit une autre voisine dans la même bande de 128 octets : ça invalide cette ligne de cache daLoad-Hit-Storens le cache L1, forçant le CPU à la relire depuis le cache L2 (ça s’appelle un Load-Hit-Store -LHS- ou un Store-To-Load). Ici l’optimisation Predictive Store Forwarding semble permettre au second accès (lecture voisine) de se faire à partir du cache L1, sauvant quelques dizaines de cycles CPU. Et c’est cette optimisation qui est problématique.
EDIT : correction, l’idée de base est bien ce que je décrivais, mais PSF va plus loin : s’il détecte une collision entre une écriture et une future lecture, il va utiliser la valeur qui sera écrite avant même qu’elle ne sorte du CPU, sauvant complètement la lecture.

Cette optimisation ne se trompe pas/ne fait pas d’erreur de calcul; juste que comme dans le pb Spectre des CPU Intel, un malin peut créer du code qui fait dépendre cette optimisation d’un test sur une lecture mémoire non autorisée (si mémoire[x] & 2^bit, lire mémoire[x + 4] sinon lire mémoire[x + 300] : lecture dans la même cacheline dans le premier cas, hors du cache dans le second cas); le CPU va interdire cet accès; mais en mesurant combien de temps ça a pris pour déclencher une erreur d’accès, on peut savoir si l’accès s’est fait en L1 ou pas, donc si le test était vrai ou faux, ce qui permet de deviner un bit de la zone mémoire dont on n’avait pas accès.
Ce qui, en répétant pleins de fois l’opération, permet de deviner le contenu de mémoire à laquelle on n’a normalement pas accès.

Pour l’utilisateur lambda qui n’utilise pas les applications vulnérables, c’est une bonne chose que la désactivation soit optionnelle.
Pour le reste je ne vois là essentiellement qu’une opération de communication d’AMD pour maintenir la confiance dans leurs CPU, en dévoilant eux même une faille de sécurité et en donnant presque immédiatement une solution qui marche. Plutôt bien joué, je trouve.

Mais il y a tout plein d optimisations qui font gagner 1% par ici ,2% par là …
1 % de performances en plus ce n’est vraiment pas négligeable quand il s agit de super calculateur , la faille touche essentiellement des outils de virtualisation très utilisés dans le domaine domaine professionnel et dans ce domaine , les perfs/watt c est un critère de choix d un processeur.

Pour le coup, je trouve qu’ils ont réagit rapidement même s’il aurait été bien plus intéressant que le patch corrige la faille et ne se contente pas de laisser le choix de la désactivation de la technologie.

Je n’ai pas ce type de processeur, mais ne peut-on pas désactiver le PSF depuis le BIOS tout simplement ? Au lieu de patcher l’OS pour ce faire.