Pocas veces veremos unas declaraciones tan duras de alguien tan importante como el creador de Linux hacia una empresa tan grande como AMD. Y es que el ingeniero de software y padre del SO más implementado en empresas y servidores de todo el mundo está harto, está cansado, y ha lanzado unas acusaciones muy duras contra algo tan clave como la seguridad por hardware de los procesadores AMD, en concreto, de los Ryzen. En opinión de Linus: hay que “deshabilitar el estúpido AMD fTPM HWRND”.
Desactivar potencialmente su uso, ni más ni menos, de una medida de seguridad que en escritorio trajo controversia, puesto que Windows 11 necesita de un sistema TPM 2.0 para instalarse, algo que dejó fuera a muchas CPU de Intel y AMD. Ahora, desde la perspectiva del software abierto y de la seguridad, Linus Torvalds atiza a los de Lisa Su.
AMD, los Ryzen, EPYC y el problema del stuttering que no termina
Tenemos que irnos a marzo del año pasado para entender desde dónde viene el problema. El artículo que hicimos era bastante esclarecedor y aunque en principio y según se detectó solo afectaba a los usuarios de Windows, finalmente los de Linux también reportaron problemas varios:
“AMD ha determinado que determinadas configuraciones del sistema AMD Ryzen pueden realizar de forma intermitente transacciones de memoria relacionadas con el fTPM en la memoria flash SPI (“SPIROM”) ubicada en la placa base, lo que puede provocar pausas temporales en la interactividad o capacidad de respuesta del sistema hasta que la transacción concluya”, indica la compañía en su web oficial.
Actualización: Los PCs afectados requerirán una actualización de la BIOS del sistema de la placa base (sBIOS) que contenga módulos mejorados para la interacción de fTPM con SPIROM. AMD espera que los archivos sBIOS flasheables del cliente estén disponibles a partir de principios de mayo de 2022. El tiempo exacto de disponibilidad de la BIOS para una placa base específica depende del calendario de pruebas e integración de su fabricante. Las actualizaciones flasheables para placas base se basarán en AMD AGESA 1207 (o más reciente).
Solución: Como solución inmediata, los clientes afectados que dependen de la funcionalidad fTPM para el soporte del módulo de plataforma de confianza pueden utilizar en su lugar un dispositivo TPM de hardware (“dTPM”) para la computación de confianza. Los módulos dTPM de plataforma utilizan una memoria no volátil (NVRAM) integrada que sustituye a la interacción TPM/SPIROM descrita en este artículo.
Hubo una solución, es cierto, dos meses después de aquel momento, pero se obligó en ese instante a volver a versiones anteriores del kernel de Linux para solventar todos los problemas, algo que no gustó. Pues bien, en Windows todo se estabilizó y pareció resuelto. En Linux… Ya se ha acabado la paciencia.
Un nuevo informe sobre la plataforma Rembrandt ha disparado una vez más las alarmas, puesto que todo estaba actualizado en el equipo. Desde el firmware de la placa y procesador, hasta el SO. De hecho, se lanzó un parche de urgencia para terminar con el problema, que era bastante importante dado que el stuttering era alto… Pero no sirvió para nada. ¿La solución? Deshabilitar por BIOS el fTPM de AMD y sus Ryzen, algo que ha hecho estallar a Linus Torvalds.
Linus lanza unas declaraciones contra el AMD fTPM ¡en el Lore del propio kernel de Linux!
La declaración que se puede leer es dura y dice lo siguiente:
“Simplemente deshabilitemos el estúpido fTPM HWRND. Tal vez lo usemos para “recopilar entropía de diferentes fuentes” en el momento del arranque, pero claramente *no* debe usarse en tiempo de ejecución. ¿Por qué alguien usaría esa porquería en cualquier máquina que la tenga? Supuestamente está arreglado (que aparentemente no resultó ser cierto después de todo) ¿también tendría la instrucción CPU RDRAND errores o no tiene el problema?
Si no confía en la implementación de CPU RDRAND (y eso también ha tenido errores, vea clear_rdrand_cpuid_bit y x86_init_rdrand), ¿por qué confiaría en la versión de fTPM que ha causado incluso *más* problemas?
Así que no veo ningún inconveniente en decir simplemente “eso de fTPM (de AMD) no funciona”. Incluso si termina trabajando en el futuro, hay alternativas que no son peores.
Linus”
El problema parece llegar desde el generador de números aleatorios del hardware dentro del AMD fTPM en todos los sistemas Ryzen, sea de servidor o escritorio. Afecta al kernel de Linux con el famoso stuttering, y al parecer, ninguna de las correcciones de AMD ha terminado por arreglar esto, así que esperemos que más de un año después los de Lisa Su tras este golpe de Linus puedan terminar por corregir lo que está siendo un quebradero de cabeza, una vez más, para la comunidad.
La entrada El creador de Linux atiza a AMD: «Hay que deshabilitar el estúpido fTPM de los Ryzen» aparece primero en El Chapuzas Informático.
