Il semble que le correctif publié par AMD pour son bogue Zen 1 « Division par zéro » n’était pas la solution ultime, tout ce que la société voulait qu’il soit. Alors que la société a été rapide dans la publication d’un correctif, on soupçonne maintenant qu’ils ont été un peu trop rapides : selon Michael Larabel de Phoronix, l’ingénieur AMD Linux Borislav Petkov a publié un nouveau correctif qui a résolu un problème avec la solution d’origine. (également publié par lui). C’est juste un autre point de données sur les difficultés de durcissement contre d’éventuels vecteurs d’attaque.
Le bogue d’origine concernait la façon dont Zen 1 traitait un calcul d’entier divisé par 0 dans certaines circonstances : selon les résultats, il était possible que le processeur d’AMD conserve des « données de quotient obsolètes » dans ses registres même après la fin complète de l’opération, ce qui pourrait donner aux attaquants une fenêtre pour récupérer des informations sensibles. La solution de contournement originale consistait à effectuer une dernière « division fictive 0/1 avant de revenir du gestionnaire d’exceptions #DE ». L’idée est simple : toutes les anciennes données encore stockées seraient effacées à la fin de la division 0/1 (dont le résultat est toujours, eh bien, zéro).
Le problème avec cette solution, comme l’a expliqué Petkov, était qu’au moment où la disposition de sécurité entrerait en vigueur, l’attaque d’exécution spéculative aurait déjà trop avancé : il y aurait déjà une certaine quantité d’anciennes données sur le diviseur d’AMD, que les attaquants pourraient obtenir. avant que la division factice n’entre en jeu. Comme Petkov l’a expliqué, sa nouvelle solution force maintenant cette même division dans un certain nombre de scénarios :
« Au départ, on pensait que faire une division anodine dans le gestionnaire #DE prendrait soin d’empêcher toute fuite d’anciennes données du diviseur, mais au moment où le défaut est signalé, la spéculation a déjà trop avancé et de telles données pourraient déjà ont été utilisés par des opérations plus jeunes.
Par conséquent, effectuez la division inoffensive à chaque sortie vers l’espace utilisateur afin que l’espace utilisateur ne voie aucune donnée potentiellement ancienne provenant de divisions entières dans l’espace noyau.
Faites la même chose avant VMRUN également, pour protéger les données de l’hôte contre les fuites vers l’invité également. »
Cela a déjà été un mois chargé pour les vulnérabilités dans le domaine du processeur, AMD et Intel ayant tous deux été touchés par des divulgations. De la vulnérabilité Downfall la plus extrême d’Intel (affectant Skylake à Tiger Lake/Rocket Lake) en passant par les vulnérabilités SQUIP et Inception d’AMD (et la vulnérabilité désormais corrigée « diviser par zéro », les chercheurs ont travaillé dur. Cela ne se compare toujours pas à l’histoire historique des jours Meltdown et Spectre (bien que ces nouveaux bogues soient également liés à des vulnérabilités d’exécution spéculative. L’exécution spéculative fait référence à la façon dont les processeurs modernes tentent d’anticiper les étapes de calcul avant même qu’elles ne deviennent nécessaires, afin que les données requises soient déjà disponible au cas où il serait appelé à l’exécution. Pourtant, bien que les correctifs de certaines de ces vulnérabilités aient entraîné des pénalités de performances (parfois graves), c’est au moins un bon signe que la division factice 0/1 d’AMD n’entraîne pas de surcharge supplémentaire.
Dans le même temps, il est encourageant de voir qu’au moins dans ce cas, le correctif de sécurité n’a pas été publié d’une manière « installez-le et oubliez-le » – avec le genre de travail de manège que les experts de l’équipe bleue avoir à transporter, il y avait d’autres façons que cela aurait pu se passer (on aurait pu croire que le patch déficient fonctionnait pleinement, laissant la porte ouverte à d’autres explorations de piratage sur la route (quel que soit l’impact que ceux-ci pourraient avoir).