¿Por qué las CPU están diseñadas de manera que el exploit de "fusión" funciona? [duplicar]

12

Estoy tratando de envolver mi cabeza alrededor de "fusión", pero para entenderlo primero, he estado tratando de entender los accesos a la memoria.

Por lo que entiendo, la CPU intenta buscar la dirección virtual en el búfer interno de traducción, que indica qué datos hay en la memoria caché de la CPU. Si está allí, inmediatamente lo buscamos. De lo contrario, buscaremos la dirección en la tabla de páginas.

Ahora, desde mi lectura, cada proceso tiene su propia tabla de páginas. Sin embargo, cada proceso también tiene el núcleo asignado en su tabla de páginas.

Presumiblemente, la tabla de páginas también tiene bits de acceso, obviamente no podemos permitir lecturas directamente en el espacio del kernel cuando la CPU está en modo de usuario (creo que esto se llama "ring-3").

Por lo que entiendo de las tablas de páginas, estos bits de acceso se almacenan en los bits más bajos de la dirección. Como las entradas de nuestra página son 4k, quedan muchos bits para almacenar los bits de acceso.

Por lo que he leído sobre el exploit, el problema es que la verificación del acceso se realiza después de recuperar los datos. La razón de esto es por razones de eficiencia, queremos llevar rápidamente los datos a la CPU y solo podemos detectar el error de permiso antes de realizar cambios permanentes. Pero desafortunadamente, hemos afectado la memoria caché de la CPU al realizar una búsqueda de memoria indirecta que se puede detectar mediante ataques de tiempo.

Este esquema podría tener sentido si la búsqueda de la página fuera barata, pero la verificación de acceso es costosa. Pero a mi entender, ese no parece ser el caso.

He leído que la tabla de páginas en una máquina de 64 bits tiene al menos tres capas, lo que significa al menos tres búsquedas de memoria. Esperemos que estos estén en el caché, pero si no lo están, eso significa buscar recursivamente la tabla de páginas para sus propias páginas.

Después de haber hecho todo este trabajo y finalmente encontrar la entrada de la tabla de páginas, cuando cargamos la dirección física de la tabla de la página, también cargamos los bits de acceso. ¿Por qué no verlo ahí? Parece mucho más trivial comprobar el bit de acceso que ya hemos cargado que mezclar con circuitos para tratar con él más adelante.

Obviamente me estoy perdiendo algo acerca de cómo funciona la CPU, pero no puedo averiguar qué. Tenemos que hacer la búsqueda en la tabla de páginas para incluso averiguar qué recuperar, y una vez que hemos tenido ese problema, ¿por qué no solo verificamos el bit de acceso?

    
pregunta Clinton 08.01.2018 - 17:22
fuente

2 respuestas

1

Un par de cosas que te perdiste:

  1. Es posible que la memoria del kernel en cuestión ya esté en el caché, lo que hace que recuperar los datos sea tan rápido como recuperar los bits de acceso. Es una búsqueda dirigida por el contenido para ambos. Incluso si no, está el TLB. Los accesos completos a la tabla de páginas de tres niveles no son el caso común para optimizar cuando el objetivo es el rendimiento.

  2. El nivel de privilegio en sí puede ser cambiado por otras instrucciones a medio ejecutar en la tubería. Hasta que esas instrucciones estén totalmente retiradas, el nivel de privilegio en sí mismo es solo una especulación.

Me pregunto si el # 2 llevará al descubrimiento de aún más vulnerabilidades ...

    
respondido por el Ben Voigt 08.01.2018 - 20:42
fuente
0

La verdadera razón es que nadie se dio cuenta de los problemas de seguridad durante el diseño. No hay ninguna razón fundamental por la que las CPU no puedan implementarse de manera segura, y su pregunta describe una forma de hacerlo.

La ejecución especulativa es para el rendimiento, por lo que la CPU intenta hacer todo el trabajo posible antes de la ejecución real, pero no puede modificar el "estado arquitectónico", lo que el software puede ver. Cargar la memoria en un búfer interno no afecta el estado, por lo que puede hacerlo cuando lo desee. Pero causar una infracción de acceso lo afecta, por lo que los diseños actuales esperan hasta la ejecución real. (Esto es una especulación de mi parte).

A pesar de que AMD no es vulnerable a Meltdown, sospecho que eso es más suerte que planificación. El artículo de Meltdown dice que tanto Intel como AMD realizan búsquedas especulativas después de una infracción de acceso. Simplemente no pudieron crear un exploit práctico en AMD.

Una solución razonable es verificar los permisos antes de las búsquedas especulativas y detener la ejecución especulativa si se producen. Cuando la ejecución real se pone al día, puede provocar una interrupción y evitar dejar efectos en el sitio.

    
respondido por el paj28 08.01.2018 - 22:01
fuente

Lea otras preguntas en las etiquetas