Según he podido entender en slashdot, el riesgo viene de:
i) Hay un punto muy sutil que permitiría identificar a un thread que está usando la FPU de manera intensiva, pues podría "cronometrar" las paradas (usando, por ejemplo, la instrucción RTSC, que devuelve un contador). De ahí, se podría focalizar para efectuar el ataque al thread de codificación/encriptación.
ii) Una vez identificado, mediante un exploit, no proporcionado, patapám, se produce el acceso a los datos sensibles.
iii) Hay rumores (y por tanto, algo no fiable), que indican que al menos el exploit se podría evitar con una actualización del microcódigo de las CPU's (se puede efectuar al vuelo al inicio del S.O., p.e. hay algunas distribuciones de Linux que llevan la opción activada por defecto).
También comentaban que para evitar eso, mediante software, i.e. mediante el scheduler (aka planificador) del S.O. evitar que cuando se esté ejecutando una tarea susceptible de ser sensible no se ejecute código en la otra unidad de ejecución lógica. Este problema no se da en sistemas multiprocesador porque desde un thread en una CPU concreta no se podría identificar qué thread está consumiendo recursos de FPU (al menos, sin trampas).
Salud y buenos alimentos.
(¿Alguien necesita contratar a un ingeniero en informática para Barcelona? C/C++/Linux/Tiempo real/Control de dispositivos con buen nivel y experiencia. Contactadme en "ps2linux@hotmail.com")
Re:Habrá solución?
(Puntos:3, Informativo)( http://www.voluntariado.net/ | Última bitácora: Domingo, 10 Junio de 2012, 21:48h )
i) Hay un punto muy sutil que permitiría identificar a un thread que está usando la FPU de manera intensiva, pues podría "cronometrar" las paradas (usando, por ejemplo, la instrucción RTSC, que devuelve un contador). De ahí, se podría focalizar para efectuar el ataque al thread de codificación/encriptación.
ii) Una vez identificado, mediante un exploit, no proporcionado, patapám, se produce el acceso a los datos sensibles.
iii) Hay rumores (y por tanto, algo no fiable), que indican que al menos el exploit se podría evitar con una actualización del microcódigo de las CPU's (se puede efectuar al vuelo al inicio del S.O., p.e. hay algunas distribuciones de Linux que llevan la opción activada por defecto).
También comentaban que para evitar eso, mediante software, i.e. mediante el scheduler (aka planificador) del S.O. evitar que cuando se esté ejecutando una tarea susceptible de ser sensible no se ejecute código en la otra unidad de ejecución lógica. Este problema no se da en sistemas multiprocesador porque desde un thread en una CPU concreta no se podría identificar qué thread está consumiendo recursos de FPU (al menos, sin trampas).
Salud y buenos alimentos.
(¿Alguien necesita contratar a un ingeniero en informática para Barcelona? C/C++/Linux/Tiempo real/Control de dispositivos con buen nivel y experiencia. Contactadme en "ps2linux@hotmail.com")