Princeton COS 592 - Implementing an Untrusted Operating System

Unformatted text preview:

Implementing an Untrusted Operating System on TrustedHardwareDavid LieDept. of Comp. and Elec. Eng.University of TorontoToronto, ONT M2J 1A2Chandramohan A. ThekkathMicrosoft Research1065 La AvenidaMountain View, CA 94043Mark HorowitzComputer Systems Lab.Stanford UniversityStanford, CA 94305ABSTRACTRecently, there has been considerable interest in providing“trusted computing platforms” using hardware — TCPAand Palladium being the most publicly visible examples. Inthis paper we discuss our experience with building such aplatform using a traditional time-sharing operating systemexecuting on XOM — a processor architecture that providescopy protection and tamper-resistance functions. In XOM,only the processor is trusted; main memory and the operat-ing system are not trusted.Our operating system (XOMOS) manages hardware re-sources for applications that don’t trust it. This requires adivision of responsibilities between the operating system andhardware that is unlike previous systems. We describe tech-niques for providing traditional operating systems servicesin this context.Since an implementation of a XOM processor does notexist, we use SimOS to simulate the hardware. We modifyIRIX 6.5, a commercially available operating system to cre-ateXOMOS.Wearethenabletoanalyzetheperformanceand implementation overheads of running an untrusted op-erating system on trusted hardware.Categories and Subject DescriptorsD.4.6 [Operating Systems]: Cryptographic Controls, Ac-cess Controls; D.4.1 [Operating Systems]: Process Man-agement; C.1.0 [Processor Architectures]: GeneralKeywordsXOM, XOMOS, Untrusted Operating SystemsGeneral TermsSecurityPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SOSP’03, October 19–22, 2003, Bolton Landing, New York, USA.Copyright 2003 ACM 1-58113-757-5/03/0010 ...$5.00.1. INTRODUCTIONThere are several good reasons for creating tamper-res-istant software including combating software piracy, enablingmobile code to run on untrusted platforms without the riskof tampering or intellectual property theft, and enabling thedeployment of trusted clients in distributed services such asbanking transactions, on-line gaming, electronic voting, anddigital content distribution. Tamper-resistant software isalso useful in situations where a portable device containingsensitive software and data may fall into the hands of adver-saries, and in preventing viruses from modifying legitimateprograms.Tamper-resistance can be enforced using software or hard-ware techniques. In the past, techniques such as software ob-fuscation have been explored, but with limited success [4].There is a widespread belief that software-based solutionsare relatively easier to attack than hardware-based solu-tions [3]. Thus, there have been several proposals for creat-ing systems that rely on hardware, rather than on softwareto enforce the security and protection of programs [10, 11,14, 17, 27, 29].Trusting the hardware rather than the software has in-teresting implications for operating systems design. Sincesharing hardware resources among multiple users is a diffi-cult task, often requiring complex policy decisions, it is mostnaturally done in software by an operating system. But, ifone is reluctant to trust anything but the hardware, thenwe must somehow arrange for an untrusted agent—the op-erating system software—to manage a trusted resource—thehardware.This paper explores the design of an operating system thatruns on hardware that supports tamper-resistant software.Our operating system is intended to work with an existingprocessor architecture called XOM, which stands for eXe-cute Only Memory [17]. In the XOM processor architec-ture, programs do not trust the operating system or externalmemory, but instead, trust the processor hardware to pro-tect their code and data. In trying to design the operatingsystem for the XOM processor, we found difficulties withthe original architectural specification that made it imprac-tical to provide certain operating system facilities, such astime-slicing, process forking, and user-level signal handling.This paper describes the design changes in the operatingsystem and the architecture that were required to build afunctioning system.There is currently no hardware implementation of theXOM architecture. We therefore modify the SimOS [22]simulation system to model a XOM processor, based on anin-order processor model using the MIPS R10000 [12] in-struction set. XOMOS is implemented by modifying theIRIX 6.5 [25] operating system from SGI. Using XOMOSwe can execute XOM-protected (and ordinary) programs.Our experiments demonstrate that it is possible to write anoperating system that not only manages resources for ap-plications that do not trust it, but also supports most, butnot all, of the traditional services that one expects from anoperating system.The rest of the paper is organized as follows. Section 2describes the XOM trust model and its implications for op-erating systems design in more detail. Section 3 describesrelated work. Section 4 provides background and summa-rizes the basic processor architecture originally describedin [17]. Supporting an operating system on this interface re-quired significant software and hardware co-design, resultingin several changes to IRIX and the instruction set architec-ture. These changes are described in Section 5. Section 6describes the implementation effort required to create XO-MOS, and discusses the implementation and performance ofmicro-benchmarks as well as two secure applications runningon XOMOS: RSA operations in OpenSSL and mpg123, anMP3 decoder. In Section 7, we discuss how XOM supportsmany of the primitives that trusted computing platformssuch as TCPA and Palladium provide. Finally, we presentour conclusions in Section 8.2. THE XOM TRUST MODELXOM can protect against a sophisticated attacker whomay even have physical access to the hardware. In thisscenario, the attacker either tries to extract secrets froma program by observing its operation, or she tries to tamperwith the program’s operation to make it reveal secrets. Tothis end, the attacker may exploit weaknesses


View Full Document

Princeton COS 592 - Implementing an Untrusted Operating System

Download Implementing an Untrusted Operating System
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Implementing an Untrusted Operating System and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Implementing an Untrusted Operating System 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?