Linus Torvalds expresó recientemente su descontento con el generador de números aleatorios de hardware fTPM de AMD en la lista de correo y sugirió desactivarlo debido a problemas con el kernel en los sistemas Ryzen .
Se informa que el generador de números aleatorios de AMD fTPM ha causado recientemente algunos problemas de tartamudeo , que afectaron inicialmente a los usuarios de Windows y, posteriormente, a los usuarios de Linux. Si bien se implementó una solución para este problema y se revirtió a kernels anteriores, algunos problemas espinosos relacionados con fTPM RNG de AMD siguen sin resolverse, y algunos usuarios aún informan que tartamudean.
Un nuevo informe de errores la semana pasada afirmó que el uso de fTPM en algunas plataformas AMD podría causar tartamudeos. La versión de firmware de fTPM utilizada en este informe es 0x3005700020005, que es la primera vez que esto ocurre en la plataforma Rembrand ; los parches de kernel existentes no ayudaron.
Esto inevitablemente despertó la ira de Linus Torvalds, quien dijo en la lista de correo :
Desactivemos el estúpido fTPM hwrnd.
Si no confía en la implementación de CPU rdrand (que también tiene errores ; consulte clear_rdrand_cpuid_bit() y x86_init_rdrand()), ¿por qué confiar en la versión de fTPM que causa más problemas? Así que no veo ningún inconveniente en decir "eso de fTPM no funciona". Incluso si al final funciona, hay alternativas que no son peores.
Por lo tanto, no veo ningún daño en decir "eso de fTPM no funciona". Incluso si funciona en el futuro, hay otras alternativas que no serán peores que el presente.
y agregó :
Por lo tanto, [los problemas con RDRAND] suenan poco probables, pero quién sabe... Aparentemente, el microcódigo puede hacer cualquier cosa, al menos los problemas iniciales de fTPM parecen deberse a que el BIOS hace cosas realmente locas como el acceso flash SPI.
Puedo imaginar fácilmente el código BIOS fTPM usando un bloqueo de "sincronización EFI" global absolutamente horrible o algo así, causando algunos problemas aleatorios completamente no relacionados.
Por ejemplo, no me sorprendería que no fuera el propio código fTPM hwrnd el que decidiera leer un número aleatorio de SPI, sino que simplemente se estuviera serializando con otra cosa involucrada en el BIOS. No todos los chicos de BIOS son conocidos por su código escalable totalmente paralelo...
Me sorprendería mucho si el microcódigo de la CPU pudiera hacer algo así. Y no es imposible: HP se ha metido con los contadores de marca de tiempo con SMI, y puedo imaginarlos, o alguien más, haciendo lo mismo con rdrand.
Pero en comparación con "EFI BIOS usa un enfoque de bloqueo único", parece poco probable.
Entonces, rdrand (y especialmente rdseed) puede ser bastante lento, pero creo que estamos hablando de cientos de ciclos de CPU (quizás miles). Bastante diferente de los informes de bloqueo que hemos visto de fTPM.
Con suerte, con la presión adicional de Torvalds, habrá más claridad y correcciones para abordar el problema de AMD fTPM en Linux.