La mitigación de dos defectos arquitectónicos críticos en las CPUs puede causar degradación del rendimiento, pero el impacto en el mundo real es menor que los puntos de referencia sintéticos.
Un defecto de diseño en los chips de Intel podría forzar cambios importantes en el núcleo del sistema operativoUn defecto de diseño en los chips de Intel que se remonta a años atrás está requiriendo grandes cambios en las máquinas Windows, Linux y MacOS, dice Brandon Vigliarolo, de ConsejoTecnologico.com.
A raíz de las fallas arquitectónicas de Meltdown y Spectre, las empresas de cloud computing se están esforzando por aplicar parches a estas vulnerabilidades. Tanto los procesadores AMD como los procesadores Intel se ven afectados por el par, pero sólo los procesadores Intel son vulnerables a todas las variantes de ataque. Mientras que estas fallas arquitectónicas son posibles para mitigar parcialmente el uso de parches de software, el problema central – una supervisión en el diseño que requiere un hardware revisado – aún permanece.
SEE: Política de notificación de incidentes de seguridad de la información (Tech Pro Research)
El primer parche, Kernel Page Table Isolation (KPTI), ha sido objeto de muchas especulaciones, ya que los primeros informes estimaban una regresión del rendimiento del 30%. Tal como están las cosas, el impacto en el mundo real ha sido menor que el que se ha dado hasta ahora. Naturalmente, todo rendimiento depende de la carga de trabajo. Aunque las pruebas sintéticas pueden utilizarse como un buen indicador de la velocidad de ciertas operaciones, a menudo exageran altibajos en comparación con las cargas de trabajo del mundo real.
Desmitificando las afirmaciones sobre la desaceleración de la KPTI
KPTI corrige parte de la vulnerabilidad separando las tablas de páginas de espacio de usuario y espacio de núcleo. Esto necesariamente introduce una penalización de rendimiento, ya que las llamadas o interrupciones del sistema tienen gastos generales de conmutación de contexto. Debido a esto, las cargas de trabajo que dependen en gran medida de ellas serán las más afectadas después de la aplicación de parches. Sin embargo, la introducción de identificadores de contexto de proceso (PCID) reduce esa sobrecarga, ya que esta característica evita que los procesos miren datos no asociados con el proceso activo en el búfer de aspecto de traducción (TLB. Con esta protección adicional, se puede evitar el ciclo de lavado y repoblación del TLB.
Nube que hay que leer
El soporte de hardware para PCIDs se introdujo con la generación de procesadores Westmere, aunque el soporte para esta característica sólo estaba habilitado en la versión 4.14 del kernel de Linux. Mientras que KPTI ha sido soportado de nuevo en los núcleos 4.4 y 4.9, el soporte para PCIDs no lo ha sido. Comparar los resultados entre los tres núcleos con KPTI habilitado y deshabilitado es quizás el mejor indicador disponible de regresiones de rendimiento entre los dos. Mediante el Open Benchmarking, se han realizado algunos benchmarks de prueba.
La comparación más interesante a hacer aquí es el rendimiento de PostgreSQL, ya que el desarrollador Andrés Freund publicó el 2 de enero puntos de referencia que indican regresiones del 7-17%, y del 16-23% sin PCID. Mientras que los sistemas probados y la configuración exacta de pgbench difieren ligeramente, la prueba de Open Benchmarking confirma la cifra del 23% en el peor de los casos. Sin embargo, tres pruebas diferentes entre el núcleo 4.4 con KPTI desactivado y el soporte de PCID no presente con el núcleo 4.14 con KPTI y PCID muestran un aumento de rendimiento del 9,9% para carga normal, 6,0% para rosca simple y 17,95% para contención pesada. Mientras que los puntos de referencia indican absolutamente una regresión de rendimiento para las actualizaciones laterales del núcleo, la actualización al núcleo más reciente elimina las penalizaciones de rendimiento en esta situación.
Este efecto no se limita a PostgreSQL. Comparaciones similares para las Redis muestran un aumento del 30% en el desempeño del GET y un aumento del 33,5% en los puntos de referencia del SET.
VER: Importante rediseño de Linux para solucionar el problema de seguridad de Intel (ZDNet)
Sin embargo, no todos los casos de uso ven un aumento en el rendimiento cuando se pasa de un núcleo 4.4 inseguro a un núcleo 4.14 seguro. Renderizar en Blender, así como compilar Apache o el núcleo de Linux sólo muestra diferencias marginales, mientras que el servidor de páginas estáticas en Apache es aproximadamente un 20% más lento, aunque la aplicación de KPTI sólo muestra una penalización de rendimiento del 5% – como tal, los núcleos más nuevos parecen tener una regresión de rendimiento por otras razones. Con PostgreSQL, Linux 4.14 en general es el más rápido en este punto de referencia de la base de datos, y esta es una de las cargas de trabajo de E/S en las que el Aislamiento de tablas de páginas del kernel causa un aumento del rendimiento. Pero el rendimiento relativo para los tres núcleos probados con KPTI activado/desactivado era casi el mismo, sin que el rendimiento fuera significativamente diferente en los núcleos más antiguos que carecían de optimizaciones de PCID.
Como visión general, Linus Torvalds sugirió que las penalizaciones por rendimiento deberían ser de alrededor del 5%.
Nuevas medidas contra el deshielo y el espectro
Para combatir las fallas del chip, Google ha anunciado su solución propia Reptoline, que requiere recompilar el sistema operativo y las aplicaciones y puede ejecutar código no fiable. Este arreglo, junto con una actualización de microcódigo de Intel que introduce la especulación restringida por rama indirecta (IBRS) para Skylake y los procesadores de serie más nuevos, puede defenderse contra ambas variantes de Spectre. Reptoline ya ha sido implementado en la plataforma Google Cloud Platform.
Asegurando el futuro de la industria del cloud computing
Dado el creciente número de ataques de escape de la VM, como el ataque VENOM de alto perfil de 2015, así como las vulnerabilidades descubiertas el año pasado en los productos Hyper-V y VMware, es necesario aumentar las medidas de seguridad para mantener la confianza en la computación en nube. Todavía hay medidas que se pueden tomar. Según Rob Szumski, jefe de producto de Tectonic en CoreOS:
Boletín informativo de consejotecnologico.com
Refuerce las defensas de seguridad de TI de su organización manteniéndose al día de las últimas noticias, soluciones y mejores prácticas en materia de ciberseguridad. Entregado los martes y jueves
¿Cuál es su opinión?
¿Ha descubierto algún grado de rendimiento medible después de parchear para Meltdown y Spectre? ¿Se está moviendo a nuevas versiones del kernel para mitigar posibles problemas de rendimiento? Comparta sus experiencias en los comentarios.