14

In Meltdown and Virtual Machines it was clarified that at least Spectre works crossing VMs. This of course means that the Hypervisor must be patched, but

Should the VM OS be patched as well?

Not being real CPUs it is not clear if they are directly vulnerable to attacks based on prefetch, or if patching the Hypervisor is enough.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
Envite
  • 261
  • 2
  • 6

3 Answers3

16

My understanding, first off, is that the OS / hypervisor patch only mitigates Meltdown, not Spectre.

Second, you patch the hypervisor to prevent a VM from reading memory belonging to the kernel of the hypervisor. You patch the guest OS to prevent a process from reading memory belonging to the kernel of the guest OS. My understanding is that they are independent of each other; patching one has no effect on the other.

Emulation vs Virtualization

I'm not a great expert on virtualization technologies, but your question dips into emulation vs virtualization: in emulation the CPU, including all registers, caches, etc. is fully simulated in software and it may use a different instruction set from the underlying hardware. In virtualization, the instructions are passed directly to the hardware, but with extra process scheduling imposed by the hypervisor. In particular, my understanding of x86 virtualization, specifically Intel's VT-x technology, is that it is a "real CPU" in the sense that the guest OS is using real x86 instructions that are more-or-less passed straight through to the underlying hardware.

So yes, the guest OS will be vulnerable to Meltdown and require patching independently of whether the hypervisor has been patched.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Surely it should be possible to get real data. Like try a meltdown and a spectre type exploit from within a VM where the kernel inside the VM is unpatched but the hypervisor outside is patched. – Warren P Jan 07 '18 at 03:51
  • @WarrenP I'm not set up to try that, but if there's a link to testing like that, it would make a great follow-up answer. – Mike Ounsworth Jan 07 '18 at 04:08
4

I just tested on a throwaway VM using the proof of concept code from SpectrePoC (which is based upon Spectre Attacks: Exploiting Speculative Execution, and it worked, in that it claimed to be able to exploit the system. I would definitely recommend patching virtual machine guest kernels as well as the host kernel.

Ben Stern
  • 141
  • 4
3

Based on the information QEMU posted, the guest kernel needs to be updated, and rebooted after the hypervisor inserts the new CPUID and Machine Registers. This addresses one of the Spectre issues. Alas, QEMU has not yet released the associated source patch as of this writing, expected to be in their 2.11.1 version, so you may need to reboot your VM again after that patch if running on QEMU. The guest kernel should recognize the new CPUID/MR and react appropriately. Other hypervisors (and cloud providers) may have already provided these changes, but the new kernel is still required to protect the guest OS from malicious applications.

NaperJ
  • 31
  • 1