5

Question

I know that Vmware hypervisors at least have a setting to ignore CPU microcode updates from within the guest OS (no surprise).

CPU microcode update available. The guest OS tried to update the microcode from patch level XX (YYh) to patch level ZZ (TTh), but VMware ESX does not allow microcode patches to be applied from within a virtual machine. Microcode patches are used to correct CPU errata. If you are not experiencing any problems with your CPU, you can ignore this microcode patch. Otherwise, you may be able to obtain a BIOS/firmware update which includes this microcode patch from your system vendor, or your host OS may provide a facility for loading microcode patches obtained directly from the Intel web site.

https://kb.vmware.com/s/article/1028290

Is this the case with all hypervisors (like KVM, where a Virtual Qemu CPU gets presented) or is there maybe a setting for Vmware Vsphere where the detected microcode update from the guest machine gets staged to be used by the hypervisors microcode loading mechanism (e.g. when the microcode is authentic and the version is newer than the installed microcode)?

Assumptions

  1. No guest machine may ever upload microcode to the hypervisor's CPU except when the microcode is specific for a virtualized CPU. But then again, what use would it have? The hypervisor's code could also be updated to just change the virtual CPU.

  2. Spectre needs to be mitigated on Hypervisor level and thus needs proper Bios firmware and/or microcode uploads by the Hypervisor. Microcode cannot be fixed via the guest os.

Background

Red Hat withdrawed microcode updates related to Spectre and virtual machines try to upload microcode during boot.

Mon Jan 15 2018 Petr Oros - 1:1.17-25.4 Use right upstream source for revert Resolves: #1533978

Fri Jan 12 2018 Petr Oros - 1:1.17-25.3 Revert Microcode from Intel and AMD for Side Channel attack Resolves: #1533978

Changelog of the microcode_ctl RPM

Improve this question

1 Answer 1

Reset to default
7

Yes, hypervisors (the ones which aren't unusually broken, at least) will always refuse microcode update access from guests (VMs). Any microcode updates must be delivered either by the hypervisor itself, or by system firmware/boot-loader.

The reason for this is the most obvious: security. A microcode update can change visible details of the ISA (instruction set architecture), and disturb the whole system, up to and including crashing other VMs that were not prepared for the ISA changes, etc (refer to the Intel TSX microcode fix that removed the Intel TSX-NI instructions for an example).

Also, there are microcode-update-level attacks, and those, when successful, will bring down the entire system. Thus, one VM could crash the hypervisor and all other VMs. Refer to the Inertiawar paper on Intel microcode updates for an example.

Also, an hypervisor might expose to the guest a different, sometimes synthesized CPU model, than the one it is really running at. The guest has no business trying to update the microcode of such a CPU.

Microcode updates are, therefore, an attack surface all hypervisors worth something will close down.

Improve this answer
3
  • 2
    That's how it is supposed to be. Do you have references that can back that up?
    – Gerald Schneider
    Feb 2, 2018 at 10:07
  • The Intel TSX-NI visible change is well-known, here's one example. From: bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195 : "Updating the microcode on these Intel Haswell processors when Intel TSX is in use by libpthread will cause running processes linked to libpthread to be killed with SIGILL." For the inertiawar disclosure, it is best if you search for it yourself.
    – anonymous
    Feb 2, 2018 at 15:22
  • 1
    @anonymous I look at the bug report... and I don't see hypervisors neither VM. So it is an example about microcode update side-effects, but not in strong relation with the question.
    – Massimo
    Oct 2, 2018 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .