How Low Can You Go?Recommendations for Hardware-SupportedMinimal TCB Code Execution∗Jonathan M. McCune† Bryan Parno† Adrian Perrig† Michael K. Reiter‡ Arvind Seshadri††Carnegie Mellon University‡University of North Carolina at Chapel HillAbstractWe explore the extent to which newly available CPU-based secu-rity technology can reduce the Trusted Computing Base (TCB) forsecurity-sensitive applications. We find that although this new tech-nology represents a step in the right direction, significant perfor-mance issues remain. We offer several suggestions that leverageexisting processor technology, retain security, and improve perfor-mance. Implementing these recommendations will finally allow ap-plication developers to focus exclusively on the security of their owncode, enabling it to execute in isolation from the numerous vulnera-bilities in the underlying layers of legacy code.Categories and Subject DescriptorsC.4 [Performance of Systems];D.2.11 [Software Architectures]; K.6.5 [Security and Protection]General Terms Measurement, Design, SecurityKeywords Trusted Computing, Late Launch, Secure Execution1. IntroductionThe architecture of today’s computer systems is layered, with appli-cations forming the highest layer and the hardware forming the low-est. With the layered architecture, each application’s Trusted Com-puting Base (TCB), and hence security, depends on many layers ofcode, including the system firmware (BIOS), the firmware of vari-ous peripheral devices, the bootloader, the OS kernel, and the appli-cation’s own code. With the trend towards increasingly feature-richand complex systems, the code size and complexity of each layer hasgrown tremendously. For example, today’s OSes consist of severalmillion lines of code and support a wide variety of hardware plat-forms. With the explosion in size and complexity of an application’sTCB, securing applications has become a daunting task.∗This research was supported in part by CyLab at Carnegie Mellon undergrant DAAD19-02-1-0389 from the Army Research Office, and grants CNS-0509004, CT-0433540 and CCF-0424422 from the National Science Foun-dation, by the iCAST project, National Science Council, Taiwan under theGrants No. (NSC95-main) and No. (NSC95-org), and by a gift from AMD.Bryan Parno is supported in part by a National Science Foundation Gradu-ate Research Fellowship. The views and conclusions contained here are thoseof the authors and should not be interpreted as necessarily representing theofficial policies or endorsements, either express or implied, of AMD, ARO,CMU, NSF, or the U.S. Government or any of its agencies.Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. To copy otherwise, to republish, to post on servers or to redistributeto lists, requires prior specific permission and/or a fee.ASPLOS’08,March 1–5, 2008, Seattle, Washington, USA.Copyrightc 2008 ACM 978-1-59593-958-6/08/03. . . $5.00On a modern computing device, the minimal TCB for executinga piece of code consists of the CPU, the memory, and the interfacebetween them. The challenge then is to develop an architecture thatexecutes application code while relying only on this mandatory TCB,yet simultaneously maintains compatibility with the existing layeredsystems architecture.In earlier work [16, 17], we proposed a Secure Execution Archi-tecture (SEA)1that executes the security-sensitive code of an appli-cation while trusting only the mandatory TCB and a Trusted PlatformModule (TPM). SEA achieves this property by executing an applica-tion’s security-sensitive code in isolation from all other software onthe system. The isolation is achieved using the CPU-based isolationtechnologies present in modern commodity CPUs from AMD andIntel, namely AMD’s Secure Virtual Machine (SVM) technology [1]and Intel’s Trusted Execution Technology (TXT) [11].In this paper, we evaluate the performance of SEA on commoditysystems. Unfortunately, SVM and TXT were designed for extremelyinfrequent usage, say once per boot cycle. As a result, we find that theSEA approach on current hardware suffers from performance issuesthat undermine its appeal. Fortunately, our investigation also revealsthat by combining alterations to SEA with hardware modificationsto improve performance and concurrency, we can achieve efficientminimal TCB code execution. In other words, we can execute appli-cation code while trusting only the mandatory TCB and avoid today’sperformance issues.Although other researchers have proposed compelling hardwaresecurity architectures, e.g., XOM [14] or AEGIS [23], we focus onhardware modifications that tweak or slightly extend existing hard-ware functionality. We believe this approach offers the best chanceof seeing hardware-supported security deployed in the real world.Through a series of experiments on existing commodity hardware,we show that our recommendations promise significant performanceimprovements.In summary, this paper makes the following contributions:•We specify the hardware requirements for executing applicationcode with a minimal mandatory TCB.•Using our own implementation of primitives for minimal TCBcode execution, we show that current hardware renders it imprac-tical, e.g., paralyzing the processor for a full second to set up atrusted execution session.•We recommend modifications of commodity hardware to se-curely improve the performance and concurrency of SEA. In ourrecommendations, we seek to minimize the changes required,thereby increasing the likelihood of their adoption.1We present a list of acronyms in the appendix.142. BackgroundWe provide information on the hardware technologies we explore.2.1 Trusted Platform Modules (TPMs)The TPM is a chip designed by the Trusted Computing Group tostrengthen platforms against software attack [25].2.1.1 TPM-Based AttestationA computing platform containing a Trusted Platform Module (TPM)can provide an attestation or quote—essentially a digital signature onthe current platform state—to an external entity. The platform stateis detailed in a log of software events, such as applications startedor configuration files used. Each event is reduced to a measurement,m, using a cryptographic hash function, H. The hash value is storedin one of the TPM’s