Meltdown, Spectre y Hana
No es la primera vez que un aviso de seguridad revela la vulnerabilidad de PC y servidores. En el caso de Meltdown y Spectre, sin embargo, muchos expertos serios en TI hablan de un GAU de seguridad porque, aunque la contención del peligro es y será posible, aún no se pueden evaluar sus efectos.
La diferencia con problemas de seguridad anteriores: Meltdown y Spectre no consisten en solucionar un "molesto" error de programación, sino en una decisión arquitectónica fundamental del diseño del procesador.
Los pasos de cálculo que el procesador ejecuta de forma opcional y predictiva no están igual de seguros y protegidos exhaustivamente que el código "oficial" del programa. Para que no se pierda tiempo esperando resultados intermedios, la mayoría de los procesadores multinúcleo modernos calculan posibles resultados a modo de "trabajo ocupado" en obediencia anticipada.
Se elimina lo que no se necesita. Lo que se necesita ya está listo. Por desgracia, esta tarea de diligencia anticipada se lleva a cabo en la "tierra de nadie" del procesador, donde se producen resultados correctos, pero con exclusión de todas las medidas de seguridad.
Futuros análisis mostrarán hasta qué punto la reparación de Meltdown y Spectre es urgente y necesaria, porque esta Security-GAU puede ser utilizada por maquinaciones criminales. Para un usuario de Hana, en cambio, se plantea una cuestión completamente distinta: ¿Afectará la "reparación" al rendimiento de la base de datos de Hana?
Derivado del conocimiento público sobre Meltdown y Spectre y las soluciones para eliminar la vulnerabilidad ya sea a nivel de BIOS o del sistema operativo, se puede ver que el rendimiento del procesador se reduce definitivamente.
La conocida revista de informática "Magazin für Computer-Technik" (c't) ya ha podido realizar algunas pruebas, que se publicaron en el número del 20 de enero de este año. El resultado resumido:
Con funciones ofimáticas sencillas, apenas se notará una caída significativa del rendimiento en el PC, con los juegos de ordenador puede ocurrir raramente, pero con comandos de entrada/salida muy intensivos, como los que se producen sobre todo en el entorno de las bases de datos, pueden observarse caídas claras y notables del rendimiento.
Hana es una base de datos de computación en memoria que depende predominantemente de la velocidad del procesador y del tamaño y la velocidad de las memorias caché y principal.
En teoría, por tanto, las medidas de reparación (parches) a nivel de procesador, incluido el BIOS (Basic Input/Output System) y a nivel de sistema operativo (Linux de Suse y Red Hat), pueden influir significativamente en el rendimiento global de la base de datos Hana.
Si la base de datos Hana se ejecuta en un entorno de sistema virtualizado (hipervisor), las medidas en un sistema VMware también son, por supuesto, decisivas.
Por lo tanto, el cliente existente de Hana debería encontrar respuestas en el mercado de servicios de SAP, que SAP ha desarrollado junto con sus socios Intel, IBM, Suse, Red Hat y VMware. Incorrecto - véase la captura de pantalla.
El silencio de SAP en el lugar donde el cliente existente busca primero consejo y ayuda es preocupante: ¿Acaso SAP no sabe o no quiere decir nada al respecto? ¿Qué peligro corren los sistemas Hana? ¿Por qué callan Intel e IBM, en cuyos procesadores funciona Hana?
Según los conocimientos actuales, Meltdown y Spectre tendrán un impacto en todas las bases de datos de computación en memoria. Esto significa que Hana (local y en la nube) es la principal afectada por este desastre de seguridad.
La situación actual es muy desagradable y preocupante para todos los clientes existentes porque SAP está intentando trasladar la responsabilidad a los fabricantes de servidores Hana certificados y a los proveedores de sistemas operativos, véase el texto de la nota SAP 2586312.
Nota SAP: 2586312
Linux: ¿Cómo protegerse contra las vulnerabilidades de ejecución especulativa? (Versión 3 del 19 de enero de 2018)
A principios de enero de 2018, se reveló un fallo de diseño en las CPU modernas. Al explotar este defecto de diseño, las aplicaciones de modo de usuario pueden obtener acceso a cualquier memoria física, incluso si la memoria está mapeada solo en modo kernel y, por lo tanto, no debería ser accesible. El fallo de diseño se manifiesta en varios errores, denominados Vulnerabilidades y Exposiciones Comunes. Estos fallos no pueden solucionarse en las propias CPU, sino que requieren actualizaciones tanto del microcódigo como del núcleo del sistema operativo. Las CPU afectadas son las más recientes y las más antiguas de Intel (Xeon) e IBM (Power), entre otras.
SAP recomienda encarecidamente seguir las recomendaciones y aplicar las actualizaciones proporcionadas por los proveedores de hardware, los proveedores de virtualización y los distribuidores de sistemas operativos, según corresponda. Estas actualizaciones pueden afectar al rendimiento del sistema. En los sistemas virtualizados, tanto el SO anfitrión como el SO invitado deben ser parcheados y ambos pueden afectar al rendimiento. La gravedad de la regresión del rendimiento depende de la carga de trabajo y del tipo de CPU. En los sistemas virtualizados, tanto el SO anfitrión como el invitado pueden verse afectados.
Póngase en contacto con el proveedor de su servidor. Busque una actualización de la BIOS que incluya parches de microcódigo para los errores reales de la CPU. Varios servidores pueden requerir una desconexión completa de la alimentación después de ciertas actualizaciones de la BIOS que incluyen un nuevo microcódigo. Consulte la guía de instalación de la actualización de la BIOS.
Póngase en contacto con el distribuidor del sistema operativo.
Instale los parches necesarios y reinicie su host.