Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer la noticia de que Eric Biggers, uno de los desarrolladores del cifrado Adiantum y mantenedor del subsistema del kernel de Linux fscrypt, propuso un conjunto de parches para bloquear los problemas de seguridad derivados de la peculiaridad de los procesadores Intel que no garantizan tiempos de ejecución constantes para las instrucciones de los diferentes datos procesados.

Sobre su propuesta menciona que en los procesadores Intel, el problema se viene manifestando desde la familia Ice Lake, ademas de que tambien un problema similar se observa en los procesadores ARM.

La dependencia del tiempo de ejecución de las instrucciones de los datos procesados ​​en estas instrucciones es considerada por el autor de los parches como una vulnerabilidad en los procesadores, ya que tal comportamiento no puede garantizar la seguridad de las operaciones criptográficas realizadas en el sistema.

Me gustaría llamar la atención de la gente sobre el hecho de que en los últimos CPU Intel y Arm , por el defecto en el tiempo de ejecución de las instrucciones puede depender de los datos valores operados. Esto incluso incluye instrucciones como adiciones, XOR e instrucciones AES, que tradicionalmente se supone que son de tiempo constante con respecto a los valores de datos operados.

Muchas implementaciones de algoritmos criptográficos se basan en el hecho de que los datos no afectan el tiempo de ejecución de las instrucciones, y la violación de este comportamiento puede dar lugar a la creación de ataques de canal lateral que recuperan datos en función del análisis del tiempo de procesamiento.

Potencialmente, la dependencia del tiempo de ejecución de los datos también se puede usar para organizar ataques para determinar los datos del kernel del espacio del usuario.

Las instrucciones de tiempo no constante rompen el código criptográfico que se basa en el código de tiempo constante para evitar ataques de tiempo en claves criptográficas, es decir, la mayoría
código criptográfico. Este problema también puede tener un impacto más amplio en la capacidad de
sistemas operativos para proteger los datos de procesos no privilegiados.

Para Intel, los procesadores con Ice Lake y posteriores se ven afectados por este problema.

La solución para este problema es establecer un indicador de CPU que restaure el antiguo, correcto
comportamiento de temporización independiente de datos: DIT en Arm y DOITM en Intel.

Según Eric Biggers, incluso para instrucciones que realizan operaciones de suma y XOR, así como para instrucciones AES-NI especializadas, no se proporciona un tiempo de ejecución constante por defecto (la información no se confirma mediante pruebas, según otros datos, hay un retraso de un ciclo al multiplicar vectores y contar bits).

Para deshabilitar este comportamiento, Intel y ARM han propuesto nuevas soluciones, como el bit PSTATE DIT (Data Independent Timing) para CPU ARM y el bit DOITM (Data Operand Independent Timing Mode) MSR para Intel CPU, devolviendo el comportamiento anterior con tiempo de ejecución constante.

Intel y ARM recomiendan activar la protección según sea necesario para el código crítico, pero en realidad, pueden ocurrir cálculos importantes en cualquier parte del kernel y del espacio del usuario, por lo que se está considerando la posibilidad de habilitar permanentemente los modos DOITM y DIT para todo el kernel.

Para los procesadores ARM, la rama del kernel de Linux 6.2 ya recibió parches que cambian el comportamiento del kernel, pero estos parches se consideran insuficientes, ya que solo cubren el código del kernel y no cambian el comportamiento del espacio del usuario.

Para los procesadores Intel, la inclusión de la protección se encuentra actualmente solo en la etapa de revisión. El impacto del parche en el rendimiento aún no se ha medido, pero según la documentación de Intel, habilitar el modo DOITM reduce el rendimiento (por ejemplo, debido a la desactivación de algunas optimizaciones, como la precarga específica de datos) y, en futuros modelos de procesadores, la degradación del rendimiento puede incrementar.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.