Linux 6.13 se retrasa debido a problemas ocasionados por un parche enviado por Microsoft
El lanzamiento de la nueva versión del kernel Linux 6.13 se ha visto retrasada debido a problemas de estabilidad generados por un cambio introducido por un empleado de Microsoft. Se menciona que este cambio fue aceptado en la rama principal en el pasado mes de noviembre de una forma que ha sorprendido a muchos, ya que no siguió las prácticas habituales.
El parche fue enviado de manera no estándar y aprobado sin recibir acuses de recibo (ACK) por par de los mantenedores de la arquitectura x86, lo que constituye una violación de las normas aceptadas en el desarrollo del kernel.
El parche en cuestión introdujo soporte para el uso de páginas de memoria grandes en modo ROX (solo lectura y ejecutable) al asignar memoria destinada a código ejecutable y la finalidad del parche enviado era reforzar la seguridad del sistema al dificultar la explotación de vulnerabilidades mediante la ejecución de código malicioso en memoria marcada como solo lectura.
El uso de páginas grandes para mapear áreas de texto reduce la presión de iTLB y mejora el rendimiento.
Amplíe execmem_alloc() con la capacidad de usar páginas grandes con permisos ROX como caché para asignaciones más pequeñas. Para llenar el caché, se asigna una página grande escribible desde vmalloc con VM_ALLOW_HUGE_VMAP, se llena con instrucciones no válidas y luego se vuelve a mapear como ROX.
El alias de mapa directo de esa página grande se excluye del mapa directo. Se entregan partes de esa página grande a los que llaman a execmem_alloc() sin ningún cambio en los permisos. Cuando se libera la memoria con execmem_free(), se invalida nuevamente para que no contenga instrucciones obsoletas.
Se menciona que el retraso en el lanzamiento del kernel 6.13 se debe a que el uso de un caché de páginas de memoria ejecutables grandes en modo ROX fue habilitado de forma predeterminada para los módulos en sistemas x86_64. El cambio abordó un problema técnico importante: la asignación de páginas en modo ROX para código ejecutable que aún no estaba completamente preparado.
Esto permitió evitar la necesidad de reasignar temporalmente las páginas de modo ROX a modo de escritura hasta que los módulos del kernel estuvieran listos para su ejecución. Sin embargo, a pesar de los beneficios previstos, los problemas de estabilidad identificados ponen en duda la calidad y la seguridad del parche, lo que llevo a la necesidad de extender las pruebas antes del lanzamiento definitivo.
Y tal parece que los desarrolladores no se equivocaron, ya que durante la fase final de pruebas del kernel Linux 6.13, un ingeniero de Intel detectó un problema crítico que afectaba el funcionamiento del sistema en algunas laptops con procesadores basados en la microarquitectura Alderlake. El problema se manifestaba al intentar reactivar el kernel desde el modo de suspensión, un fallo particularmente relevante en dispositivos móviles.
x86: Deshabilitar la compatibilidad con EXECMEM_ROX
El module_writable_address() causó un desastre gigante.
alternative.c, sin mencionar que todavía contiene errores, algunos de los cuales son notables.
Las variantes del CFI fracasan y fracasan.Mike ha estado trabajando en parches para limpiar todo esto nuevamente, pero dada la situación actual, esto simplemente no está listo.
Desactivar por ahora, intentemos nuevamente en el próximo ciclo.
El inconveniente surgió al compilar el kernel con el compilador Clang y habilitar el modo de protección CFI (Control Flow Integrity). Este modo está diseñado para reforzar la seguridad al bloquear manipulaciones indebidas del flujo de control, como las que ocurren en ataques que alteran punteros de función en la memoria. Sin embargo, la interacción entre CFI y las nuevas optimizaciones introducidas en el kernel para el manejo de páginas de memoria ROX (solo lectura y ejecutables) resultó problemática.
El mecanismo EXECMEM_ROX, que permite utilizar un caché de páginas de memoria ejecutables marcadas como solo lectura, parecía ser la causa raíz de los fallos observados en la reactivación del sistema. Como solución temporal, los mantenedores de Intel y AMD responsables de la arquitectura x86 propusieron deshabilitar EXECMEM_ROX en la versión 6.13 del kernel. Esto permitirá lanzar el kernel mientras se trabaja en un parche definitivo que resuelva el problema sin comprometer la estabilidad ni la seguridad.