Improving Xen Security Through Disaggregation

Improving Xen Security through Disaggregation Derek G. Murray Grzegorz Milos Steven Hand University of Cambridge Computer Laboratory [Firstname.Lastname]@cl.cam.ac.uk Abstract In order to evaluate the trustworthiness of a software system, Virtual machine monitors (VMMs) have been hailed as the basis for it is necessary to identify its trusted computing base (TCB). The an increasing number of reliable or trusted computing systems. The integrity of the TCB may then be measured, and this unforgeable Xen VMM is a relatively small piece of software – a hypervisor measurement can be used to generate a key that may be used for at- – that runs at a lower level than a conventional operating system testation, encryption and decryption operations [33]. However, the in order to provide isolation between virtual machines: its size TCB of a current Xen-based system comprises, in addition to the is offered as an argument for its trustworthiness. However, the VMM, a fully-fledged operating system (known as Dom0) and a management of a Xen-based system requires a privileged, full- set of user-space tools. These tools are used to perform several tasks blown operating system to be included in the trusted computing that require elevated privileges, including the creation of new VMs. base (TCB). Due to the inclusion of user-space software in the TCB, the size of In this paper, we introduce our work to disaggregate the man- the TCB is practically unbounded, as it can include any software agement virtual machine in a Xen-based system. We begin by that may be run by the administrator of the physical platform. Fur- analysing the Xen architecture and explaining why the status quo thermore, any measurement of the TCB cannot be used to guarantee results in a large TCB. We then describe our implementation, which the integrity of a virtual machine, because the system administrator moves the domain builder, the most important privileged compo- may run arbitrary privileged code at any time. In effect, this im- nent, into a minimal trusted compartment. We illustrate how this plies that the system administrator must be trusted, which impairs approach may be used to implement “trusted virtualisation” and the usefulness of Xen in utility computing scenarios [26]. improve the security of virtual TPM implementations. Finally, we In this paper, we demonstrate the use of disaggregation to shrink evaluate our approach in terms of the reduction in TCB size, and the TCB of a virtual machine in a Xen-based system. We have by performing a security analysis of the disaggregated system. transferred the VM-building functionality into a small, trusted VM that runs alongside Dom0. We had two main goals in this work. Categories and Subject Descriptors D.4.6 [Operating Systems]: The primary goal was to reduce and bound the TCB of a Xen-based Security and Protection—Information flow controls system, in order to improve its security. In particular, by removing Dom0 user-space from the TCB, we would remove the require- General Terms Design, Security ment that the administrator of the physical platform be trusted. We Keywords Disaggregation, trusted computing base, virtual ma- anticipate that this will be relevant for the users of virtualisation in chines utility computing. A closely-related goal was to demonstrate that a VM running on a disaggregated system maintains the same confidentiality and integrity properties as a physical machine, assuming 1. Introduction the inviolability of the TCB. This should allay many concerns over Many researchers have proposed using virtual machine monitors switching to a virtualised approach. (VMMs) to improve the reliability, security or assurance of com- We begin by introducing the Xen architecture, the domain build- puting systems [10]. They argue that the small code-base of a VMM ing process, and how these relate to the TCB of a Xen-based sys- can be used as justification for trusting its correct operation; this tem (Section 2). We then describe our framework for selecting a same argument has been applied to microkernels [31]. The assump- TCB for the disaggregated solution, and introduce new criteria for tion is made that the integrity of the lower layers (including the evaluating a TCB that should be considered in addition to the raw VMM) is axiomatic, therefore it is possible to infer the integrity of number of lines of code (Section 3). We discuss the implementation components (individual virtual machines) running above [3, 7]. We of our disaggregated domain builder design, which has also neces- aim to use the Xen hypervisor [4] as the basis of an “open trusted sitated the development of a lightweight inter-VM communication computing” system [20]. Such an approach extends the purview of mechanism (Section 4). We evaluate our disaggregated approach trusted computing hardware into virtual machines (VMs); it also against our primary goals by enumerating the contents of the TCB allows the user discretion over when to use this hardware, and en- and performing a security analysis (Section 6). Finally, we consider ables the use of trusted and untrusted software side-by-side. related work (Section 7) and draw conclusions (Section 8). 2. Background The existing Xen VMM architecture and privilege model have This is the author’s version of the work. It is available here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in VEE implications for security, and enable an administrator to take full ’08. http://doi.acm.org/10.1145/1346256.1346278 control of all virtual machines running on the same host. It is VEE’08, March 5–7, 2008, Seattle, Washington, USA therefore impossible for the users of a virtual machine to trust Copyright c 2008 ACM 978-1-59593-796-4/08/03. $5.00 in the confidentiality and integrity of that virtual machine. This o a d k e r n e l i m a g e f r o m d i s k may inhibit the uptake of virtualisation, especially in the class of L applications where confidentiality is required by law. l l o c a t e p h y s i c a l m e m o r y m a p In this section, we provide a brief overview of the Xen architec- A ture (Subsection 2.1), describe the domain building process (Sub- C o p y k e r n e l i m a g e i n t o n e w V M o m U section 2.2), and discuss the design of Xen with respect to its trusted D computing base (Subsection 2.3). S X e n t u p i n i t i a l p a g e t a b l e s f o r n e w V M 2.1 Xen architecture e The traditional representation of a Xen-based system shows sev- L a u n c h n e w V M eral virtual machines, drawn separately and side-by-side on top of the Xen VMM (hypervisor), which itself is positioned above the platform hardware [4]. A single VM, Dom0, is distinguished as a Figure 1. Outline of the steps involved in building a new VM management or control VM, which is always booted by the hyper- (DomU). Privileged operations are shown as bold arrows; direct visor, and contains the control plane software. However, this picture foreign mappings are shown as dotted lines. ignores the trust relationships between Dom0 and the remaining VMs. In our work we aim to reduce and bound these trust relationships, so that Dom0 can accurately be positioned side-by-side with robustness [4]. However, the delegation of this task to user-space other VMs. processes exposes the special privileges to all user-space processes Xen makes extensive use of paravirtualisation in order to in Dom0, which has implications for the trusted computing base achieve good performance. This process entails porting VM ker- (see §2.3). In this subsection, we describe the process of building a nels to run on a new machine architecture that corresponds to the paravirtualised VM. Thanks to paravirtualisation, many of the low- support provided by the VMM. On the x86 architecture, four pro- level steps involved in a conventional x86 OS boot process (such as cessor rings are used to define privilege levels. In most common interactions with the BIOS, and the use of 16-bit real mode) can be operating systems, the kernel runs in ring 0 (the highest privilege elided. level), and user processes run in ring 3 (the lowest privilege level). The main steps in the domain building process are shown in Fig- Xen must have full control over and protection from the VMs that ure 1, with privileged operations (as defined later in §3.1) shown as it hosts, so it runs in ring 0. VM kernels are paravirtualised in order bold arrows. Firstly, the kernel image (and, optionally, an initial to run in ring 1. User processes continue to run in ring 3. ramdisk) are loaded from disk into the domain builder’s memory. Xen provides many mechanisms for communication. The most The image is parsed in order to extract the executable code region, primitive is the hypercall, which is an invocation of the hypervisor and obtain any parameter values. Following this, the builder re- by a guest VM. A hypercall is analogous to a system call in con- quests that the hypervisor allocates physical memory for the new ventional operating systems, and is also implemented using a soft- VM. This is not depicted as a privileged operation, because it does ware trap to transfer control to the hypervisor.

Load more