Al leer el documento técnico , suena como pesimismo. La página web principal dice que “Specter es más difícil de explotar que Meltdown, pero también es más difícil de mitigar. Sin embargo, es posible evitar explotaciones conocidas específicas basadas en Specter a través de parches de software ".
Esto parecería implicar que no es posible no prevenir ataques desconocidos basados en Specter a través de parches de software, ¿es cierto?
El núcleo del ataque de Specter es utilizar un entrenamiento incorrecto del predictor de ramificación de la CPU para hacer que la CPU se ramifique especulativamente a un fragmento de código seleccionado por el atacante mientras ejecuta el programa objetivo, luego observa los efectos indirectos de ejecutar ese código. Esto solo es posible porque las CPU actuales comparten el estado del predictor de rama en todos los subprocesos que se ejecutan en la computadora.
Es posible escribir código x86 / amd64 que sea inmune a Specter insertando instrucciones que eviten la ejecución especulativa después de cada rama (por ejemplo, las instrucciones cpuid o mfence ), pero esto tiene el costo de una Pérdida severa de rendimiento, y solo se puede aplicar a un nuevo software.
Una CPU que permita vaciar el estado del predictor de ramificación podría hacerse inmune a Specter restableciendo el estado en cada cambio de contexto (a costa de cierto rendimiento). Ni la implementación de Intel ni la de AMD de la arquitectura x86 / amd64 parece tener tal instrucción (todavía), pero espero que aparezca en unos pocos años. Esto tendría mucho menos impacto en el rendimiento que la prevención de la ejecución especulativa, ya que incluso un predictor de ramificación sin inicializar es aproximadamente un 70% preciso.
Aquí hay dos situaciones diferentes. Uno ejecuta código de máquina no confiable en una CPU. El otro está ejecutando códigos de bytes no confiables o scripts en un compilador JIT, como Javascript.
editar: cambié algunas cosas debido a mi mala interpretación del código que Specter utiliza para funcionar correctamente. Utiliza el código existente con privilegios más altos con ramas condicionales donde la CPU está deliberadamente diseñada para ejecutar la ruta incorrecta en la rama con datos maliciosos, lo que da como resultado lecturas de memoria que se almacenan en caché y luego se descartan. Excepto por el código de prueba de concepto, el exploit usa código ya en el sistema, no su propio código como dije anteriormente.
Meltdown está relacionado con la ejecución de código de máquina no confiable en una CPU Intel en un entorno restringido, como una cuenta de usuario limitada. El código puede usar Meltdown para acceder a la memoria protegida contra lectura, como la memoria del kernel que se supone que está fuera de los límites. No está relacionado con los compiladores JIT.
Specter está relacionado con: 1) Como Meltdown, ejecutar código de máquina no confiable en un entorno restringido y acceder a memoria restringida como la memoria del núcleo. Lo que se puede acceder depende de lo que se asigna al espacio de direcciones virtuales cuando se ejecuta el código vulnerable de Specter. 2) JIT compiers tales como Javascript. Los entornos restringidos compilados de Javascript y JIT que ejecutan código no confiable pueden ser explotados por Specter para obtener acceso al espacio de direcciones del compilador JIT de Javascript, el navegador, y probablemente más que eso.
El código que se ejecuta en un compilador o intérprete JIT tiene la ventaja de que solo necesita parches en el compilador o intérprete JIT para solucionar el problema. Hacer que el script atacante no pueda sondear el caché puede derrotar a Specter. Creo que parchear contra Specter para el código nativo es donde se hace más difícil.
El parche de aislamiento de la tabla de páginas que se usa para arreglar Meltdown no corrige Specter *. El código vulnerable de Specter es un código condicional que ya está en el sistema. Para hacer uso de Specter, este código se ejecuta con privilegios diferentes a los del programa atacante, de modo que tiene acceso a los datos a los que el programa atacante no tiene acceso. Después de que el programa atacante prepara las memorias caché y confunde el predictor de rama, el programa atacante invoca el código vulnerable de Specter con argumentos que hacen que sus instrucciones ejecutadas de manera especulativa se lean de la memoria contra la que normalmente protege. Estas instrucciones de lectura nunca son ejecutadas completamente por la CPU porque las descarga una vez que descubre que la predicción de bifurcación fue incorrecta. Pero las operaciones de lectura afectaron los cachés, y ahora el programa atacante analiza los cachés para encontrar los datos.
Entonces sí, es posible hacer parches de software. Una vez que se encuentra que son vulnerables, los condicionales individuales pueden modificarse de tal manera que son inútiles para Specter. Se puede hacer un enfoque más genérico de agregar código de máquina después de todas las instrucciones de bifurcación para hacer que la CPU no ejecute nada de manera especulativa. ¡Esto causará un impacto notable en el rendimiento, ya que una CPU moderna puede ejecutar de manera especulativa más de 100 instrucciones mientras espera para verificar una predicción de bifurcación! Tal vez se pueda hacer algún tipo de modificación del compilador para que deshabilite la ejecución especulativa después de los condicionales que acceden a los datos en función del valor de la variable utilizada para el condicional o los accesos a la memoria basados en datos externos, o podría requerir que las variables utilizadas en los condicionales sean almacenados en un registro para garantizar que la ejecución especulativa esté habilitada.
* Lo que he dicho aquí involucra accesos de memoria a áreas que son legibles por el código vulnerable de Specter. Lo que no sé todavía es si las instrucciones ejecutadas de forma especulativa pueden acceder a datos protegidos contra lectura como lo hace Meltdown. ¿Tal vez esto sea posible en las CPU de Intel y no en AMD? Sospecho que no hay mucha discusión sobre esto porque la mayoría de las CPU son Intel y todo lo que Intel sea vulnerable a Specter también es vulnerable a Meltdown. Pero podría ser importante para el código no confiable que se ejecuta en un compilador JIT, ya que dicho código tendría acceso a la parte protegida contra lectura del espacio de direcciones del compilador JIT (el kernel y la memoria física) mientras usa el código vulnerable de Specter que se ejecuta con los privilegios de El compilador JIT. Los parches de aislamiento de la tabla de páginas arreglarían esto, pero los usuarios pueden pensar que, dado que no están ejecutando código nativo, no lo necesitan.
Lea otras preguntas en las etiquetas spectre