Lazy FPU state leak ( CVE - 2018-3665), también conocida como Lazy FP State Restore [1] o LazyFP , [2] [3] es una vulnerabilidad de seguridad que afecta a las CPU Intel Core . [1] [4] La vulnerabilidad es causada por una combinación de fallas en la tecnología de ejecución especulativa presente dentro de las CPU afectadas [1] y cómo ciertos sistemas operativos manejan el cambio de contexto en la unidad de punto flotante (FPU). [2] Al explotar esta vulnerabilidad, un proceso local puede filtrar el contenido de los registros de FPU que pertenecen a otro proceso. Esta vulnerabilidad está relacionada con las vulnerabilidades Spectre y Meltdown que se divulgaron públicamente en enero de 2018.
Fue anunciado por Intel el 13 de junio de 2018, después de ser descubierto por empleados de Amazon , Cyberus Technology y SYSGO . [1] [a]
Además de utilizarse para aritmética de punto flotante , los registros FPU también se utilizan para otros fines, incluido el almacenamiento de datos criptográficos cuando se utiliza el conjunto de instrucciones AES , presente en muchas CPU de Intel. [3] Esto significa que esta vulnerabilidad puede permitir que el material clave se vea comprometido. [3]
Los registros de punto flotante y SIMD son grandes y no son utilizados por todas las tareas (o subprocesos) del sistema. Para que el cambio de contexto sea más rápido, la mayoría de los microprocesadores comunes admiten el cambio de estado diferido. En lugar de almacenar el estado completo durante un cambio de contexto, el sistema operativo puede simplemente marcar el FPU como "no disponible" con la esperanza de que la tarea a la que se cambia no lo necesite. Si el sistema operativo ha adivinado correctamente, se ahorra tiempo. Si la suposición es incorrecta, la primera instrucción FPU o SIMD provocará una trampa en el sistema operativo, que luego puede guardar el estado en la tarea anterior y cargar el estado correcto para la tarea actual.
En las CPU fuera de servicio , la condición de "FPU no disponible" no se detecta inmediatamente. (De hecho, casi no se puede detectar inmediatamente, ya que puede haber múltiples instrucciones que causan fallas ejecutándose simultáneamente y el procesador debe tomar la primera falla encontrada para preservar la ilusión de ejecución en orden. La información sobre cuál es la primera no está disponible hasta la etapa de retiro en orden). El procesador ejecuta especulativamente la instrucción utilizando el contenido del registro de la tarea anterior y algunas instrucciones posteriores, y solo más tarde detecta la condición de FPU no disponible. Aunque todo el estado arquitectónico se revierte al comienzo de la instrucción que falla, es posible usar parte del estado de FPU como la dirección en una carga de memoria, lo que activa una carga en la caché del procesador. La explotación sigue entonces el mismo patrón que todas las vulnerabilidades de la familia Spectre: como el estado de la caché no es un estado arquitectónico (la caché solo afecta la velocidad, no la corrección), la carga de la caché no se deshace y la dirección, incluida parte del estado del registro de la tarea anterior, se puede detectar posteriormente midiendo el tiempo que lleva acceder a diferentes direcciones de memoria.
Es posible explotar este error sin activar ninguna trampa del sistema operativo. Al colocar el acceso a la FPU en la sombra de una predicción errónea de rama forzada (por ejemplo, utilizando un retpoline ), el procesador seguirá ejecutando el código de manera especulativa, pero volverá a la rama mal predicha y nunca ejecutará realmente la trampa del sistema operativo. Esto permite que el ataque se repita rápidamente, leyendo rápidamente todo el estado del registro FPU y SIMD.
Es posible mitigar la vulnerabilidad en los niveles del sistema operativo y del hipervisor restaurando siempre el estado de la FPU al cambiar de contexto de proceso. [6] Con una solución de este tipo, no se requiere ninguna actualización de firmware . Algunos sistemas operativos ya no restauraban de forma perezosa los registros de la FPU de forma predeterminada, protegiendo a esos sistemas operativos en las plataformas de hardware afectadas, incluso si existía el problema de hardware subyacente. [6] En el sistema operativo Linux que utiliza el kernel 3.7 o superior, es posible forzar al kernel a restaurar con entusiasmo los registros de la FPU utilizando el eagerfpu=onparámetro del kernel. [3] Además, muchos proveedores y proyectos de software del sistema , incluidas las distribuciones de Linux , [7] OpenBSD , [8] y Xen [4] han publicado parches para abordar la vulnerabilidad.