Virtual Machine Security (or false trust offered by VMMs)

by Stephan Mueller

Everybody is chattering about virtual machines and their security these days. And every vendor, analyst, and government agency gives a number of suggestions on how to secure virtual machines, but what are the intended goals set forth by the different interest groups for achieving secure virtual machines? Let us try to enumerate them:

• full separation between virtual machines, so that the operation of one virtual machine cannot affect the operation of another or the host system or hypervisor
• limited access to resources to the virtual machine the administrator intends to grant access
• secure administration of the virtual machines, including protection of the console access to the different virtual machines

To reach these goals, all parties indeed achieved a number of successes. Current virtualization implementations try to fully implement the given goals. These implementations use hardware support (such as Intel VT-d, the PowerPC hypervisor mode, or the SIE instruction on IBM System z machines).

However, there is one big issue that none of the virtualization implementations seem to address appropriately: providing a computing environment to guest system that behaves exactly like the hardware. Virtualization implementations rely on a very big and very complex software component that provides virtualized or emulated hardware to guests. Let us call this software component "virtual motherboard." The following list references these virtual motherboard components for various virtualization implementations:

• HyperV: worker process
• KVM / Xen: QEMU
• VMWare: VMX process

So, we know that these software components for virtual motherboards are big. But what is the issue? Going back to the goals listed above, we assume that these software components operate unprivileged with respect to the hypervisor. Therefore, if a rogue guest operating system finds errors and cracks these components, they still cannot subvert the hypervisor or other virtual machines.

The big problem in these virtual motherboard implementations lies in the support of a secure operating environment granted to the guest. Typical virtual machine usage scenarios intend to host trusted guest operating systems. However, these guest operating systems may in turn host untrusted user space applications. To allow the guest operating system to protect itself, it uses numerous hardware support functions. However, a large number of that hardware is virtualized with the above listed virtual motherboard implementations in virtual environments! The following is a list of a few examples of virtualized hardware which supports the protection mechanisms of guest operating systems:

• Intercepted, but privileged processor instructions are implemented by the mentioned software components. Each intercepted but privileged processor instruction must contain a privilege check to prevent guest user space software to execute that instruction. For example, the processor instruction "MOV CR3" should certainly not be allowed to guest user space software, as this instruction allows changing the page tables used for memory isolation. Only the guest kernel software shall be allowed to perform this instruction.
• Virtualized or emulated hardware is implemented in code that is shared between the guest operating system and untrusted guest applications. Hence, if these guest applications may access portions of such emulated or virtualized hardware, any bugs in such implementation may easily open up venues into other code components that are intended for privileged guest code.
• Virtualized or emulated hardware is required to perform certain privilege checks to prevent guest user space software from accessing them.

If the big and complex virtual motherboard implementations contain bugs, untrusted guest applications may be given a means to circumvent guest operating system protection mechanisms.

Unfortunately, these days everybody seems to be keen in ensuring the correct implementation of hypervisors to achieve the goals outlined at the beginning. Great development effort is spent in this area. However, it seems not everybody is interested in tightening the implementation of these virtual motherboards, even though great security-related achievements may be gained with comparatively less development effort. For example, the virtual motherboards may contain virtualized hardware that may not be needed in certain environments. Therefore, this functionality should not be part of the virtual motherboard in such environments.

For example, QEMU implements several emulated network cards or graphics cards. This is over the top for secure environments. QEMU should only offer one -- maybe the simplest and smallest implementation -- emulated hardware per hardware type, i.e. only one network card or one graphics adapter.

As a bottom line, we ask all participants to not only focus on securing the hypervisor, but to also make sure the virtual motherboard implementation does not allow untrusted guest applications to circumvent guest operating system protection mechanisms.