AMD reconnaissait il y a peu que ses processeurs
Ryzen de dernière génération étaient vulnérables aux failles de type Spectre. Aujourd’hui, et comme promis, le groupe déploie donc des correctifs permettant de réduire les risques de sécurité liés au PSF.
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?
3 « J'aime »
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 
1 « J'aime »
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.
2 « J'aime »
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.
Un sécurité doit être activé par défaut, c’est normal, c’est à l’utilisateur de le désactivé en connaissance des causes. Surtout avec la généralisation du télétravaille ou l’ordinateur perso devient de plus en plus un ordinateur pro.
La prédiction qui se trompe, ce n’est pas une erreur de calcul. Si la prédiction ne se trompait jamais, il n’y aurait pas besoin de prédiction justement…
Aujourd’hui un CPU performant c’est un CPU qui traite plusieurs instructions en parallèle (et je parle pas de plusieurs cœurs, mais bien d’un parallélisme interne au sein d’un coeur). Mais dans le flux d’instructions d’un programme, tu en as toujours certaines qui vont dépendre du résultat d’instructions précédentes, et en notamment quand il y a un branchement conditionnel (exécution d’une branche de code ou d’une autre en fonction de la valeur d’une variable).
Avant, quand il y avait un tel branchement, le CPU attendait que toutes les instructions dont dépendait la condition soient traitées, puis il basculait sur la branche. Mais ça faisait un petit moment pendant lequel le parallélisme n’était plus exploité, une partie du CPU se tournait les pouces au lieu de commencer à traiter de nouvelles instructions.
C’est là que la prédiction de branchement intervient : par différents moyens statistiques, quand il y a un branchement, le CPU choisit la branche qui a le plus de chances d’être la bonne et commence à traiter les instructions de cette branche avant même d’avoir fini d’évaluer la condition de branchement. Si la prédiction a été bonne (et aujourd’hui, il n’est pas rare de dépasser les 99% de succès), tant mieux, on a gagné en performances puisqu’on a déjà commencé à traiter la branche, si la prédiction a été mauvaise, c’est pas grave, le CPU interrompt la branche prédite et recommence au début de la bonne branche.
Oui et cette prédiction est bien utilisée par l’attaque Spectre sur les CPU Intel (en mesurant combien de temps le programme a tourné avant de faire une faute d’accès, on peut savoir si le test était positif ou pas même sans avoir accès à la mémoire visée). Mais ici le problème est tout autre.
Ici l’attaque sur AMD utilise une autre forme de prédiction, « Predictive Store Forwarding » : PSF estime si une zone mémoire qui va être lue ne va pas être modifiée par de instructions exécutée en parallèle (les CPUs x86 étant out of order), et décide s’il faut lire la mémoire/le cache, ou si la valeur qui va être écrite par une autre instruction peut directement être utilisée.
https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf
PREDICTIVE STORE FORWARDING
It is common for a CPU to execute a load instruction to an address that was recently written by a store. Many modern processors implement a technique known as Store-To-Load-Forwarding (STLF) to improve performance in such cases. With STLF, data from the store is forwarded directly to the load without having to wait for it to be written to memory. In a typical CPU, STLF occurs after the address of both the load and store are calculated and determined to match.PSF expands on this by speculating on the relationship between loads and stores without waiting for the address calculation to complete. With PSF, the CPU learns over time the relationship between loads and stores. If STLF typically occurs between a particular store and load, the CPU will remember this. When the CPU sees the
store/load pair again, it may predict that STLF will occur and speculatively forward the data from the store to the load. This is done before confirming that the store and load are in fact to the same address.
Yep, ce n’est en effet pas le même type de prédiction.
Mais fondamentalement, ça reste normal qu’une prédiction, quelque soit sa nautre, se trompe parfois. Sinon il n’y aurait pas besoin de prédiction 
Un cpu est un calculateur, et un calculateur qui se lance dans des approximations par le biais de prédictions, perso je ne trouve pas ça top tu tout. Chacun son point de vue…
Ca tombe bien, ce n’est pas le cas ici.