El parche de AMD para su error Zen 1 «División por cero» no fue el final, sino todo lo que la compañía quería que fuera. Si bien la empresa se apresuró a emitir un parche, es posible que lo hayan hecho demasiado rápido: según Michael Larabel de Phoronix, el ingeniero de Linux de AMD, Borislav Petkov, publicó un nuevo parche que solucionó un problema con la solución original (también publicado por él mismo). ). Es solo otro punto de datos sobre las dificultades de fortalecerse contra posibles vectores de ataque.
El error original se relacionaba con cómo Zen 1 procesaba un cálculo entero dividido por 0 en ciertas circunstancias: según los hallazgos, existía la posibilidad de que la CPU de AMD mantuviera «datos de cociente obsoletos» dentro de sus registros incluso después de que la operación hubiera terminado por completo, lo que podría dar a los atacantes una ventana para recuperar información confidencial. La solución original era realizar una «división ficticia 0/1 final antes de regresar del controlador de excepciones #DE». La idea es simple: todos los datos antiguos que aún estuvieran almacenados se borrarían al completar la división 0/1 (cuyo resultado siempre es, bueno, cero).
El problema con esa solución, como explicó Petkov, era que para cuando se activara la provisión de seguridad, el ataque de ejecución especulativa ya habría avanzado demasiado: ya habría cierta cantidad de datos antiguos en el divisor de AMD, que los atacantes podrían obtener. antes de que entrara en acción la división ficticia. Como lo explicó Petkov, su nueva solución ahora obliga a esa misma división en varios escenarios:
«Inicialmente, se pensó que al hacer una división inocua en el controlador #DE se evitaría la filtración de datos antiguos del divisor, pero cuando se genera la falla, la especulación ya ha avanzado demasiado y dichos datos ya podrían han sido utilizados por operaciones más jóvenes.
Por lo tanto, realice la división inofensiva en cada salida al espacio de usuario para que el espacio de usuario no vea ningún dato potencialmente antiguo de las divisiones de enteros en el espacio del núcleo.
Haga lo mismo antes de VMRUN también, para evitar que los datos del host se filtren también en el invitado».
Ya ha sido un mes ajetreado por las vulnerabilidades en el ámbito de la CPU, y tanto AMD como Intel han sido afectados por revelaciones. Desde la vulnerabilidad Downfall más extrema de Intel (que afecta a Skylake a través de Tiger Lake/Rocket Lake) hasta las vulnerabilidades SQUIP e Inception de AMD (y la vulnerabilidad «divide by zero» ahora reparada, los investigadores han estado trabajando arduamente. Todavía no se compara con la historia histórica de los días Meltdown y Spectre (aunque estos nuevos errores también están relacionados con vulnerabilidades de ejecución especulativa. La ejecución especulativa se refiere a la forma en que las CPU modernas intentan adelantarse a los pasos de cálculo antes de que sean necesarios, de modo que los datos requeridos sean ya está disponible en caso de que se llame a la ejecución Sin embargo, si bien las correcciones a algunas de esas vulnerabilidades han conllevado (a veces severas) penalizaciones de rendimiento, es al menos una buena señal de que la división ficticia 0/1 de AMD no viene con sobrecarga adicional.
Al mismo tiempo, es alentador ver que, al menos en este caso, el parche de seguridad no se emitió con una especie de «configúrelo y olvídese», con el tipo de trabajo de carrusel que los expertos del equipo azul tenía que llevar, había otras formas en que esto podría haber funcionado (se podría haber creído que el parche deficiente funcionaba completamente, dejando la puerta abierta para más exploraciones de piratería en el futuro (con cualquier impacto que puedan tener).