Microsoft swallows the BluePill

Why doesn't Microsoft want users to run Vista in a VM? Why, because the presence of a VMM could mean someone has l33tly r00t3d your b0x0r! So nice of Microsoft to protect us shivering, ignorant, childlike customers from choosing how we'd like to run Windows. Ahh, the bliss of having all my decisions made for me. Thank you. I wonder if I should be just as worried about the inherent insecurity of running on a hypervisor once Longhorn ships? Oops, I almost forgot: best not to think of these things! Better to let Microsoft do the worrying for me.

Now that the BluePill pseudo-sploit has been widely publicized for over a year now, I'm still aware of no actual attacks. This, despite the fact that SVM and VT hardware are now extremely common, and getting more so by the day. Why would that be?

Well, first of all, SVM and VT make possible nothing that was not already possible before; VMware's software-only products are an existence proof. The BluePill-istas don't claim that SVM/VT make new exploits possible per se; rather, the claim is that SVM/VT make it possible to cloak the presence of a VMM rootkit completely.

Allow me to go on record: this claim is pure fantasy. In practice, it is always possible to detect the presence of a VMM, via timing attacks. "Aha!", my hand-wringing BluePill interlocutor exclaims: "But the VMM lets us hook RDTSC and the PIT and the APIC timer, etc., so we can show the VM whatever time we want! Or whatever!" The details of getting such an approach right in practice are tough beyond belief. Once you start thinking it through, you quickly realize the deck is stacked in favor of the would-be VMM detector. As a practical example, VMware's software goes to extremely clever lengths in coordinating and manipulating the various virtual time sources just to get certain versions of the linux kernel to boot. It took some smart people years to really drive a stake through the heart of the "pester mingo" boot-time failure in SMP VMs. This was the result of a real, naturally occurring guest code that had nothing to do with VM detection; you can imagine that a dedicated attack on the VMM's virtual time sources could be many orders of magnitude more effective.

So, I'm claiming you can always find out that there's a VMM underneath you. Should that worry us, too? Since some members of the security community are using VMs to study malware, the arms race between malware creators and investigators has temporarily taken a turn wherein some malware refuses to run in a VM. This has led some to think of the detectability of a VMM as a deficiency in the virtualization layer.

I don't see it that way. As VMs become more commonplace, malware that refuses to run in VMs will be naturally selected out. We don't expect, e.g., a Dell laptop to cloak the version of Windows it's running, or which chipset or video card is present, or for that matter which version of Windows is running. It's perfectly legit for software to query these aspects of its execution environment, having an orderly way to enumerate and version them is a valuable thing. As VM proliferation progresses, I suspect that we will come to think of VMMs in the same way: as another facet of the stack of hardware and software on which you happen to be running, whose presence is neither surprising nor secret.