Existing Work

The following presents a selection of existing work and solutions in the area of virtualization.

Xen Xen [Bar+03] is one of the early adopters of virtualization technology on the x86 platform. It started with a paravirtualization approach and added support for hardware-assisted virtualization later when this technology was becoming available. Xen is a widespread solution and as it is available as open source, it is also the base for many other virtualization solutions, both in academia and industry.

The Xen architecture consists of the Type-1 Xen hypervisor and a management VM, calledDom0. Dom0 is always a paravirtualized VM running Linux [Comb] which runs the management tools and is in charge to control the other VMs, calledDomU. DomUs can run paravirtualized VMs and, if supported by the hardware, unmodified guest VMs.

From the security perspective, the trusted computing base of any VM running on a Xen system consists of the Xen hypervisor itself and the complete Dom0 management VM, being a Linux kernel together with the user-land infrastructure running on it. This increases the trusted computing base compared to a monolithic Linux system and thus Xen does not provide the necessary design for a secure system foundation I envisage.

KVM Kernel Virtual Machine (KVM) [Kiv+07] is a Type-2 virtualization system, adding a virtualization functionality to the Linux kernel and making it a hypervisor. KVM builds

upon hardware support for virtualization and started with the x86 architecture. For device virtualization KVM uses an adapted version of the QEMU system emulator [Bel05]. Any VM running on a Linux with KVM needs to rely on the Linux kernel and the adapted QEMU driving the VM. Analogous to the reasoning for Xen, the trusted computing base includes a monolithic kernel design and is thus not suited for a secure system.

VMware Mobile Virtualization Platform The VMware Mobile Virtualization Plat-form (MVP) [Bar+10] targets embedded and mobiles devices, most prominently smartphones.

Their primary use case is to run a second Android operating system on the mobile phone to cover contradicting goals of a private and business usage of the phone. The OS for private use shall be as open as possible and allow to install any third-party application. On the contrary, the business OS shall be as secure as possible and controlled by company IT.

The architecture of MVP uses a standard Android configuration and places a hypervisor module into the host Android Linux kernel, making the host system a type-2 hypervisor.

Several programs are executed in the host to provide functionality to the guest system, such as virtual private networking and storage. MVP emphasises the BYOD (Bring Your Own Device) approach, which requires easy adaptability of the system to any mobile device and as such favours the approach of adding hypervisor functionality to an existing system. The host system runs the private Android and the guest system runs the enterprise version.

Consequently the enterprise Android has to rely on the private Android system, that is the trusted computing base of the enterprise Android system includes the open private Android system.

MVP relies on the security properties of the host Android system. Besides relying on the Linux kernel, the user interface and application starting subsystem must be also trusted as for example the switching between the domains is done with a special application.

NoHype NoHype [Sze+11] is an architecture that statically allocates CPUs and memory to virtual machines and lets a single virtual machine run exclusively on a number of cores.

The system uses state-of-the-art Intel processors to leverage virtualization features such as nested page-tables. During startup Xen is used to bring a virtual machine into a fully running state. When the startup is completed, the hypervisor is exchanged with a very minimal one that will kill the virtual machine on any virtual machine exit event. Consequently the VM must be fully working without causing any exit events. As this architecture removes the traditional hypervisor during runtime of a VM there is also no attack vector a VM could use to break out of the virtual machine and attack other VMs or the whole system.

NoHype uses a slightly modified kernel to mitigate problems where the hardware provides no means to guard against misbehaving other virtual machines, such as with inter-processor interrupts, which according to the authors, posses no problem to the applicability of their solution. Their target use case is secure virtualization in the cloud-computing area where VMs can be statically allocated to the hardware and overprovisioning is not required to better utilize the available hardware.

