Security and IO-Virtualization
x86-IO is very hard to virtualize, because x86 is a so called “open architecture”. Very different vendors can develop very different IO-components for x86. Therefore, an overwhelming number of components exist. Virtualization purposes are often considered when IO-components are developed for mainframes (see “I/o for virtual machine monitors: Security and performance issues” by Karger et al.). Components for x86 are usually developed to be driven below a single operating system. Virtualization of x86-IO-components while guaranteeing isolation suffers from possible limitations of these components.
A plenty of IO-components result in a plenty of drivers for all these different components, but drivers for x86 are usually bad: badly designed, unrieable and responsible for a huge degree of erros, flaws and vulnerabilities (see “Reconstructing i/o” by Keir Fraser et al.). Drivers are highly privileged software components and usually are not isolated from other privileged components.
Virtual machines can’t have direct hardware access on x86, the VMM has to multiplex hardware access of multiple suspicous guests. The VMM has to offer an interface like virtual hardware components. An access to virtual IO leads to an access to real IO through the VMM, but to access the real IO the VMM has to integrate multiple drivers into its TCB and the VMM has to trust into proper behaviour of these drivers. Nobody want bad driver code located within the VMM’s TCB, because the VMM is the most privileged component in a virtualized environment. Therefore the VMM wants to locate driver code out of its TCB. In an unvirtualized environment every OS drives IO for its own, with dedicated drivers. With a pure-Isolation-VMM every Guest gets its own set of IO-components and every Guest has its own set of drivers for these dedicated components: no sharing of io-components exist. A pure-Isolation-VMM pushes drivers out of its TCB into the untrusted Guests. Guests don’t use the same software stack for IO. The VMM’s TCB stays small and verifyable.
On x86 the VMM can’t do that, because IO-components have Direct Memory Access (DMA). The IO-components communicate directly, without any address translation, with memory locations. Drivers program IO-components to DMA (write) directly into specific parts of memory. They can overwrite memory-locations dedicated to other guests or the VMM. Therefore, a untrusted driver, located within an untrusted guest that potentially is compromised would be able to compromise the VMM if drivers are located within guests. Therefore, a VMM for x86 can’t locate drivers for IO-components within guests, because it would have to trust its guests. The VMM has to integrate untrustworthy drivers into its TCB. The VMM has to trust into these drivers, though they are not really trustworthy. A flaw within these drivers will compromise system reliability and all guests will be affected.
Well, the VMM now has the drivers, but it has to offer an opportunity to access IO-components by its guests. Different virtualization technologies offer different interfaces.
Full virtualization usually emulates typical IO-components. A guest accesses emulated IO through usual drivers available for these typical IO-components by default. An access to emulated IO is mapped to real IO by the VMM. To be able to use existing driver code within guests, the emulated IO has to behave exactly like its real original counterpart. The VMM only has to offer a small subset of available x86-IO-components, like a specific Network Interface Controller, but writing such emulated IO is a hard and complex task actually. Therefore a guest has to include very much and very complex emulation-code into its TCB. A Flaw within this code is very likely and not only security of guests suffers from this.
A paravirtual VMM usually exports just a small interface for different types of IO, like block-devices or Network Interface Controllers. It uses a Split-Driver-Model. Every guest implements very simple untrusted drivers that communicate with the interface. A paravirtual VMM does not have to use complex emulated IO that behaves like real IO and we don’t need emulation-code. The VMM remains small and simple. Flaws within its interface are less likely.
The VMM has to access real IO directly. Therefore, every VMM has to include drivers for each IO-component available for x86. A VMM is an Operating System and drivers have to be rewritten for every different OS. Therefore, all drivers for x86-IO usually have to be rewritten for each VMM. To avoid this huge implementation effort, a VMM can sit on top of an usual OS. Such a VMM gains access to every driver existing for the particular OS. This is VMware’s “Hosted Architecture” (or Type-II-VMM according to Popek et al.), for example. The Hosted Architecture of course has an important effect on security. The VMM’s TCB has to include a whole OS, including all vulnerabilities. Madnick et al. argued in their paper “Application and analysis of the virtual machine approach to information system security and isolation” … “that a combined
virtual machine monitor/operating system (VMM/OS) approach to information system isolation provides substantially better software security than a conventlonal multiprogramming operating system approach”, because a VMM is a very small program and a OS is much more complex than a VMM. With a Hosted Architecture this statement becomes false. The TCB of such a VMM is not smaller than the TCB of any OS, it is bigger of course.
Instead of a VMM running a Hosted Architecture, a VMM can run on a bare machine, that is: on top of its hardware directly. Such a VMM is called Bare-Metal-VMM - or Type-I-VMM.
To exclude drivers from a VMM’s TCB, a VMM can export drivers into n Guests. Driver-Domains share IO with other Domains (Guests) through interfaces of a VMM. Such a VMM tries to increase security isolation by removing untrustworthy drivers from its TCB and the whole system. Driver-Domains have special privileges, other Guests don’t have, because they have to access real IO directly. Every Guest having direct hardware access has to be considered as trusted, because it can DMA into all memory locations. A real security isolation is not achievable by Driver-Domains on x86. In addition, a Driver-Domain is in contact with sensitive data of guests. A TCB does not get smaller just by moving things around within a TCB. The VMM’s TCB will include all components of each Driver-Domain. Each Driver-Domain usually runs a complete OS for itself. Therefore, the VMM’s TCB will include n Driver-Domains and n Operating Systems. In addition the flow of information gets more complicated, because we have to take the indirection of Driver-Domains. The VMM has to route each IO-access to a specific Driver-Domain.
The Security of a VMM, running a Hosted-Architecture or running a Domain-Architecture won’t exceed security limitations of the Operating Systems the VMM runs on.
To address the issue of badly designed drivers, a VMM can restrict itself to only a particular subset of available IO-components available on x86, because we would be able to rewrite the driver code for this subset and consider it as trusted. We gain a smaller TCB, but we loose flexilbility, because such a VMM only runs on specific hardware.
The only way to solve security issues of IO-Virtualization is to use a I/O Memory Management Unit (IOMMU). An IOMMU is able to restrict DMA of IO-components, because it adds an additional layer of address translation. An IOMMU maps DMA-Addresses to physical addresses and the VMM programs the IOMMU how to map it. Therefore, an IOMMU offers flexibility of DMA-Address-Translation like a MMU offers for virtual memory. The IOMMU creates dedicated address spaces and an IO-component only has access within this space. Therefore, an IOMMU isolates accesses of guests to IO-components completly. With an IOMMU we are able to push drivers into Driver-Domains without an increase in complexity, because we can consider these guests as untrusted now and use the IOMMU to guarantuee isolation. The VMM’s TCB stays small and formally verifyable, an error within drivers can’t compromise system security.
IOMMU’s are not yet included with every VMM, but they are likely to be in near future, according to Leendert van Doorn et al. within “The Price of Safety: Evaluating IOMMU Performance”.