Al final resultó que, la ejecución de algunas instrucciones específicas de FMA3 en un procesador AMD Ryzen conduce a un bloqueo crítico del sistema operativo.
Instrucciones como FMA3 (Fused-Multiply-Add) son compatibles con Intel (en Haswell) y AMD. Estas son instrucciones como
d = round(a × b + c) , donde
d debe estar en el mismo registro que
a ,
b o
c . En comparación, las instrucciones FMA4 solo son compatibles con AMD (en Buldozer y procesadores posteriores). Allí
a ,
b ,
cyd pueden estar en diferentes registros.
Se descubrió un error en el procesador en
Flops versión2 , una utilidad simple y poco conocida para probar CPU. Cabe señalar que el desarrollador de esta utilidad Alexander "Mystical" Yee (Alexander "Mystical" Yee) lo posiciona como una utilidad de prueba específica que es sensible a la microarquitectura de procesadores. En otros puntos de referencia, el error nunca apareció.
Con la utilidad Flops versión2, se entregan binarios específicos para todas las principales arquitecturas x64 (Core2, Bulldozer, Sandy Bridge, Piledriver, Haswell, Skylake). Pero por el momento, ni entre los ensamblados binarios
para Windows ni
para Linux hay una versión para probar Zen. Por lo tanto, ahora para probar Ryzen utilizó binarios de otras arquitecturas, a saber, el Haswell más cercano. El error antes mencionado con las instrucciones de FMA3 fue
descubierto hace dos semanas por el autor del programa Flops, cuando realizó una prueba con el archivo binario de Haswell en una computadora con la siguiente configuración:
- Ryzen 7 1800X
- Asus Prime B350M-A (BIOS 0502)
- 4 x 8GB Corsair CMK32GX4M4A2400C14 @ 2133 MHz
- Actualización de aniversario de Windows 10
De repente, se descubrió que el sistema generalmente se congela durante la siguiente operación:
Single-Precision - 128-bit FMA3 - Fused Multiply Add:A veces, la prueba pasa esta operación con éxito, pero aún depende de alguna otra operación en el futuro.
El desarrollador explica que su prueba es de código abierto, y si no confía en los resultados, puede tomar y compilar el binario en Visual Studio usted mismo y verificar los resultados.
Alexander sabía qué atención llamaría al informar un error en un procesador anunciado. Por lo tanto, revisó repetidamente los resultados. El procesador colgó el sistema en todas las frecuencias de reloj. Y cuando trabajaba en modo de subproceso único, cada núcleo colgaba el sistema.
Había algunas probabilidades de que la causa de la falla aún no estuviera en el procesador, sino en otra cosa. Por ejemplo, en una placa base específica, en un BIOS específico, en un sistema operativo específico ... ¿Qué más podría ser?
El desarrollador compartió los resultados con sus colegas para que verifiquen otras versiones de Zen en sus computadoras. Se confirmaron fallas para otros procesadores, en diferentes placas base, bajo diferentes versiones de Windows y bajo Linux.
En los primeros días después de la llamada de Alex, cinco propietarios de procesadores Ryzen lanzaron pruebas. Aquí están los resultados:
Fallas confirmadas:- 1800X + Asus Prime B350M-A (BIOS 0502)
- 1700 + Asus Prime B350M-A (BIOS ???)
- 1700 + Héroe Asus Crosshair VI
- 1700 + Asus Crosshair VI Hero (BIOS 5803) (dos bancos de memoria G.Skill + Kingston)
- 1800X + Asus Crosshair VI Hero (Windows 7): una vez que pasó la prueba, falló repetidamente.
Operación confirmada sin problemas:El desarrollador de referencia verificó todas las variantes de FMA (128 bits, 256 bits, precisión simple, precisión doble de números). En todos los casos, la computadora se congela fuertemente.
Fue acosado por un solo detalle: aunque la prueba se escribió correctamente, por alguna razón no encajaba en otros puntos de referencia, como prime95 y y-cruncher, aunque también usan FMA en las pruebas.
Por lo tanto, quedó cierta incertidumbre.
Al final, el 16 de marzo, se recibió un
mensaje oficial de un representante de AMD de que el error se corregirá en el nuevo código
AGESA (AMD Generic Encapsulated Software Architecture), un protocolo que se utiliza, entre otras cosas, para inicializar los núcleos del procesador AMD. En otras palabras, los especialistas de la compañía verificaron y confirmaron el error. Más tarde, los representantes de AMD
confirmaron oficialmente el error en los comentarios para los medios .
Afortunadamente, dicho error se puede solucionar sin reemplazar el hardware, sino simplemente actualizando el microcódigo. El error es insignificante, por lo que no causará revisiones del procesador ni ningún otro problema para la empresa. De hecho, en el mundo real del trabajo, casi nadie puede encontrar este error, no afecta ni a la computadora ni al rendimiento del procesador.
La mala noticia es que los atacantes pueden usarlo para ataques DoS. Es decir, principalmente este error es un problema de seguridad de la información. Después de todo, un programa de usuario ordinario que se ejecute en modo de usuario, y no en el nivel del kernel del sistema operativo, no debería bloquear el sistema de manera estricta. Pero esto está sucediendo.
El hecho de que la prueba se haya ejecutado en un binario para otra arquitectura no es tan importante. Cualquier procesador debe reproducir con éxito las pruebas de cualquier binario si es compatible con el conjunto apropiado de instrucciones, escribe el autor del benchmark. Pero incluso si ejecuta la prueba con instrucciones incompatibles, el programa no debe bloquear el sistema con fuerza.
El peligro de una vulnerabilidad de seguridad se ve agravado por el hecho de que el código malicioso incluso se puede ejecutar desde una máquina virtual, aún colgará todo el sistema. Una computadora con el nuevo procesador Ryzen puede colgar cualquier malware. Quizás incluso a través de un navegador.
Como ya se mencionó, AMD está trabajando en la actualización del protocolo AGESA. Después de eso, se lanzarán parches para todas las versiones de BIOS en todas las placas base.