Concerning running real-time workload in a virtual machine, the NoHype architecture is interesting, as no intercepting hypervisor also means that it cannot induce any addi-tional latency. Only the latency through the hardware virtualization funcaddi-tionality is added (see [SLW09]). NoHype requires to have a CPU local timer which for the Intel platform is the APIC timer that would need to be sufficient for the VM workload. NoHype is exclusively targeted at virtualization and the architecture does not allow to run any additional services

besides virtual machines where each virtual machines occupies at least one physical CPU at all times, even if the VM is idle.

CloudVisor CloudVisor [Zha+11] is a virtualization system that targets the cloud envi-ronment, aiming to reduce the trusted computing base of each VM running in the system.

The threat model describes VMs that exploit the VMM to gain access to other VMs as well as the cloud provider that can use management tools to inspect customer VMs. To prevent that, CloudVisor uses secure booting techniques to plug a tiny security monitor below the VMM and run it in guest mode, using nested virtualization. Nested paging is used to hide the guest memory from the VMM and each VM exit and entry is trapped by CloudVisor to adapt the nested page table. VM requests on storage devices are detected and transparently encrypted by CloudVisor, presenting only encrypted data to the VMM.

The CloudVisor architecture targets common virtualization systems and introduces an isolated layer between the VMM and guest so that a, potentially penetrated VMM, cannot access data from within a VM. It runs systems with a single VMM and, due to the encryption of storage data, induces an overhead of up to 54.5%. Secure booting techniques shall ensure that a guest must only trust CloudVisor and not the VMM. CloudVisor might be a solution for existing VMM systems, however, a system should include security considerations from the ground up and integrate those in the system.

SPUMONE SPUMONE [Nak+11] is a virtualization system for multi-cores that is developed on the SH platform. It runs guest systems in privileged mode. This offers benefits with regards to the event latency achieved by the system up in to the guest. The low engineering effort required to bring a guest OS to the platform is also put as an advantage of SPUMONE. Regarding devices the platform requires that devices can be exclusively given to a guest, any possible sharing cannot be prohibited and can be done cooperatively among the guests. As the guest kernels are running in the privileged mode of the processor, they cannot be protected from other subsystems using an MMU. Only the user processes on the guest system use virtual memory protection. SPUMONE proposes to use core-local memory to run code on a core. Core-local memory is not accessible from other cores and thus provides protection from code running on other cores. However, this requires that all code running on a core fits into the core-local memory, which size is only a few hundred kilobytes and thus does not suffice to run for example Linux. To support guests that do not fit entirely into the core-local memory, SPUMONE uses a swapping mechanism with hashes to exchange memory pages between the core-local memory and the main memory. Code is only executed in the core-local memory and the hashes are used to check the integrity of the memory when it is copied to from the main memory to the core-local memory. SPUMONE is not able to protect the virtualization layer itself on the core nor other guest running on the same core. A monitor service is proposed to check integrity. This monitor must run on a separate core so that it cannot be tampered with. To protect guests from each other the system can only support one guest per core.

Cells The Cells architecture [And+11] targets mobile phones by providing multiple virtual phones on a single device. It uses virtualization based on operating system mechanisms, such as namespaces and device proxies, to run multiple instances of mobile phone software on the same kernel. This approach has the benefit that all functionality related to device drivers, noteworthy 3D acceleration, does not need to be virtualized and can be used in any

of the virtual phones. The downside is that all the virtual phones depend on the proper working of the Linux kernel and any attack on Linux puts all virtual phones on risk.

NOVA The NOVA microhypervisor [SK10] is a tiny hypervisor. It uses the mechanisms provided by the x86 architecture to implement virtualization and splits the functionality of a traditional VMM into the hypervisor, which runs in privileged mode of the CPU and handles CPU based virtualization, and the actual VMM which handles device virtualization.

Using one VMM per VM, the VMM is just exposed to the VM it handles but not to other VMs. Proper isolation is ensured by the NOVA microhypervisor. NOVA outperforms other virtualization solutions, showing that splitting hypervisor-functionality from the VMM does not induce any performance penalties.