Separating Hypervisor Trusted Computing Base Supported by Hardware
Total Page：16
File Type：pdf, Size：1020Kb
Separating Hypervisor Trusted Computing Base Supported by Hardware Carl Gebhardt Chris I. Dalton Allan Tomlinson Information Security Group Hewlett-Packard Labs Information Security Group Royal Holloway, University of Bristol, BS34 8QZ, UK Royal Holloway, University of London, TW20 0EX, UK [email protected] London, TW20 0EX, UK [email protected] [email protected] ABSTRACT of interest in virtualisation and its application in a security In this paper we explore how recent advances in virtuali- context, numerous researchers [8, 17, 19] have investigated sation support for commodity hardware could be utilised to how the TCB can be reduced and security critical functions reduce the Trusted Computing Base (TCB) and improve the could be isolated. This separation of privileged code, or dis- code separation of a hypervisor. To achieve this, we reassess aggregation, is well known and an actively discussed concept on the definition of the TCB and illustrate how segregation of, for instance, XEN-based systems [19]. of different code blocks could be enforced by hardware pro- Moreover, some researchers have argued that a virtualised tection mechanisms. We argue that many software-based system is more secure than a non-virtualised system, al- efforts in TCB reduction and separation can benefit from though it adds code to the TCB [5]. This is based on the utilising those hardware capabilities. isolation properties and fault containment introduced with virtualisation. In this sense, virtualisation is just a coarse grained isolation scheme which, in contrast to traditional Categories and Subject Descriptors OS isolation, does not operate on a process, but below the D.4.6 [Software]: Operating Systems—Security and Pro- kernel level. Arguably, the security gains are based on the tection fact that a hypervisor controls resources and executes out- side the control, beneath the traditional OS kernel. This, however, does shift the burden of separation and isolation General Terms from the OS kernel to the hypervisor. Currently, hypervisors Design, Security are still considered more trustworthy than traditional OSes based on their smaller TCB, but they are growing fast in Keywords functionality and size. Consequently this trust may become misplaced, and alternative methods are required to reduce Virtualisation, hardware extension, Trusted Computing Base the TCB. In this paper we explore the possibility of using the cur- 1. INTRODUCTION rently unused hardware protection mechanism of modern Numerous researchers suggested the use of virtualisation virtualisation-enabled CPUs. We suggest making use of for security, fault isolation or assurance [5, 14]. The ar- those currently unused protection modes to separate and iso- gument to use virtualisation for security improvements is late security critical functions within a hypervisor.Wewant based on the reduction in the code base which has to be to emphasise that TCB reduction is not a new idea, but trusted. Rather than trusting an Operating System (OS) that recent developments in virtualisation technology have to isolate processes and share resources, in a virtualised created new challenges and opportunities. Consequently, we system a hypervisor is entrusted with those tasks. A hy- want to seize the moment to learn from past mistakes and pervisor consists of only a few hundred of thousand lines outline possible directions of future virtualisation research. of code as opposed to the millions of lines of source code (SLOC) in a modern OS and thus potentially offers bet- 2. MOTIVATION ter security guarantees. Reducing the Trusted Computing Base (TCB) is not a novel idea and is a well understood Unfortunately, from a security perspective, functionality and discussed concept in past and present system security often takes precedence over secure design, leaving security to research [5, 11, 17, 19, 23, 25]. With the recent resurgence be retrofitted afterwards. As outlined in Section 4.1, there areprotectionmechanismsinmodernCPU’swhicharenot utilised at all. The historical decisions taken not to use all protection mechanisms have resulted in legacy system sup- Permission to make digital or hard copies of all or part of this work for port issues for today’s designers. Changing this, and util- personal or classroom use is granted without fee provided that copies are ising the unused protection modes is possible, but inflicts not made or distributed for profit or commercial advantage and that copies a significant amount of development and maintenance work bear this notice and the full citation on the first page. To copy otherwise, to for software developers. On the positive side, CPU man- republish, to post on servers or to redistribute to lists, requires prior specific ufacturers are increasingly addressing security concerns in permission and/or a fee. STC’10, October 4, 2010, Chicago, Illinois, USA. hardware and are willing to trade chip real estate for secu- Copyright 2010 ACM 978-1-4503-0095-7/10/10 ...$10.00. rity functions. For instance, modern platforms are able to 79 support an alternative way to dynamically boot a trusted (i.e. one that can undermine the security of the system) hypervisor or OS kernel. Those platforms are able to dy- may be invoked with arbitrary input.”. Further the authors namically reset and measure their state without performing conclude that all code which may undermine the systems’ a traditional reboot and initialisation through a BIOS [9]. security should be trustworthy. The borders of the TCB To enable this so-called Dynamic Root of Trust for Measure- also may become blurred, particularly when availability and ment (DRTM), the CPU, chipset and platform manufactur- robustness are paramount. A platform can contain code ers had to accommodate many changes to the underlying which is designed to detect, contain and recover from a fail- hardware and software infrastructure. ure. This code might not be security critical according to the However, a secure system still requires a harmonised col- previous discussion. However, this code provides the basis laboration between hardware and software components. The for a operational trusted platform. We therefore distinguish recent resurgence of interest and advances in virtualisation between ‘operational dependable code’ and ‘trusted code’. hardware development, has created a window of opportunity It is however arguable, whether operational code should be for creative security solutions. Consequently, we propose to included in the TCB or not. make full use of the existing protection mechanisms avail- Further, it is difficult to evaluate the quality of a given able in the new, hardware assisted, virtualisation chips at code base. It is a common belief, that the amount of SLOC this early stage of hypervisor development. is a good measure for the quality of a TCB [11, 27]. This measure seems too coarse grained and immediately raises 3. BACKGROUND the question of which lines of code to trust? Do all lines of code need to be trusted, or is it sufficient to trust only code 3.1 Trusted Computing Base which performs sensitive operations? Moreover, it is also clear that a poor interfaces design or poor code separation The many platform components, technologies and con- will not result in a more trustworthy system just because it cepts which are responsible for the correct functionality and has less amount of code than any other system. security of a computing platform, constitute the Trusted Therefore, as discussed in the remainder of this paper, Computing Base (TCB). In other words, a platform solely the overall trustworthiness of a system can be elevated by relies on the TCB components for functionality and security separating and containerising security critical functions, es- enforcement and therefore to evaluate a platform’s trustwor- pecially if this can be supported and enforced by hardware. thiness it is necessary to assess its TCB. In the following, we want to discuss the definition of the TCB and in Section 4 outline our TCB model for hardware assisted virtualisation. 3.2 Ring Protection The Trusted Computer System Evaluation Criteria [6], The ring protection scheme is based on a 2-bit privilege better known as the ‘orange book’, defines a TCB as fol- level, enabling the CPU to determine four different separate lows: “The heart of a trusted computer system is the Trusted levels of privilege - from ring 0, with the most privileges, Computing Base (TCB) which contains all of the elements to ring 3, with the least privileges. Depending on which of the system responsible for supporting the security pol- ring level code is being executed, the program has access to icy and supporting the isolation of objects (code and data) different CPU functionalities and features. Traditionally, an on which the protection is based.”. The criteria further de- OS kernel, including device drivers, runs with the highest mands the TCB to be as small as possible: “[...] a TCB privileges and no restrictions in ring 0. Applications are should be as simple as possible consistent with the functions placed inside ring 3, the least privileged level. Rings 1 and 2 it has to perform.” are generally unused. Modern OSes however, support a feature-rich set of func- Unfortunately, the monolithic design of commodity OSes tionality and an increasingly complex security policy model, does not only pose a security threat, but also turns out to be which unfortunately, increases the complexity of its TCB. a technical hurdle for virtualisation. In a virtualised envi- Moreover, the perception of the TCB may also differ from ronment, a guest OS must not be allowed to run directly on a user’s, a software vendor’s as well as a platform supplier’s hardware and interfere with the CPU state directly. Virtu- point of view. Reducing the TCB is a well understood con- alisation therefore requires placing a hypervisor layer under cept to increase the trustworthiness and reliability of a com- the OS, in order to trap privileged instructions. puter system [2, 4, 11, 18, 19, 23, 25, 27].