Securing virtual machine monitors: what is needed?

ABSTRACTIt is widely believed that the use of a virtual machine monitor (VMM) is at least as secure, if not more secure than separate systems. A recent Information Week survey [6] reports that 55% of responding business technology professionals believe that a system running in a virtual machine is as safe as physical servers and 20% believe it safer than physical servers. Such views are certainly encouraged by recent papers, such as [2] and [10]. Madnick and Donovan [9] first proposed VMMs for security in 1973 by pointing out that "since virtual machine monitors tend to be shorter, simpler, and easier to debug than conventional multiprogramming operating systems, the VMM is less error-prone." In reality, the security of a single system running in a virtual machine can never be as secure as that single system running in its own dedicated physical hardware. The security of a system in a virtual machine depends on the correct operation of both the operating system and the hypervisor software, while in a dedicated physical computer, it depends only on the correct operation of the operating system. Because there are more lines of code that must be correct, the VMM case always has more opportunity for exploitable flaws. What Madnick and Donovan were actually talking about was not that any one particular virtual machine was more secure, but rather that a small secure virtual machine monitor can improve the security of controlled sharing between different virtual machines, better than can a conventional operating system. The failure of any one virtual machine's operating system then can only compromise data which is accessible to that virtual machine. While many people view virtual machine monitors as something special and different, in realty they are just special-purpose operating systems. The major difference is that the API to a virtual machine monitor is the instruction set of the virtual machine, while the API to an operating system is a set of system calls to manipulate processes, file systems, perform I/O, etc. To the extent that a particular VMM uses paravirtualization, it begins to look more like a classical operating system than a VMM. Just like operating systems, VMMs can have exploitable security vulnerabilities. Attanasio, et. al. [1], published a classic study of security vulnerabilities in VM/370 that illustrates the problem. A more recent study of VMM vulnerabilities has been done by Ferrie [4]. Many of these vulnerabilities arise, because modern VMMs are much larger and more complex than is required. Karger and Safford [7] that not only do "modern" VMMs not meet the requirements of being small and simple, but that their approaches to I/O virtualization not only can compromise the security, but also the performance of the systems. The solution to these security vulnerabilites is to return to Madnick and Donovan's original idea that VMMs are supposed to be very small and simple. There are VMMs that have been designed to be small and simple and to pass high-assurance security evaluations, including KVM/370 [5] and DEC's VAX VMM [8]. The only VMM to have received Common Criteria evaluation to at least the medium assurance level (EAL5) is IBM's Processor Resource/System Manager (PR/SM) [3].