OSDev.org

Recent discussions around have made me wonder. How can you ever be really sure your code is not running in some kind of VM, no matter how low level that may be?

Let's say you developed some technique for figuring out if you are inside VMWare, Qemu, KVM [insert your favourite VM here] and that worked fine. How could you ever possibly know for sure that you are really in Ring 0 if your code was loaded by a boot loader which in turn was loaded by some unknown BIOS function via an INT 13?

AFAIC, if you loaded your code via an INT 13 you might as well assume you are in a VM of some kind because you absolutely no way of knowing if you are really in ring 0 or not.

If you had bothered to read the intel manual, you'd know that the ring 0 issue is disjunct from any hardware VMs. If you had bothered to google you'd find methods to detect the presence of VMs. If you had bothered to google you'd find methods to test if you're in ring 0.

And more annoyingly, you're still violating forum rules on every other post.

While there are methods that work with current VMs, the answer to the general question: "Can I always be 100% certain that my code is running on real hardware and not in some kind of VM/emulator/whatever?" is "no".

In Computer Science software and hardware are equivalent. It's theoretically impossible for a program to determine whether a particular function (the CPU, a peripheral, etc.) is being implemented in physical hardware or not. In practice, you could detect imperfections (e.g. different timing, bugs, etc.) in the emulation/virtualization and no current mainstream VM even tries to mask its presence, advertising itself in things like device vendor strings, device IDs, etc. However, a perfect, cycle-correct emulator would be impossible to detect.

Hypervisors do not typically expose virtualization extensions to the guest (nested virtualization), so one approach is to try and initialize VT-x/AMD-V. If you can't initialize virtualization, it might be because you are a guest. (Or maybe the CPU just doesn't support it.)

There is plenty of literature on virtualization attacks and defense, have you tried searching the web?

intx13 wrote:Hypervisors do not typically expose virtualization extensions to the guest (nested virtualization), so one approach is to try and initialize VT-x/AMD-V. If you can't initialize virtualization, it might be because you are a guest. (Or maybe the CPU just doesn't support it.)

That isn't really fool-proof anymore, as modern CPUs support nested virtualisation. I haven't tested it, but the CPU in my new computer is supposed to support this and VirtualBox gives me the option to enable nested virtualisation for the guest. Any malicious virtual machine host could easily expose this to the guest to fool any such detection methods.

More to the point, (proof-of-concept) malware along these lines has actually been written before: https://en.wikipedia.org/wiki/Blue_Pill_%28software%29. Furthermore, said malware took things a step further by (if I'm understanding the Wikipedia article correctly) swapping out the real machine for the virtual one while the operating system was running.

There's usually quite a bit of inaccuracy and inconsistency in emulated/virtualized environments. Looking at those things that are hard to implement either correctly or fast can reveal something. And then performing memory or port accesses on virtualized ranges vs non-virtualized can tell some more. E.g. port I/O always causes a VM exit on SVM/VMX (quite slow, thousands of cycles). Instructions with undefined results (e.g. shifts with too large shift count) may behave differently when they use memory operands in virtualized ranges vs non-virtualized (because the emulation/virtualization software may not implement this in the exact same manner as in the CPU and I know of 3 different implementations of shift instructions (2 for intel, 1 for AMD)). There are many ways in which you can get a high degree of assurance that your environment is actually a virtual/emulated x86 PC. Cycle-accurate and correct emulation/virtualization is impossible without sacrificing too much computing power (and, perhaps, memory), to the point that the whole things doesn't make any practical sense (other than being accurate and correct), with usability near zero (things are too slow, network stack timeouts, etc).

@alexfru: that may be true for heavily virtualised environments like VirtualBox, but in the case of the aforementioned malware there was a lot less virtualisation and a lot more direct pass-through between the guest system and the host hardware, with the virtual machine host intercepting only what is necessary to gather/alter the required data. On the other hand, the thread starter didn't really mention if he's talking about detecting intentionally hard-to-detect virtual environments (presumably malicious ones) or just ordinary virtual environments like VirtualBox. If the latter, using vendor strings in the system's hardware is a tell-tale sign and I believe (although I may be wrong about this) that Microsoft Windows and a lot of Linux distributions use this technique to detect when they are running in a virtual machine.

Isn't there a bit set somewhere that indicates a virtualized environment? I could've sworn I read something about that somewhere; I've been skimming Intel/AMD Docs and I can't find where I thought I saw that; does that sound familiar to anyone else?

Hi,

azblue wrote:Isn't there a bit set somewhere that indicates a virtualized environment? I could've sworn I read something about that somewhere; I've been skimming Intel/AMD Docs and I can't find where I thought I saw that; does that sound familiar to anyone else?

Yes - see this page from vmware that describes the "official" way of using CPUID to detect VMs. Some VMs don't support this (Bochs, Qemu), but a lot do (Xen, KVM, VMware).


Cheers,

Brendan

This thread reminded me of something I've been wondering about for a while; it's kind of a variation of a blue pill attack.

If a virus attacks a guest OS, is there anyway for it to "break free" of a virtual environment and attack the host OS?

Short answer: yes.

This year, the VENOM bug was discovered which could in theory be exploited to escape a QEMU, KVM, Xen or VirtualBox VM.

Long answer: in principle, no, unless there is a vulnerability in the virtual machine manager.