Can a hypervisor rootkit enable hardware-assisted virtualization when it has been disabled by the BIOS?

Question

I was recently reading An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits (PDF), and it wasn't entirely clear about the conditions under which the hypervisor rootkit can start virtualization. If virtualization is enabled then everything is fine, but what happens if virtualization is disabled?

Specifically, does either Intel VT-x or AMD-v (VMX and SVM) support unlocking and enabling HAV after the BIOS (or a later hypervisor) has disabled and locked it? I am not interested in modifying the BIOS or changing its settings, purely in whether a hypervisor can change these settings.

(If anyone is wondering: No, I am not planning on creating a malicious rootkit :P)

Answer 1

To quote the Intel Software Manual, Volume 3c:

VMXON is also controlled by the IA32_FEATURE_CONTROL MSR (MSR address 3AH). This MSR is cleared to zero when a logical processor is reset. The relevant bits of the MSR are:

• Bit 0 is the lock bit. If this bit is clear, VMXON causes a general-protection exception. If the lock bit is set, WRMSR to this MSR causes a general-protection exception; the MSR cannot be modified until a power-up reset condition. System BIOS can use this bit to provide a setup option for BIOS to disable support for VMX. To enable VMX support in a platform, BIOS must set bit 1, bit 2, or both(see below), as well as the lock bit.
• Bit 1 enables VMXON in SMX operation. If this bit is clear, execution of VMXON in SMX operation causes a general-protection exception. Attempts to set this bit on logical processors that do not support both VMX operation (see Section 23.6) and SMX operation (see Chapter 6, “Safer Mode Extensions Reference,” in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B) cause general-protection exceptions.
• Bit 2 enables VMXON outside SMX operation. If this bit is clear, execution of VMXON outside SMX operation causes a general-protection exception. Attempts to set this bit on logical processors that do not support VMX operation (see Section 23.6) cause general-protection exceptions.

Interpretation, for those who aren't au fait with what's going on here:

• MSR stands for machine specific register and refers to registers / configuration settings that alter between implementations of the x86 architecture.
• Some of these are used to configure features for that family of processor.
• VMXON is the (Intel) x86 instruction to enter hypervisor management mode - the point where you get access to hardware assisted virtualisation features including extended page tables, etc. Here, you create virtual machines and execute vmenter and vmexit and so on.
• A general protection exception is an exception handler built into the processor that occurs when you do something you're not allowed to do. Examples would include executing privileged instructions outside of a privileged level, e.g. the sidt instruction as a user mode application (ring 3).

As you can see from the documentation, BIOSes have a choice to enable or disable VMX and also may use the lock bit; if the lock bit is set any attempt to write to alter the configuration will cause a GP exception.

So it really depends how those bits are set by your BIOS, in answer to your question. If the BIOS sets all of the bits to 000, then software ought to be able to enable the hypervisor via WRMSR - see the discussion here. I think WRMSR is a privileged instruction, meaning you'd need to do it from the kernel. However, once the lock bit is set, you're required to reboot - essentially the circuitry will check the state of the reset flag, then throw an exception at your operating system - which can either carry on as normal or crash, depending on whether it understands the exception (most likely not).

Answer 2

It fully depend if the virtualization can be enabled or not by the OS. While I may be wrong, i can imagine that using some specific syscall, you can reflash a BIOS from a OS running. There is some motherboard that permit it on Windows, there is the flashrom tool who permit that on Linux.

So then someone could reflash the firmware to have virtualization enabled by default, and wait for reboot.

Regarding if this can be done without reboot, I do not know. I would recommend to take your processor documentation, and try to see if there is information on this.

Of course, if you can reflash the firmware/BIOS, then you can directly place a rootkit there, and this point is addressed by UEFI if I am not wrong ( but not in a way that would satisfy everybody, especially in the free software side ).

Answer 3

No, since the CPU provides the hypervisor access to the root mode below ring 0. See page 6 of this VMware whitepaper.

Also see this Linux KVM article:

If your hardware doesn't have an IOMMU ("Intel VT-d" support in case of Intel - "AMD I/O Virtualization Technology" support in case of AMD), you'll not be able to assign devices in KVM. Some work towards allowing this were done, but the code never made it into KVM, due to various issues with the code. At the moment it doesn't seem like device assignment without hardware support, will ever be integrated into KVM.