Linus Torvalds, el creador de Linux, aparentemente está «frustrado» con el hardware defectuoso de empresas como Intel, AMD y NVIDIA, afirmando que los fabricantes son la razón detrás de las vulnerabilidades.
Linus Torvalds expresa su resentimiento hacia los fabricantes de hardware, incluidos Intel, AMD y NVIDIA, ante las modificaciones del código del kernel para solucionar los ataques teóricos
Bueno, el creador de Linux tiene una forma de expresar los problemas que tiene el sistema operativo, principalmente cuando están asociados a un factor externo, probablemente empresas de CPU como AMD e Intel. Torvalds ha estado bastante activo últimamente en la reparación del núcleo de Linux debido a errores y fallas reportadas. Esta vez, según él, ha expresado su resentimiento hacia las modificaciones que se están haciendo en el núcleo de código abierto para atender vulnerabilidades que son culpa del fabricante del hardware.
Torvalds señala específicamente las CPU más nuevas de Intel que debutan con soporte para LAM (Linear Address Masking), y esto es lo que tenía para decir ( a través de kernel.org ) en la bandeja de entrada pública de la lista de correo del kernel de Linux:
Sinceramente, estoy bastante harto de hardware con errores y ataques completamente teóricos que nunca se han demostrado realmente en la práctica. Así que creo que esta vez vamos a hacer frente a la gente del hardware y decirles que es *SU* maldito problema, y si ni siquiera se molestan en decir sí o no, nos quedaremos de brazos cruzados.
Maldita sea, pongamos la responsabilidad en quién tiene la culpa y no tomemos cualquier «…» aleatorio de un hardware defectuoso y digamos «oh, pero *podría* ser un problema».
– Linus Torvalds
Bueno, es cierto que se trata de una elección de palabras interesante, pero no se puede discutir lo que afirma Torvalds, dado que es realmente complicado solucionar un problema en el núcleo, que probablemente esté asociado con la «gente del hardware» y su implementación. En términos de LAM, esta característica en particular se utiliza para garantizar la integridad de la memoria mediante el empleo de una «implementación basada en punteros»; sin embargo, esta técnica ha dado lugar a frecuentes ataques de especulación denominados SLAM, que es aparentemente lo que está molestando a Torvalds por ahora.
Un ingeniero de Intel respondió al problema de LAM y afirmó que se pretendía desactivarlo hasta que se implementara una solución, pero esto no sucedió. Sostuvo que los ataques SLAM se podrían evitar con LASS (separación lineal del espacio de direcciones), pero el equipo no ha publicado la solución por ahora.
El creador de Linux expresa su “frustración” por los errores de fTPM de AMD y pide desactivar la función.
Los problemas de fTPM de AMD son bien conocidos en la industria y suelen provocar bloqueos y caídas del sistema. El creador de Linux, Linus Torvalds, ha expresado su decepción por esta función, calificándola de «plaga» para el kernel.
Los problemas de fTPM de AMD tienen una larga historia y surgieron con el lanzamiento de Windows 11
Para resumir rápidamente, el módulo de plataforma segura (TPM) es una comprobación de seguridad que se ha convertido en una necesidad para la última versión de Windows 11. Si bien la intención detrás de esta medida es beneficiar al consumidor, la función trajo varios problemas. Los principales problemas que trajo fTPM fueron tartamudeos aleatorios y retrasos. Además, varios usuarios también experimentaron temblores e interrupciones mientras jugaban. Si bien el problema ocurrió en la plataforma Intel, la mayoría de los problemas se dieron en AMD, que aún persisten en la actualidad.
AMD lanzó varias correcciones para solucionar el problema y, hasta cierto punto, se resolvieron. Sin embargo, en el kernel de Linux, la situación es diferente. El problema de TPM en Linux también se destaca en Kernel.org Bugzilla , un sitio famoso por identificar errores en el kernel. Esto es lo que Linus Torvalds dijo sobre los problemas emergentes debido a fTPM:
Simplemente desactivemos esa estúpida cosa de fTPM hwrnd.
Quizás se pueda usar para «recopilar entropía de diferentes fuentes» en tiempo de arranque, pero claramente *no* debería usarse en tiempo de ejecución.
¿Por qué alguien usaría esa porquería cuando cualquier máquina que supuestamente lo tiene arreglado (lo que aparentemente no resultó ser cierto después de todo) también tendría la instrucción rdrand de CPU que no tiene el problema?
Si no confía en la implementación de rdrand de CPU (y que también ha tenido errores; consulte clear_rdrand_cpuid_bit() y x86_init_rdrand()), ¿por qué confiaría en la versión fTPM que ha causado aún *más* problemas?
Por lo tanto, no veo ningún inconveniente en decir simplemente «ese asunto de fTPM no funciona». Incluso si funciona en el futuro, hay alternativas que no son peores.
Si bien la declaración del creador de Linux expresa su resentimiento hacia el problema, también mencionó los codificadores de BIOS de la placa base, los factores de ponderación para RDRAND basado en CPU y HWRND basado en fTPM. Esperamos que se publiquen soluciones para los problemas identificados en el futuro, pero toda la saga de «fTPM» es decepcionante y, por lo que parece, aún no ha terminado.
