En Meltdown and Virtual Machines se aclaró que al menos Specter trabaja cruzando VMs . Esto, por supuesto, significa que el hipervisor debe estar parcheado, pero
¿Debería parchearse también el sistema operativo VM?
Al no ser CPU reales, no está claro si son directamente vulnerables a los ataques basados en la captación previa, o si el parche del hipervisor es suficiente.
En primer lugar, tengo entendido que el parche del sistema operativo / hipervisor solo mitiga el Meltdown, no Specter.
Segundo, parchea el hipervisor para evitar que una VM lea la memoria que pertenece al núcleo del hipervisor. Usted parchea el sistema operativo invitado para evitar que un proceso lea la memoria que pertenece al núcleo del sistema operativo invitado. Mi entendimiento es que son independientes el uno del otro; parchear uno no tiene efecto en el otro.
Emulación vs virtualización
No soy un gran experto en tecnologías de virtualización, pero su pregunta se sumerge en la emulación frente a la virtualización : en la emulación, la CPU, incluyendo todos los registros, cachés, etc., está completamente simulada en el software y puede usar un conjunto de instrucciones diferente al hardware subyacente. En la virtualización, las instrucciones se pasan directamente al hardware, pero con una programación de procesos adicional impuesta por el hipervisor. En particular, mi comprensión de virtualización x86 , específicamente La tecnología VT-x de Intel , es que se trata de una" CPU real "en el sentido de que el sistema operativo invitado está utilizando instrucciones x86 reales que son más o menos aprobadas. directamente a través del hardware subyacente.
Entonces, sí, el sistema operativo invitado será vulnerable a Meltdown y requerirá la aplicación de parches independientemente de si el hipervisor ha sido parchado.
Acabo de probar en una máquina virtual desechable utilizando el código de prueba de concepto de SpectrePoC (que se basa en Ataques de espectros: explotando ejecuciones especulativas , y funcionó, en el sentido de que afirmaba poder explotar el sistema. Definitivamente recomendaría parchear los núcleos de invitados de máquinas virtuales así como el núcleo host.
Basado en la información publicada QEMU, el kernel de invitado debe actualizarse y reiniciarse después de el hipervisor inserta el nuevo CPUID y los registros de la máquina. Esto aborda uno de los problemas de Spectre. Lamentablemente, QEMU aún no ha lanzado el parche de origen asociado en este momento, se espera que esté en su versión 2.11.1, por lo que es posible que deba reiniciar su VM nuevamente después del parche si se ejecuta en QEMU. El kernel invitado debe reconocer el nuevo CPUID / MR y reaccionar adecuadamente. Es posible que otros hipervisores (y proveedores de la nube) ya hayan proporcionado estos cambios, pero aún se requiere el nuevo núcleo para proteger el sistema operativo invitado de aplicaciones maliciosas.
Lea otras preguntas en las etiquetas virtualization meltdown spectre virtualhost