@GXY Encantado de debatir contigo.
tal como ponen en el mismo enlace que me pones de TheRegister:
The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI.
Hasta ahora, para mantener la seguridad de los procesos (que un proceso no husmee en la memoria asignada a otro, y sobre todo, en el kernel), los Sistemas Operativos confiaban en establecer limites en los accesos a nivel de MMU, de tal forma, que un intento de lectura en la memoria asignada a otro proceso, levantaria una excepcion de seguridad. El bug descubierto es que, a pesar de que el acceso a la memoria de un proceso desde otro es detectado y tratado correctamente (o sea, evitado y una excepcion levantada), el acceso ESPECULATIVO no era evitado hasta que era REALMENTE ejecutado.
¿que es la ejecucion especulativa? en la ejecucion especulativa, la CPU analiza lo que se va a ejecutar para traer desde memoria principal (mucho mas lenta) a memoria cache de la CPU (infinitamente mas rapida) los valores con los que va a trabajar proximamente, y ademas, intenta predecir cuales van a ser los saltos de ejecucion futuros y trae de RAM los datos que PODRIAN ser necesarios en el futuro.
En un pipeline de ejecucion Out-Of-Order como las CPUs actuales
https://en.wikipedia.org/wiki/Out-of-or ... processors la instruccion esperaria pacientemente en la CPU hasta que los datos estuviesen disponibles en cache L1/L2, entonces seria ejecutada, y seria solo entonces cuando la excepcion por acceso ilegal seria levantada (y tratada) por la CPU. El bug se aprovecha de que, aunque la excepcion seria levantada, el dato YA SE ENCUENTRA en la cache L1/L2, y puede ser accedido a traves del interfaz de acceso a la cache L1/L2.
La forma en que se ejecuta el exploit es:
- construyo un codigo en el cual provoco que la ejecucion especulativa de la CPU acceda a un dato que provocaria un acceso ilegal, de tal forma que el dato prohibido es accedido por la unidad de prediccion especulativa y traido a la cache L1/L2 de la CPU.
- antes de que dicha instruccion que accede a dicho dato prohibido sea ejecutada, provoco un salto de ejecucion no previsto a mi propio codigo que hace que dicha ejecucion especulativa sea erronea, tire todo el pipeline de ejecucion a la basura, y siga ejecutando mi codigo
- accedo a la cache L1/L2 de la CPU, y recojo el dato al cual deberia tener acceso prohibido.
Como ves, el problema aqui es que, cuando se borra el pipeline de ejecucion porque ha habido un salto de ejecucion incorrectamente 'especulado', la CPU deberia borrar tambien el dato que se ha traido especulativamente a la cache L1/L2, o bien, que el acceso especulativo a memoria prohibida, sea detectado por los sistemas de seguridad de la MMU.
La solucion es que la memoria asignada al kernel sea protegida por un sistema adicional de seguridad que se denominan 'Isolated Pages', y es un bit adicional que se setea en la MMU, en la cual, se establecen que unas determinadas zonas de la RAM estan AISLADAS, y JAMAS deben ser accedidas por otro proceso que no sea el que las creo. Este mecanismo de seguridad PROTEGE contra el bug, puesto que el acceso esta cortado a nivel de MMU, y no solo detectado por la unidad de ejecucion de la CPU. Todo acceso a las 'Isolated Pages', sea el que sea, levanta una interrupcion en la CPU para que la CPU verifique si dicho acceso es permitido.
Si las CPUs disponen de este mecanismo de seguridad, ¿porque no se usaba? porque usarlo implica una caida de rendimiento entre el 10% y el 30% en sistemas con mucho acceso a disco (Syscalls) y mucho tratamiendo de interrupciones (Virtualizacion)
el parche KPTI (Kernel Page Table Isolation) no desactiva la ejecucion especulativa, simplemente refuerza la seguridad del kernel a costa de una penalizacion de rendimiento.
Y ahora, vamos al 9x que tanto te escama.
el 9x seria la penalizacion que tendriamos si desactivamos al EJECUCION ESPECULATIVA.
los pipelines de ejecucion especulativa actuales tienes unas 14-19 etapas
https://en.wikichip.org/wiki/Special:Br ... -20(client) pero los antiguos pentium 4 prescott con microarquitectura netburst tenian pipelines gigantes de hasta 31 etapas
http://www.tomshardware.com/reviews/intel,751-5.htmlImaginate un pipeline de ejecucion
https://en.wikipedia.org/wiki/Instruction_pipelining como una fabrica de vehiculos, en la cual, internamente, se realizan diversas tareas en serie, que dan como resultado final un coche construido. en cada etapa del proceso, se realiza una tarea concreta. Un coche tarda en construirse 15 dias, pero la fabrica es capaz de producir 30 coches diarios, por supuesto, en el interior de la fabrica, se encuentran coches en diversos estados/etapas de fabricacion.
La ejecucion especulativa es:
- predecir que, puesto que todo coche tiene 1 volante, si solamente te quedan 50 volantes, tienes volantes para dia y medio, y habria que pedir mas, en lugar de esperar a quedarte sin volantes, parar toda la cadena de produccion esperando que lleguen nuevos volantes, o bien
- predecir que desde central van a cambiar el modelo de coche a fabricar y ahora en lugar de 2 asientos, cada coche va a necesitar 5, por lo tanto, hay que pedir mas asientos de los previstos
si la ejecucion especulativa no funcionase, el procesador se atascaria cada dos por tres, ya que los accesos 'no naturales' a RAM deberian ser resueltos en el mismo momento de la ejecucion de la instruccion, atascando toda al CPU, o bien, en caso de saltos condicionales, la CPU deberia esperar a que el resultado estuviese disponible para saber donde seguir la ejecucion en lugar de ejecutar una de las ramas 'especulativamente'.
en su dia lei que la desactivacion de la ejecucion especulativa de los Intel Prescott conllevaria una penalizacion de 9x en su rendimiento, obviamente, eso fue hace tanto tiempo que no tengo el enlace. tendras que creer mi palabra, pero creo que tal como te he planteado el dilema, veras que una penalizacion 9x es muy posible.
No se va a desactivar la ejecucion especulativa. nunca. ademas, que seria imposible, esta a nivel de arquitectura y microcodigo de la CPU.
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[mad]](/images/smilies/nuevos/miedo.gif "loco")
![[burla2]](/images/smilies/nuevos/burla_ani1.gif "burla2")
