That noise was us knocking on wood.Doomsday Time
The worst-case scenario in a hypervisor-based hosted environment? Hyperjacking, where an exploit leads to a compromised platform, allowing criminals full access to all hosted guests on a given machine. In subverting the hypervisor, malicious software could easily disguise its presence from traditional security tools that reside in either hosted-OS partitions or on any software layer above the hypervisor.
The exploit situation is analogous to the threat of cloaked rootkits compromising a standalone server OS. If you own the hypervisor, you own all data traversing the hypervisor and are in a position to sample, redirect or spoof anything you please. Without some form of failsafe, guest OSes would have no way of knowing they're running on a compromised platform.
This is the stuff of nightmares when you're talking large-scale virtualization platforms that offer 10, 50, even hundreds of hosted servers running on a single piece of hardware. The potential risk for loss of control and revenue is enormous.
The answer is to maintain the integrity of the hypervisor while building in multiple fail-safes so hosted OSes can ensure they're communicating with an untainted hypervisor as a bridge to the underlying hardware and external connections. To run an unmodified OS outside Ring 0, the hypervisor must intercept "forbidden" Ring 0 instructions and emulate them elsewhere—without the guest OS recognizing what's going on. Silicon makers are looking to help here; for example, newer Intel and AMD chips targeting the virtualization market are able to insert a new privilege level beneath Ring 0. Both provide new machine code instructions that work only at Ring -1, intended to be managed by a hypervisor. In this way, a guest OS doesn't have to be modified, and the performance penalty from emulation is reduced.
