Il s'est avéré que l'exécution de certaines instructions FMA3 spécifiques sur un processeur AMD Ryzen entraîne un crash critique du système d'exploitation.
Des instructions telles que FMA3 (Fused-Multiply-Add) sont prises en charge par Intel (dans Haswell) et AMD. Ce sont des instructions comme
d = round(a × b + c) , où
d doit être dans le même registre que
a ,
b ou
c . En comparaison, les instructions FMA4 ne sont prises en charge que par AMD (dans Buldozer et les processeurs ultérieurs). Là,
a ,
b ,
c et
d peuvent être dans des registres différents.
Un bug dans le processeur a été découvert dans
Flops version2 , un utilitaire simple et peu connu pour tester les CPU. Il est à noter que le développeur de cet utilitaire Alexander "Mystical" Yee (Alexander "Mystical" Yee) le positionne comme un utilitaire de test spécifique sensible à la microarchitecture des processeurs. Dans d'autres benchmarks, le bug ne s'est jamais présenté.
Avec l'utilitaire Flops version2, des fichiers binaires spécifiques sont fournis pour toutes les principales architectures x64 (Core2, Bulldozer, Sandy Bridge, Piledriver, Haswell, Skylake). Mais pour le moment, ni parmi les assemblages binaires
pour Windows , ni
pour Linux il n'y a de version pour tester Zen. Par conséquent, maintenant pour tester Ryzen, les binaires utilisés d'autres architectures, à savoir le Haswell le plus proche. L'erreur susmentionnée avec les instructions FMA3 a été
découverte il y a deux semaines par l'auteur du programme Flops, lorsqu'il a exécuté un test avec le binaire de base pour Haswell sur un ordinateur avec la configuration suivante:
- Ryzen 7 1800X
- Asus Prime B350M-A (BIOS 0502)
- 4 x 8 Go Corsair CMK32GX4M4A2400C14 @ 2133 MHz
- Mise à jour anniversaire de Windows 10
Soudain, il a été découvert que le système gèle généralement pendant l'opération suivante:
Single-Precision - 128-bit FMA3 - Fused Multiply Add:Parfois, le test réussit cette opération, mais il se bloque toujours sur une autre opération à l'avenir.
Le développeur explique que son test est open source, et si vous ne faites pas confiance aux résultats, vous pouvez prendre et compiler le binaire dans Visual Studio vous-même et revérifier les résultats.
Alexander savait quelle attention il attirerait en signalant une erreur dans un processeur annoncé. Par conséquent, il a vérifié à plusieurs reprises les résultats. Le processeur a suspendu le système à toutes les fréquences d'horloge. Et lorsque vous travaillez en mode monothread, chaque cœur suspend le système.
Il y avait des probabilités que la cause de l'échec ne soit toujours pas dans le processeur, mais dans autre chose. Par exemple, dans une carte mère spécifique, dans un BIOS spécifique, dans un système d'exploitation spécifique ... Quoi d'autre pourrait être?
Le développeur a partagé les résultats avec ses collègues afin qu'ils vérifient les autres versions de Zen sur leurs ordinateurs. Des échecs ont été confirmés pour d'autres processeurs, sur différentes cartes mères, sous différentes versions de Windows et sous Linux.
Dans les premiers jours après l'appel d'Alex, des tests ont été lancés par cinq propriétaires de processeurs Ryzen. Voici les résultats:
Échecs confirmés:- 1800X + Asus Prime B350M-A (BIOS 0502)
- 1700 + Asus Prime B350M-A (BIOS ???)
- 1700 + Asus Crosshair VI Hero
- 1700 + Asus Crosshair VI Hero (BIOS 5803) (deux banques de mémoire G.Skill + Kingston)
- 1800X + Asus Crosshair VI Hero (Windows 7) - une fois passé le test, a échoué à plusieurs reprises.
Fonctionnement sans problème confirmé:Le développeur de référence a vérifié toutes les variantes FMA (128 bits, 256 bits, simple précision, double précision des nombres). Dans tous les cas, l'ordinateur se bloque fermement.
Il a été harcelé par un seul détail: bien que le test ait été écrit correctement, pour une raison quelconque, il ne correspondait pas à d'autres repères, tels que prime95 et y-cruncher, bien qu'ils utilisent également FMA dans les tests.
Il restait donc une certaine incertitude.
Finalement, le 16 mars, un représentant officiel d'AMD a reçu un
message officiel
indiquant que le bogue serait corrigé dans le nouveau code
AGESA (AMD Generic Encapsulated Software Architecture), un protocole utilisé, entre autres, pour initialiser les cœurs de processeur AMD. En d'autres termes, les spécialistes de l'entreprise ont vérifié et confirmé le bogue. Plus tard, les représentants d'AMD ont
officiellement confirmé le bogue dans les commentaires des médias .
Heureusement, un tel bogue peut être corrigé sans remplacer le matériel, mais simplement en mettant à jour le microcode. Le bogue est insignifiant, il ne causera donc pas de révisions du processeur ou d'autres problèmes pour l'entreprise. En fait, dans le monde réel du travail, presque personne ne peut jamais rencontrer ce bug, cela n'affecte ni l'ordinateur ni les performances du processeur.
La mauvaise nouvelle est que les attaquants peuvent l'utiliser pour des attaques DoS. Autrement dit, cette erreur est principalement un problème de sécurité de l'information. Après tout, un programme utilisateur ordinaire fonctionnant en mode utilisateur, et non au niveau du noyau du système d'exploitation, ne devrait pas bloquer le système correctement. Mais cela se produit.
Le fait que le test ait été exécuté sur un binaire pour une autre architecture n'est pas si important. Tout processeur doit réussir à reproduire les tests à partir de n'importe quel binaire s'il prend en charge l'ensemble d'instructions approprié, écrit l'auteur du benchmark. Mais même si vous exécutez le test à l'aide d'instructions incompatibles, le programme ne doit pas bloquer correctement le système.
Le danger d'une vulnérabilité de sécurité est aggravé par le fait que du code malveillant peut même être exécuté sous une machine virtuelle, il bloquera tout le système. Un ordinateur équipé du nouveau processeur Ryzen peut bloquer tout malware. Peut-être même via un navigateur.
Comme déjà mentionné, AMD travaille à la mise à jour du protocole AGESA. Après cela, des correctifs seront publiés pour toutes les versions du BIOS dans toutes les cartes mères.