Separating Hypervisor 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 (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, -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 -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 , 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 (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.. 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 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]. The motivation be- These instructions are then executed at a lower privi- hind reducing the TCB of a system is twofold: firstly, it is lege level than they would be in a non-virtualised system. widely accepted, that the reduction of code, results in less Unfortunately the architecture contains several non- errors and thus potential flaws that could compromise secu- virtualisable instructions that could undermine the system’s rity [11, 18]. This is generally true if all code runs on the stability and security [21]. Special safeguards have to be ap- same privilege level. Secondly, evaluating or verifying code plied to those instructions and they have to be handled by quality demands small and well defined code blocks. Prefer- the hypervisor. However, ring de-privileging is not straight- ably, these code blocks should by human auditable; however, forward, and a hypervisor can be implemented in different in reality, due to practicality and cost issues, verification of ways. Technical details and the challenges caused by ring complex code such as OSes or hypervisors is very rare, but de-privileging are beyond the scope of this paper. possible under some strict assumptions. In 1987 Shockley To overcome the limitations of ring de-privileging and al- et al. [25] already described this approach as “divide and low any unmodified guest OS to run without restrictions at conquer” and argued a complex TCB can be divided into its intended privilege level, CPU manufacturers introduced a subset of smaller components which can independently or hardware support for virtualisation. Hardware assisted vir- incrementally be evaluated. tualisation allows the creation of a Hardware Virtual Ma- The work of Murry et al. [19] however, defines the TCB chine (HVM) [1, 30] under the control of a hypervisor and “as a set of code positions from which a privileged operation are supported by hardware extensions to the CPU. HVM in-

80 troduces a special mode of operation which allows the guest 4.2 Code Separation OS kernel to execute at its intended privilege level: A more general approach to reducing the TCB is to sep- arate trusted components from untrusted parts. This re- Non-privileged mode - This is a modified view of the quires some form of interaction or collaboration between the CPU to accommodate virtualisation. In this mode two separated domains. To facilitate this, one well known VMs can now run at their intended privilege level, all approach is to implement a like IPC: for ex- privileged and some unprivileged CPU instruction will ample via message passing over shared resources. Another trap into the privileged mode. approach is to use a layered system as described by Karger Privileged mode - This mode remains the same as if run- et al. [12] for the VAX architecture, in which each layer ning a native OS kernel, however a hypervisor is placed adds specific functions within a security kernel. Alterna- into the privileged mode to handle the traps from the tively, trusted proxies or trusted wrappers can be used to non-privileged mode. decouple previously entangled components [11, 27]. The se- curity gained, results from well defined interfaces and lim- The transition between the two modes is controlled by ited interaction between the components on different trust hardware and the hypervisor. Transitions to the non-privi- levels. The addition of interfaces or processing capabilities leged guest kernel are referred to as VM entry whereas tran- also adds code to the TCB. This seems counterintuitive at sitions to the privileged hypervisor are called VM exits. first, however, adding IPC capabilities results in an overall Because the authors are more familiar with the archi- decrease in the size of the TCB as other critical components tecture as well as limited access to AMD documentation, we can be outsourced. want to focus on Intel terminology in the following. However As outlined in the Section 3.1, disaggregation and code the concepts and ideas are potentially equally applicable to separation is beneficial, leading to a smaller TCB. How- any x86 architecture and AMD’s virtualisation technology ever, simply stripping a TCB of all non-security function- in particular. ality seems a little naive. Furthermore it is debatable what a “good” TCB consists of. For interfaces, according to Mur- 4. TRUSTED COMPUTING BASE FOR HVMS ray et al. [19], it rather depends on the size of the interfaces Previous efforts on TCB reduction relied on software in- and the size of the TCB state space. Assuming the inter- terfaces for segregation, e.g. trusted wrappers, Inter Pro- faces are secure by design and untrusted input is sufficiently cess Communication (IPC), or trusted libraries. Instead of sanitised, adding interface code to the TCB could increase relying on software interfaces for code separation only, we the overall trustworthiness of a system. want to discuss the extension of those concepts with ex- However, we propose to add another parameter to the isting hardware protection mechanisms. Hardware control evaluation of the TCB: hardware separation. We can phys- mechanisms have the advantage of being self-contained and ically separate code, reduce the input sanitisation in the have a smaller attack surface, thus reducing the chance of core TCB and therefore reduce the interface complexity. On subversion [24]. Moreover, hardware implementations tend legacy systems, there are generally two places where code to offer a performance benefit over software only solutions. was executed: ring 0 and ring 3. As a result, any compro- With recent advances in hardware virtualisation support, mise of the most privileged context (ring 0) led to a complete the complete ring protection scheme also became available system compromise. Therefore, all code executed on ring 0 to hypervisors. Consequently, we argue in the following, had to be trusted and included in the TCB. Code running on that trusted code separation through software interfaces can ring 3 is widely considered untrusted, with some exceptions, be supported by hardware protection mechanisms. Further, e.g. ring 3 code executing system calls, etc. we want to discuss the opportunity to re-consider how the The introduction of a new hardware-based hypervisor mode execution of hypervisor code can be separated to increase has fundamentally altered this assumption. To embrace the the overall trustworthiness of virtualised systems. new hardware privileges, we would like to propose the fol- lowing classification of TCB components: 4.1 HVM Protection Rings In Intel terminology the privileged mode is labelled VMX 4.2.1 Core hypervisor TCB root mode whereas the unprivileged mode is called VMX The core hypervisor TCB (hTCB) is located on ring 0 in non-root mode. The Virtual-Machine eXtension (VMX) is VMX root mode H0 and in essence remains the same as dis- a new hardware enhancement introduced to support virtu- cussed in Section 3.1. However, the core hypervisor TCB alisation [30]. It is important to emphasise, that the VMX consists of all security critical functionality, which if failing, root mode implements the protection scheme described in would undermine the system’s security. Within the core hy- Section 3 and illustrated in Figure 1, whereas the VMX pervisor TCB are included those functions that are neces- non-root mode can be regarded as a new mode of operation sary to interact with the extended hTCB. This includes any with reduced privileges. Both modes support all four rings, means of implementing the interface as necessary, and the where the guest OS is presented its expected ring model and associated input sanitising. Figure 1 illustrates the position the hypervisor is able to use multiple privilege levels on its of the core hTCB. own [30]. In the following we use the terminology H0 to H3 for the rings in VMX root mode that are available to the 4.2.2 Extended hypervisor TCB hypervisor. The extended hTCB is executed on either ring 1, ring 2 Throughout literature, the whole VMX root mode is often or ring 3 in VMX root mode and located outside the bound- referred to as ring -1, implying that it is a new mode of aries of the core hTCB. Potentially three different layers operation added to the existing four rings. This is a common of extended hTCB can exist. See Figure 1. Each of these misconception as the VMX non-root mode is actually new. extended TCBs will be represented by its associated hard-

81 ware . Each layer in this chain of extended transitions on current generation chips. We are aware that hTCBs has to trust the layer beneath, until the core hTCB this might change with further advances in hardware vir- is reached. tualisation technology, for instance hardware assisted page tables. However, a detailed performance comparison is be- 4.2.3 Guest TCB yond the scope of this paper. As highlighted in Figure 1, the guest TCB (gTCB) is the trusted codebase located in the VMX non-root mode, and 5.2 Development Effort thus contains the trusted code executed in the context of There will undoubtedly be a development effort associated each VM. Guest VMs have no knowledge of the functions with utilising the VMX root mode protection mechanisms. implemented in the root mode, consequently the complete The magnitude of changes necessary to the hypervisor and TCB of each VM is the sum of all TCBs beneath it. How- the amount of development effort for the hypervisor appli- ever, as VM exits trap to the hypervisor and thus the core cations will certainly depend on the usage scenario. hTCB, the extended hTCB is not always included in the overall TCB automatically. This will depend on which func- 5.3 Device Sharing tionality, has been implemented in the extended hTCB. Device drivers remain a difficult problem, because they have access to physical resources. In a virtualised environ- ment, efficiently sharing physical resources often requires the Ring 3 Guest Application inclusion of device drivers into the overall TCB. On sys- tems without Direct Memory Access (DMA) protection, de- Ring 2 vice drivers have potentially unlimited access to all physical memory and must be safeguarded. DMA protection is be- Ring 1 coming available on commodity systems in the form of an Input Output Unit (IOMMU). How- Ring 0 gTCB ever, whilst an IOMMU allows the safe direct assignment

VMX non-root mode Guest OS of a device to a VM, it does not solve the issue of device sharing. H3 ext. hTCB 3 6. RELATED WORK H2 ext. hTCB 2 Apart from the previously discussed KVM, we are not aware of any other work, which proposes the use of the CPU H1 ext. hTCB 1 protection scheme in the VMX root mode. Consequently, we are not aware of the use of the discussed protection schemes VMX root mode H0 Hypervisor core hTCB for TCB code separation or reduction. However, numerous publication exist on reducing the TCB as well as extend- ing hardware features to protect the TCB. In the following Figure 1: Architectural overview. we categorise related work into two sections: work on TCB reduction and work on protecting the TCB with hardware. 6.1 TCB reduction 5. CONSIDERATIONS The work of Schaefer et al. [23] in 1984 and the later The architecture we propose has some similarities to the extension in 1987 by Shockley et al. [25], discussed the par- Kernel-based Virtual Machine (KVM) [13] model: The titioning and reduction of a TCB into smaller subsets. They OS is executed in root mode with the kernel placed on H0 argue that smaller subsets allow for a chain of simpler evalu- and user applications, such as guest emulation, reside at ations, which leads to the conclusion that the overall system H3. Guest OSes are executed in non-root mode at their in- is correct. Moreover, Shockley et al. [25] discuss a hierar- tended privilege level, while the VM as such is an userspace chical TCB design organised in protection domains. This is task in VMX root mode. However, this has similar trust im- very similar to our proposal which can be regarded as an plications as the XEN model since it too includes a general application of their discussion to x86 hardware protection. purpose OS in the TCB. Additionally, in a para-virtualised More recently, P-Maps [22], Flicker [16] and TrustVisor [15] environment such as XEN, it is not trivial to separate the have been proposed; they are efforts to reduce the TCB and hypervisor and the management VM by hardware. This re- improve runtime integrity of security sensitive applications. sults from the direct hardware access privileges held by the While they offer a secure execution environment utilising the management VM. DRTM, they require applications specifically to be written for this environment. The TCB of such a design is certainly 5.1 Performance tiny; however, this comes with a high development effort The goals of security and performance often appear incom- as such environments typically lack sophisticated debugging patible. However, our approach has one appealing aspect: and testing capabilities. The transitions between VMs and hypervisor via VM exists The work of Murray et al. [18,19] discusses how the TCB and VM entries on current generation hardware, still inflict of XEN-based systems could be reduced by using disaggre- a significant overhead. We can trade the expensive VM-to- gation techniques as well as trusted libraries. The authors hypervisor transitions against context (mode) switches in of [11] propose to extend hypervisors with Inter Process the VMX root mode. Context switches are computationally (IPC) mechanisms, a concept borrowed from . not cheap, but significantly faster than VM-to-hypervisor They reason that IPC in the hypervisor becomes necessary

82 to allow the interaction with untrusted components. Sepa- 8. SUMMARY rating privileges has been proposed by the Nizza architec- In this paper, we propose to fully utilise the available hard- ture [27] which builds on top of the L4 microkernel and relies ware protection mechanisms to increase the overall trustwor- on IPC to isolate untrusted code. Also Heiser et al. [10] and thiness of a virtualised system. Further, we extend on the Peter et al. [20] aim to reduce the TCB of legacy code by existing definition of TCB and apply the terminology to the separating functionality into small servers and rely on a mi- unused hardware protection mechanisms. Finally, we point crokernel for isolation. out some obvious limitations of our design as well as com- 6.2 Hardware protection paring it to recent research in relevant areas. Many different extensions and often radical new hardware 9. REFERENCES designs have been proposed in order to improve protection [1] AMD. AMD64 Virtualization Codenamed ”Pacifica” mechanisms such as TIARA [26], AEGIS [28], as well as Technology: Secure Virtual Machine Architecture the (TPM) chip [29]. The ma- Reference Manual. Technical Report 33047 rev. 3.01, jor disadvantage of any new hardware architecture is the AMD Corporation, 2005. lack of support for legacy software as well as the cost of deployment and development effort for new software. Con- [2] Melvin J. Anderson, Micha Moffie, and Chris I. sequently, many researchers focus on less radical and thus Dalton. Towards Trustworthy Virtualisation minor changes to existing components while trying to main- Environments: Xen Library OS Security Service tain backward compatibility: Infrastructure. Technical report, Hewlett-Packard McCune et al. [17] suggest modification to the existing Laboratories, April 2007. x86 hardware to increase performance of their minimal TCB [3] Sergey Bratus, Peter C. Johnson, Ashwin code execution architecture. Their recommendations are Ramaswamy, Sean W. Smith, and Michael E. Locasto. based on the experience of their previous work [16], which The cake is a lie: privilege rings as a policy resource. unveiled performance penalties inflicted by the TPM and In VMSec ’09: Proceedings of the 1st ACM workshop restriction of the DRTM. on Virtual machine security, pages 33–38, New York, Bratus et al. [3] also suggest modification to the x86 ar- NY, USA, November 2009. ACM. chitecture in order to extend and reinterpret memory seg- [4] David Brumley and Dawn Song. Privtrans: mentation, to provide kernel security isolation. While hard- automatically partitioning programs for privilege ware enforced context isolation might be desirable, it re- separation. In SSYM ’04: Proceedings of the 13th quires recreation and reorganisation of existing applications conference on USENIX Security Symposium, pages to reflect the different contexts. 5–5, Berkeley, CA, USA, August 2004. USENIX However, they do require changes to the hardware and Association. some require significant redevelopment as well and may hin- [5] Peter M. Chen and Brian D. Noble. When Virtual Is der the execution of legacy applications. Moreover, these Better Than Real. In HOTOS ’01: Proceedings of the schemes do not take into consideration the existing hard- Eighth Workshop on Hot Topics in Operating Systems, ware protection mechanism, which could be utilised. page 133, Washington, DC, USA, May 2001. IEEE Computer Society. 7. DISCUSSION [6] Department of Defense. Trusted Computer System Evaluation Criteria, volume DoD 5200.28-STD. The assumption that a hypervisor is in exclusive control Department of Defense, December 1985. over all hardware resources and the most privilege piece of [7] Loıc Duflot, Olivier Levillain, and Benjamin Morin. code is paramount in order to express any trust assump- ¨ ACPI: Design Principles and Concerns. In Trusted tions. However, a hypervisor might be tricked into believing Computing: Second International Conference on it is in control of the physical hardware whilst in reality is Trusted Computing, Lecture Notes in Computer presented a virtualised environment by malicious code, such Science, pages 14–28. Springer, February 2009. as a root-kit [7]. Techniques such as Intel’s TXT [9] and AMD’s SVM [1], promise to mitigate this issue by autho- [8] Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel rising code before execution. Unfortunately, it is a fairly Rosenblum, and Dan Boneh. Terra: a virtual recent technology and therefore seems to have multiple im- machine-based platform for trusted computing. In plementation issues [7, 32] itself. Moreover, in the presence SOSP ’03: Proceedings of the nineteenth ACM of vulnerabilities within the hypervisor, it is increasingly im- symposium on Operating systems principles, pages portant to maintain the hypervisor’s runtime integrity [31]. 193–206, New York, NY, USA, October 2003. ACM. While our proposal is not revolutionary, we believe that [9] David Grawrock. Dynamics of a Trusted Platform. the current advances in hardware virtualisation technology Intel Press, February 2009. have created a window of opportunity to learn from mis- [10] Gernot Heiser, Kevin Elphinstone, Ihor Kuz, Gerwin takes made in the past. As described by Grawrock [9], the Klein, and Stefan M. Petters. Towards trustworthy intended privilege usage of the x86 protection scheme, has computing systems: taking microkernels to the next never been implemented. This has had a profound impact level. ACM SIGOPS Operating Systems Review, on the TCB and security of commodity OSes, which still 41(4):3–11, July 2007. effect us today. [11] Michael Hohmuth, Michael Peter, Hermann H¨artig, and Jonathan S. Shapiro. Reducing TCB size by using untrusted components: small kernels versus virtual-machine monitors. In EW 11: Proceedings of the 11th workshop on ACM SIGOPS European

83 workshop, page 22, New York, NY, USA, September [22] Ravi Sahita, Ulhas Warrier, and Prashant Dewan. 2004. ACM. Dynamic Software Application Protection. [12] Paul A. Karger, Mary Ellen Zurko, Douglas W. Benin, http://blogs.intel.com/research/trusted% Andrew H. Mason, and Clifford E. Kahn. A VMM 20dynamic%20launch-flyer-rls_pss001.pdf,April Security Kernel for the VAX Architecture. In 2009. Proceedings 1990 IEEE Symposium on Research in [23] Marvin Schaefer and Roger R. Schell. Toward an Security and Privacy, pages 2–19. IEEE Computer Understanding of Extensible Architectures for Society, May 1990. Evaluated Trusted Computer System Products. IEEE [13] KVM. Kernel-based Virtual Machine. Symposium on Security and Privacy, page 41, May http://www.linux-kvm.org, accessed January 2010. 1984. [14] Stuart E. Madnick and John J. Donovan. Application [24] Roger R. Schell and Michael Thompson. Platform and analysis of the virtual machine approach to Security: What is Lacking? Technical report, Elsevier information system security and isolation. Proceedings Science, January 2000. of the workshop on virtual computer systems, pages [25] William R. Shockley and Roger R. Schell. TCB 210–224, 1973. subsets for incremental evaluation. In Third AIAA [15] Jonathan M. McCune, Yanlin Li, Ning Qu, Zongwei Conference on , pages 131–139. Zhou, Anupam Datta, Virgil Gligor, and Adrian IEEE Computer Society, December 1987. Perrig. TrustVisor: Efficient TCB Reduction and [26] Howard Shrobe, Thomas Knight, and Andre deHon. Attestation. IEEE Symposium on Security and TIARA: Trust Management, Intrusion-tolerance, Privacy, pages 143–158, May 2010. Accountability, and Reconstitution Architecture. [16] Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Technical Report MIT-CSAIL-TR-2007-028, MIT, Michael K. Reiter, and Hiroshi Isozaki. Flicker: an May 2007. execution infrastructure for tcb minimization. ACM [27] Lenin Singaravelu, Calton Pu, Hermann H¨artig, and SIGOPS Operating Systems Review, 42(4):315–328, Christian Helmuth. Reducing TCB complexity for April 2008. security-sensitive applications: three case studies. In [17] Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, EuroSys ’06: Proceedings of the 1st ACM MichaelK.Reiter,andArvindSeshadri.HowLow SIGOPS/EuroSys European Conference on Computer Can You Go? Recommendations for Systems 2006, pages 161–174, New York, NY, USA, Hardware-Supported Minimal TCB Code Execution. April 2006. ACM. In ASPLOS XIII: Proceedings of the 13th [28] Edward G. Suh, Dwaine Clarke, Blaise Gassend, international conference on Architectural support for Marten van Dijk, and Srinivas Devadas. AEGIS: programming languages and operating systems, pages architecture for tamper-evident and tamper-resistant 14–25, New York, NY, USA, March 2008. ACM. processing. In ICS ’03: Proceedings of the 17th annual [18] Derek G. Murray and Steven Hand. Privilege international conference on Supercomputing, pages separation made easy: trusting small libraries not big 160–171, New York, NY, USA, June 2003. ACM. processes. In EUROSEC ’08: Proceedings of the 1st [29] TCG. TPM Main, Part 1 Design Principles. TCG European Workshop on System Security, pages 40–46, Specification Version 1.2 Revision 103, Trusted New York, NY, USA, March 2008. ACM. Computing Group, Portland, OR, USA, July 2007. [19] Derek G. Murray, Grzegorz Milos, and Steven Hand. [30] Rich Uhlig, Gil Neiger, Dion Rodgers, Amy L. Improving Xen security through disaggregation. In Santoni, Fernando C.M. Martins, Andrew V. VEE ’08: Proceedings of the fourth ACM Anderson, Steven M. Bennett, Alain K¨agi, Felix H. SIGPLAN/SIGOPS international conference on Leung, and Larry Smith. Intel Virtualization Virtual execution environments, pages 151–160, New Technology. Computer, 38:48–56, May 2005. York, NY, USA, March 2008. ACM. [31] Zhi Wang and Xuxian Jiang. HyperSafe: A [20] Michael Peter, Henning Schild, Adam Lackorzynski, Lightweight Approach to Provide Lifetime Hypervisor and Alexander Warg. Virtual machines jailed: Control-Flow Integrity. IEEE Symposium on Security virtualization in systems with small trusted computing and Privacy, pages 380–395, May 2010. bases. In VDTS ’09: Proceedings of the 1st EuroSys [32] Rafal Wojtczuk, Joanna Rutkowska, and Alexander Workshop on Virtualization Technology for Tereshkin. Another Way to Circumvent Intel Trusted Dependable Systems, pages 18–23, New York, NY, Execution Technology. USA, March 2009. ACM. http://invisiblethingslab.com/resources/ [21] John Scott Robin and Cynthia E. Irvine. Analysis of misc09/Another%20TXT%20Attack.pdf, published the Intel Pentium’s ability to support a secure virtual December 2009. machine monitor. In SSYM ’00: Proceedings of the 9th conference on USENIX Security Symposium, pages 10–10, Berkeley, CA, USA, August 2000. USENIX Association.

84