Can Operating Systems tell if they're running in a Virtual Machine?

Or, do androids know they're dreaming of electric sheep...

There was some recent news on Windows Vista EULA restrictions relating to Virtual Machines. Vista Home Editions aren't allowed to be run inside a Virtual Machine, and Vista Ultimate in a VM will restrict access to applications which use DRM. We're still waiting for clarification from Microsoft, but it seems like the popular interpretations are basically right.

This raises the question - is this a EULA restriction, or is it going to be enforced. Can it be enforced? Can an operating system tell if it's running in a Virtual Machine?

That's really two questions:

  1. Can Operating Systems currently detect if they're running in a VM?
  2. Will Operating Systems always be able to detect if they're running in a VM?

Well, I only know what I read. Let me know if you disagree...

Can Operating Systems currently detect if they're running in a VM?

Yes, they can. Right now they do it through a couple of techniques - direct hardware fingerprinting and inferred hardware fingerprinting.

Direct hardware fingerprinting is pretty straightforward. Virtual Machines have predictable hardware profiles, so you can just query for "virtual hardware" that's only available in VM's and can't easily be changed. The Virtual PC Guy describes this approach here:

The easiest way to detect that you are inside of a virtual machine is by using 'hardware fingerprinting' - where you look for hardware that is always present inside of a given virtual machine.  In the case of Microsoft virtual machines - a clear indicator is if the motherboard is made by Microsoft... [WMI Script to check the motherboard vendor]
If the motherboard is made by "Microsoft Corporation" then you are inside of one of our virtual machines.

The inferred hardware fingerprinting approach is a bit more dodgy. It works by making direct machine level calls to the virtualized CPU that will reveal if the CPU is real or virtual. Some of these call instructions that the VMM's don't currently support. Others make system calls that will only succeed on specific virtual hardware, usually because of special machine calls the VM's implement to allow communication with the host OS and optimize use of host OS resources (e.g. the Virtual Machine Additions for Virtual PC / Virtual Server , or VMWare's VMware Command Line Tools). This kind of stuff is pretty slick, but it makes "undocumented system calls" look boring.

Here are some examples of indirect hardware fingerprinting:

Of course, this approach is subject to the whims of each VMM release, and it may vary from host OS to host OS.

These two approaches remind me of the two ways to target CSS to different browsers - ask them nicely, or beat it out of them.

Will Operating Systems always be able to detect if they're running in a VM?

Of course, that's not a question I can answer with certainty until I can get my hands on a flux capacitor and 1.21 gigawatts. That won't keep me from speculating, though...

Let's step back a second and think about whether or not we want Operating Systems to know if they're running in a virtual environment. In the context of the recent Vista EULA flap, we might want to say no - the EULA restriction is stupid, and it's a good thing that they can't enforce it.

But let's talk about The Blue Pill. It's a theoretical malware application of VM technology in which a rootkit consumes the host operating system and runs as a hypervisor (a hardware virtual machine manager). Once it's done that, it can do whatever it wants without the operating system knowing it's been compromised:

The idea behind Blue Pill is simple: your operating system swallows the Blue Pill and it awakes inside the Matrix controlled by the ultra thin Blue Pill hypervisor. This all happens on-the-fly (i.e. without restarting the system) and there is no performance penalty and all the devices, like graphics card, are fully accessible to the operating system, which is now executing inside virtual machine. This is all possible thanks to the latest virtualization technology from AMD called SVM/Pacifica. [via invisiblethings.blogspot.com]

It's mesmerizing and scary at the same time, kind of like BooBah. There's some doubt as to whether it's code or just talk at this point:

However, there is great doubt throughout computer security circles as to whether blue pill is real or a mere stunt, since details and a working sample of the source code have not been made available, contravening the industry wide standard of full disclosure. [via Wikipedia]

Regardless, the concept has been validated. Microsoft Research and a group from University of Michigan proposed SubVirt (pdf), a VMM rootkit, in May 2006. Their paper is a fascinating schizophrenic game of cat and mouse: well, you could detect this by blah, but then we could zhoop, and even if you flurped we could just breeble. The SubVirt rootkit doesn't take advantage of hypervisor technology and requires a reboot, but on the other hand it seems to be more mature.

