6

Is it safe to assume that it's impossible for CPU Microcode updates and firmware updates to be initiated from a guest VM?

What software or hardware technologies protect my guest OS from altering or editing these or other firmware that may exist in the system?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 2
    If you're using virtualisation extensions such as VT-x or AMD-V, your CPU can already tell when virtualised code is executing and prevent such updates. I'd imagine the interrupts required would be passed to a virtual interrupt handler, rather than processed directly by the physical CPU. – Polynomial Nov 29 '12 at 23:32
  • 1
    What Polynominal said, I'm quite sure that those instructions are ring 0, VMs run in ring 3 – Hubert Kario Nov 30 '12 at 00:15
  • 1
    @HubertKario It's still possible for VMs to run privileged (ring 0) instructions - they're just handled by the VM software rather than the physical CPU. What they _actually_ do depends on the implementation - I can imagine some VMs using ring 0 drivers to service them, which may pose some potential issues. This is all guesswork though, since we don't really know how most virtualisation products handle this kind of thing. – Polynomial Nov 30 '12 at 06:52
  • @Purge I've reverted your edit - "virtualisation" is the correct spelling in British English, which is perfectly acceptable here. – Polynomial Nov 30 '12 at 14:44

1 Answers1

3

Yes, I think it is safe to assume that a VM will prevent guests from updating the CPU microcode of the physical CPU.

Updating the microcode on an Intel CPU involves executing the WRMSR instruction, with MSR 0x79. This is a privileged instruction, and can only be executed when the CPU is in privileged mode (CPL=0).

The virtual machine monitor (VMM) should trap on all privileged instructions, including this one, and take appropriate steps to emulate it. While I haven't checked the code of any VMM, I would expect a reasonable VMM might refuse the update, or might ignore it, but no reasonable VMM should allow a guest to update the microcode of the physical CPU that the host is running on. It would be pretty surprising for a VMM to allow a guest to request a microcode update and to actually execute that request on the host CPU.

Updates to firmware of other hardware peripherals is a trickier question. The answer will depend upon how the VMM manages access to that hardware device.

If the hardware device is emulated or virtualized, then a reasonable VMM should prevent a guest from loading firmware updates into the device (in a similar way: loading a firmware update requires I/O to interact with the device, and a VMM should restrict I/O with the device).

However, if the VMM provides the guest with unrestricted direct access to the hardware device (i.e., direct assignment of the device to that guest), then I suspect that the guest might be able to load firmware updates, if the device permits it.

The virtualization strategy for hardware devices will be dependent on the specific VM you use; some VMs use emulation or virtualization, but some may also use direct assignment in some cases. I am not an expert on this subject and cannot speak authoritatively about it. If you are concerned, choose a VM that provides full virtualization or emulation of all devices, and does not use direct assignment to give a guest direct unrestricted access to any hardware peripheral.

References:

See the Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 3A , Section 9.11.6, for a description of the procedure for loading CPU microcode updates, and Section 9.11 for CPUmicrocode updates generally.

D.W.
  • 98,420
  • 30
  • 267
  • 572