Barrapunto

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")

oh, por supuesto. Intel llevará a cabo una sustitución de todos los procesadores vendidos hasta hoy porque existe un 0.000000000000000000000001% de posibilidades de que un fallo afecte al 0.00000000000001% de las personas que usan las claves RSA, que son el 0.0005% de los usuarios de PC.

Menuda tontería has dicho. Este fallo pertenece al grupo de esos fallos curiosos para los que practicamente no existe riesgo real.