Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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)

share|improve this question

migrated from stackoverflow.com Jun 1 '12 at 21:03

This question came from our site for professional and enthusiast programmers.

2  
(If anyone is wondering: No, I am not planning on creating a malicious rootkit :P) Coincidentally, that's exactly what someone creating a malicious rootkit would say. Just saying... –  Moses Jun 6 '12 at 22:56

3 Answers 3

up vote 6 down vote accepted
+50

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).

share|improve this answer
    
I read that manual but I think I didn't understand the first point you quoted. It took me a few reads of your answer as well but I think I got it: the 001 state means you're out of luck, whereas anything else means it's either enabled or can be enabled without a reboot. Thanks very much. I would assume this is similar for AMD. –  Matthew Read Jun 6 '12 at 18:15
1  
@Matthew always takes me a few parses through these things :) yep basically, sounds like it - once the lock bit is set, tough, whatever state you've got is what you've got until reset. If not, open season. –  user2213 Jun 6 '12 at 18:18

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 ).

share|improve this answer
    
This is an entirely different problem. I'm asking whether the hypervisor can enable HAV normally, not whether you can flash a new BIOS. (Which is indeed possible, but I don't think feasible in the general case since you'd need so many different BIOSes for different motherboards. CPUs are more standardized, at least in the aspects relevant here.) –  Matthew Read Jun 1 '12 at 22:49
    
Well, there is no standard programming or documented interface to change BIOS settings afaik, but maybe some BIOS have it. The same goes for virtualization. And changing BIOS settings is just writing some bytes in the BIOS flash memory, so is flashing the BIOS, ie that's the same process, just on different memory address, hence my answer. Now, if that for the processor, I doubt. The main usage was to sell the same hardware but cheaper without HAV and to block this in BIOS, so I assume you cannot bypass the BIOS for that. –  Misc Jun 1 '12 at 22:54
    
No, there are absolutely standard and documented ways to enable and disable VMX and SVM. I am not asking about the BIOS, at all. I'll edit my question to attempt to make that clearer. –  Matthew Read Jun 1 '12 at 23:23

If I understand your question correctly, no since the CPU provides the hypervisor access to the root mode below ring 0:

See page 6 - http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf

Also see below:

"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."

http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM

I hope this helps.

Brian

share|improve this answer
    
I'm not sure how "no" follows from the hypervisor running in Ring -1, or how VT-d is relevant ... can you explain further? –  Matthew Read Jun 6 '12 at 18:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.