We built VMBRs (Virtual Machine Based Rootkits) based on two available virtual-machine monitors, including one for which source code was unavailable. On today’s x86 systems, VMBRs are capable of running a target OS with few visual differences or performance effects that would alert the user to the presence of a VMBR. In fact, one of the authors accidentally used a machine which had been infected by our proof-of concept VMBR without realizing that he was using a compromised system! [Subvirt paper pdf]

The point remains, though - we probably want our operating systems to know if they're running on virtual machines. It sounds like they should always be able to do that. Anthony Liguori, and IBM software engineer who has worked on the Xen hypervisor for two years, says:

Hardware virtualization requires a technique know as "trap and emulation". The idea is that the hardware traps certain instructions and the VMM emulates those instructions in such a way as to make the software believe it is running in a virtual machine. Software emulation implies that these instructions take much longer to complete when executed under a VMM then on normal hardware. This fact is what can be used to detect the presence of a VMM. [via virtualization.info]

You may have noticed that I jumped from talking about software VMM's (VMWare, VirtualPC) to both software and hardware VM rootkits. From what I've read, it looks like this is going to be a cat and mouse game, but the VM rootkits will always need to deal with the timing issues that Anthony mentioned. The SubVirt authors discussed this, too:

A VMBR adds CPU overhead to trap and emulate privileged instructions, as well as to run any malicious services. These timing differences can be noticed by software running in the virtual machine by comparing the running time of benchmarks against wall-clock time. A VMBR can make the detector’s task more difficult by slowing down the time returned by the system clock, but the detector can overcome this by using a clock that can be read without interference from the VMBR (e.g., the user’s wristwatch). [Subvirt paper pdf]

Well, I hope we can do better than wristwatch checks. I'd hope that an OS could check the time of day once an hour and notice a 1% drag due to VM hosting, or at least pick it up over the course of a full day. Not great, but at least it'd be detectable.

