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
-
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.
-
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: #1533978Fri 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
Best Answer
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.