logo intel

Corrección de fallo de seguridad en CPUs Intel en ciernes

Algo grande se está moviendo entre bambalinas pero nadie da explicaciones de momento. Se trata de un fallo de seguridad cuyos pormenores se mantienen en secreto hasta que se publiquen los parches pertinentes para Linux y Windows.

Normalmente, lo bugs de hardware no afectan a la seguridad sino a las características del micro, produciendo ciertos fallos cuando se ejecutan ciertas instrucciones en un cierto orden muy determinado.

Todavía no hay nada oficial pero según parece, la gente de Intel lleva tiempo vomitando código como si no hubiera un mañana en el kernel de Linux con vistas a publicar un parche lo antes posible con backport incluido. Mientras tanto, Microsoft ha estado trabajando en todo esto desde noviembre en su núcleo NT, aunque por su filosofía de desarrollo, no se sabe prácticamente nada de lo que ha estado haciendo al respecto.

El problema en principio afecta a los servicios de la «nube» que están funcionando sobre micros x86 de Intel y el parche está relacionado con lo que en Linux se ha denominado page-table isolation. Lo malo es que al ser un fallo de hardware, la solución por software va a reducir el rendimiento de los micros de Intel. Y la bajada de rendimiento se está estimando en un nada desdeñable 29-34%. Según Brad Spengler de ‘grsecurity’, la merma de rendimiento en un i7-6700 sería del 29% y en un i7-3770S de un 34%.

El tal PTI no es aplicable a procesadores AMD porque tal y como explica Tom Lendacky, los procesadores AMD no están sujetos a los tipos de ataque de los que protege la «page table isolation». La microarquitectura AMD no permite referencias de memoria incluyendo referencias especulativas que acceden a datos de mayor privilegio mientras se ejecutan en un modo de menor privilegio cuando ese acceso podría desembocar en error de página.

En esta entrada del blog ‘python sweetness’, explican con detalle el propósito de los parches cuyo fin sería prevenir ataques quitando del mapa de la tabla de páginas de procesos la mayor parte posible del kernel de Linux cuando el proceso se ejecuta en el espacio de usuario, evitando así identificar rangos de direcciones virtuales del kernel desde código que se está ejecutando desde el espacio de usuario (que debería no tener privilegios suficientes para hacer acceder a dichos rangos del mapa).

Una vez que se ha destapado parte del pastel, los parches deberían aparecer en cuestión de horas y a partir de entonces se sabrán con certeza las verdaderas consecuencias en el rendimiento.

Ver comentarios