There's one more secret weapon against bad VMM's. It's probably the best defense, but you probably aren't going to like it. I'm talking about the TPM, the Trusted Platform Module. Microsoft's Next Generation Secure Computing Base Digital Rights Management (DRM) technology (called Palladium back when Vista was Longhorn) ran on the TPM. Trusted computing works by using a hardware crypto chip which verifies hardware and software loaded by the hypervisor (which runs above the hardware virtualization layer, which runs above the good old CPU's... sheesh, this is getting complicated...).

It's as if an OS running on a Trusted Computing platform was using HTTPS (SSL) to talk to hardware and trusted software like DRM software, but with much stronger crypto. That's a good thing from the point of view of safeguarding against rootkits. It's bad news if you want to use software that works by virtualizing hardware (such as virtual soundcards which record streaming music like TotalRecorder, or virtual DVD drives which let you read ISO images like Daemon Tools or Alcohol 120). It's also bad news if you want full access to DRM protected content, since DRM processing protected by a TPM is quite a bit more robust than the flimsy DRM stuff they're using today. DRM'd media running on a Trusted platform could be sent from disk to soundcard with the same kind of anti-tampering assurance you'd expect when you connect to your bank's website across the big, bad internet. Hmm. Well, we've got a little while to think this through, since it's mostly been removed from Vista and won't ship until future versions of Windows.

16 Comments

  • If viruses or trojans employed VM tecniques and because sophisticated enough where they could only be defeated by strong TPM based crypto, this would be a strong incentive for consumers to adopt TPM despite DRM and other anticompetitive qualities of TPM. Will virus writers drive consumers into the hands of the RIAA and other media monopolies? Is this a strategy that might be used to force the adoption of TPM?

    In the process of swallowing the red pill, we might all be trapped in the TPM matrix.

  • No, we won't. None of the so-called "TPM" features are necessary to detect or prevent hypervisor infection.

  • Try starting up a virtual machine! I don't think you can nest them.

    Try poking at stuff like the self-test modes in the network hardware, and the timing registers in the video card. If you put the process in real-time mode, you will get all of the real machine so you can run an idle loop, count the iterations, look at the video timing (or you can talk on the network to a known clock source), and see if they correspond.

    The clock cycle timing will be very elastic in a virtual machine, if the VM manager is not giving all the real machine's cycles to the VM, the VM should be able to detect that.

    A counter measure would be to emulate crufty old hardware that doesn't have any of the features mentioned above.

  • Why the hell do they care if these systems running on virtual machines??????????

  • @Anonymous, you'll actually have to read the post to find that out. Some reasons include "virus" virtual machines that swallow your entire operating system so they're completely undetectable and operating system restrictions on virtual machine usage.

  • Mmmm... monkey spaghetti.

  • Of course that they can know when is runned on a Virtual Machine, because Virtual Machines uses certain logic devices, when you install windows, and the windows recognize that device automatically knows that is a virtual machine.

  • Victor, your comment makes no sense. You need to understand my sources (see link) before you post a reply.

  • Im refer to this

    Direct hardware fingerprinting is pretty straightforward. Virtual Machines have predictable hardware profiles, so you can just query for "virtual hardware" that's only available in VM's and can't easily be changed. The Virtual PC Guy describes this approach here:

    "The easiest way to detect that you are inside of a virtual machine is by using 'hardware fingerprinting' - where you look for hardware that is always present inside of a given virtual machine. In the case of Microsoft virtual machines - a clear indicator is if the motherboard is made by Microsoft... [WMI Script to check the motherboard vendor]
    If the motherboard is made by "Microsoft Corporation" then you are inside of one of our virtual machines."

    THIS IS ON YOUR ARTICLE, SO MY COMMENT HAVE SENSE.

  • @Spencer - It's a bigger question than license enforcement. For example, the article discussed the problem of malware which acts as a Virtual Machine Manager (VMM) and is thus invisible to virus detection because it's running at the virtual hardware level, as if your CPU or motherboard were infected.

  • @Victor - That's fine if you trust the VMM manufacturer (Virtual PC, Virtual Server, VMWare, Xen, etc.). What if the VMM doesn't want to be detected and reports the motherboard manufacturer is "Intel"? How would WMI help then?

  • Can Operating Systems tell if it runs under which VVM (e.g Xen, Vware..etc)?

  • I know this blog is old (came across it in google search for a check for amd-v extensions), but the statement is made regarding whether an OS can tell if it is running ina VM and this statement was made "...It works by making direct machine level calls to the virtualized CPU that will reveal if the CPU is real or virtual." Just a point, currently I don't know if any virtualization platforms, VMware, MS (formally Connectrix), Parallels, etc that virtualize the CPU, the CPU is directly accessed by the VM and is not virtualized.

    In emulators, that may be the case, but in virtualization, only the various hardware like NICs, disk controllers, etc are virtualized and that is the key to detirming if an OS is running within a VM.

    Now, if you don't install the various tools or enhanced vitual hardware, it is harder to detect. For example, in VMware, the default NIC before tools are installed is an AMD PCNET adapter so if you query that, you don't know if you are talking to an actual PCNET adapter or a virtualized one. When I check, in scripts, I simply check for the VMware name string at various places and the first place is the VMware Tools service.

  • of course. the first byte of the CPUID is 0xff.
    been that way since, oh, about 1967.
    or were you talking about them newfangled naked mini thingies?

  • The question is a fundamental computer science question referred to as the halting problem posed by Alan Turing. To be clear, his theory actually states the inverse of the question "Is it possible to fool an OS into running on a VM?". The halting problem implies it is impossible to write an algorithm for a program that checks if other programs are running correctly. In other words, programs can always be fooled.

  • Hi All, nice discussion! I can not find all the source codes, does someone collects them?

    And another question, is it possible to nest VMs? If not, am i safe when installing my own hypervisor, ring -1 is then already taken.

Comments have been disabled for this content.