Spectre, Meltdown y Hana

A finales de 1967, se sentaron las bases de lo que hoy llamamos "ejecución fuera de orden", de la paralelización a nivel del procesador principal y, por tanto, de una mejor utilización de las capacidades disponibles y, en última instancia, de un mayor rendimiento del sistema global.

Aunque las vulnerabilidades de seguridad no ponen en entredicho estos logros, las salvaguardas necesarias limitan inicialmente su uso práctico en determinadas condiciones, pero lo más importante es el posible impacto en el rendimiento global del sistema.

Me gustaría abordar el tema en cuatro pasos: Primero: ¿Qué son Spectre y Meltdown y a quién afectan? Segundo: ¿Qué podemos hacer? Tercero: ¿Qué ha hecho Suse hasta ahora y qué piensa hacer en los próximos meses? Y cuarto: ¿Por qué algunos fabricantes no dan cifras concretas sobre la pérdida potencial de rendimiento del sistema?

1. ¿a quién afectan Spectre y Meltdown?

La ampliación de la "ejecución fuera de orden" comentada anteriormente ha dado lugar a que hoy en día las CPU puedan ejecutar partes alternativas de los programas antes incluso de que esté claro cuál de las opciones se va a ejecutar.

Durante esta ejecución "especulativa", se producen lagunas en las que los mecanismos de protección de memoria habitualmente existentes entre el núcleo del sistema operativo y los procesos o entre los propios procesos dejan de ser eficaces y, por tanto, pueden producirse accesos no autorizados (véase la Tabla 1).

Como el error está en el hardware, el nivel de software (es decir, el sistema operativo y los programas de aplicación) ni siquiera se percata de este acceso. Todas las familias de CPU potentes actuales se ven afectadas por uno o varios de los posibles errores (véase la Tabla 2).

2. ¿qué podemos hacer?

La solución más obvia -sustituir todas las CPU- no es, obviamente, ni económicamente sensata ni prácticamente posible: todas las CPU de servidor actuales (incluidas otras arquitecturas y fabricantes distintos de los mencionados) están afectadas.

No es posible encontrar una solución completa a los problemas de seguridad únicamente en el software (es decir, a partir del sistema operativo o de la capa de aplicación). La única opción es "tapar" la brecha lo mejor posible -de ahí que en inglés se utilice más el término "mitigation" que el de "fix"- mediante una combinación de cambios en la propia CPU (si es que pueden modificarse a través del llamado microcódigo) y cambios en el sistema operativo.

El objetivo de estos cambios es evitar por completo la "especulación" a nivel de CPU o, al menos, impedir que otro proceso/aplicación/máquina virtual acceda a datos ajenos en la memoria principal (véase la Tabla 3).

En la Tabla 3, llama la atención la redacción "y/o", algo confusa. Esta redacción señala uno de los retos fundamentales en la comunicación de los fabricantes de software y, en especial, de sistemas operativos como Suse:

Para la variante 2 de Spectre en particular, no se puede encontrar una solución simple e inequívoca, porque dependiendo del fabricante de la CPU, el tipo de CPU y la generación de CPU, se debe tomar un camino de solución diferente. Volveremos sobre este tema en la sección 4.

3. ¿qué ha hecho Suse y qué tiene previsto hacer?

A principios de enero, Suse publicó un primer conjunto de parches para todas las versiones de Suse Linux Enterprise soportadas actualmente, incluido, por supuesto, Suse Linux Enterprise Server for SAP Applications, que limita el riesgo de Spectre (variante 1), prepara el núcleo del sistema operativo para los enfoques descritos de Spectre (variante 2) y corrige Meltdown (variante 3) al menos para la arquitectura x86-64.

Basándonos en los comentarios de nuestros socios de hardware y clientes, hemos estado ofreciendo un enfoque mejorado de Spectre (variante 2) para la arquitectura x86-64, las llamadas "retpolines", en una segunda oleada de actualizaciones del kernel desde mediados de febrero, y estamos mejorando el rendimiento en particular mediante una supervisión más fina de los accesos a la memoria.

Este trabajo de mejora constante de la seguridad y de ajuste de los accesos y restricciones llevará meses; algunos expertos en seguridad prevén incluso que lleve años.

4. ¿no hay cifras concretas?

Cada aplicación, incluso el uso específico de una aplicación y los datos correspondientes, contribuyen a determinar si los parches de seguridad tienen impacto y de qué manera (véase el Cuadro 4).

De lo dicho hasta ahora, casi huelga decir que no se puede hacer ninguna afirmación válida en general sobre los efectos de las actualizaciones de seguridad en el rendimiento global de un sistema; porque cada afirmación sólo es válida para una combinación específica de los cuatro factores siguientes:

1. Tipo de aplicación
2. Datos sobre los que opera la aplicación
3. Arquitectura CPU/hardware
4. Tipo y generación de CPU, incluida la disponibilidad de actualizaciones de microcódigo, especialmente en relación con la variante 2 de Spectre (véase la sección 2 anterior).

Lo más parecido que se puede decir es que las aplicaciones que realizan cálculos muy largos en la CPU sin acceder a la memoria son las menos afectadas. Espero que con estas explicaciones quede claro por qué es más grave desde el punto de vista de Suses no publicar cifras sobre la influencia de las actualizaciones de seguridad actuales en el rendimiento, aunque dicha influencia parezca inevitable según las circunstancias.

No obstante, aconsejamos a todos los clientes que instalen las actualizaciones del sistema operativo y del microcódigo lo antes posible y con la mayor regularidad posible, como parte de sus procesos de gestión de cambios, para minimizar los riesgos de esta familia de vulnerabilidades recientemente descubierta, aunque sorprendentemente antigua.