lue>
« back to results for ""
Below is a cache of http://velox.stanford.edu/papers/dl_osdi_02.pdf. It's a snapshot of the page taken as our search engine crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
Separating Protection and Resource Management in Operating Systems Separating Protection and Resource Management in
Operating Systems
David Lie
Chandramohan A. Thekkath
Mark Horowitz
May 17, 2002
Abstract
Traditionally, operating systems have fullled the
dual roles of enforcing security on computer sys-
tems, as well as managing and virtualizing re-
sources for the various applications sharing the ma-
chine. However, more recently, there have been some
promising proposals in creating systems where hard-
ware, rather than software enforces security and pro-
tection. These proposals would require an operat-
ing system running on such hardware to manage re-
sources on behalf of applications that do not trust it.
Unfortunately, the implementation of such an oper-
ating system has not received much attention in the
literature and it is not clear if a traditional services of
an operating system could be provided on such hard-
ware. This paper discusses the modications that are
necessary to make a modern operating system exe-
cute on such hardware. The modications were mod-
est, the most signicant changes were in the areas
that perform context switches, signal handling, and
virtual memory management.
1
Introduction
There are good reasons for developing techniques
for creating tamper resistant software. Not only can
tamper resistant software be used to combat soft-
ware piracy, but it is also useful in situations where
a portable device containing sensitive software and
data may fall into the hands of adversaries. It can en-
able mobile code to run on untrusted systems without
the fear of tampering or intellectual property theft. In
the past, software techniques for preventing tamper-
ing have been studied, but with limited success [2].
More recently, there have been some promising ad-
vances in creating systems where hardware, rather
than software is used to enforce the security and pro-
tection of code [3, 4, 9, 10, 15, 17]. These processors
provide a platform for secure execution.
A protection model based on a secure execution
platform fundamentally alters the role of the oper-
ating system that must execute on it. Traditionally,
both protection and resource management have been
the domain of operating systems. When the protec-
tion model places the burden of trust in the hardware,
the question arises as to how an operating system
can still manage resources on behalf of application
processes that do not trust it. Some evidence of this
trend already exists in the form of I/O devices that do
not trust their client operating systems [11, 16].
In this paper, we will discuss the implications
a platform that provides hardware based protection
has on the operating system.
This discussion is
based on our experience with separating protection
and resource management in a standard UNIX oper-
ating system executing on a secure execution plat-
form. In studying secure execution platforms, we
nd that much of the hardware used to implement
the platform has similar characteristics [3, 4, 9, 10].
We report our experimental results with one such
platformthe XOM processor described in [10].
A XOM processor provides protection for execut-
ing programs by placing them in separate compart-
ments [13]. The separation of compartments is en-
forced by the use of encryption. The processor has
a public/private key pair, where the private key is
embedded in the hardware and accessible only to
the processor. Each compartment has a symmetric
cryptographic key, called the compartment key, as-
sociated with it. Program code is encrypted using
a secretly chosen symmetric key, which in turn is
1 encrypted with the public key of the XOM proces-
sor. Before execution, the encrypted code key is pre-
sented to the XOM processor, which decrypts it and
makes it the compartment key of the program. The
program is then referred to as executing within its
compartment. The processor is said to be in XOM
mode while it is executing a program in a private
compartment.
Because the operating system is not trusted by ap-
plication processes running on a XOM processor, it
runs in a compartment separate from user processes.
However, to share hardware resources amongst a set
of processes, the operating system must be able to
preempt a process, as well as save and restore its con-
text. To support preemption and context-switching,
the XOM processor distinguishes the action of sav-
ing and restoring data, from the action of reading or
modifying data. With this support, a correctly writ-
ten operating system can save and restore data, but
even a malicious operating system cannot read or
modify data belonging to a user process. This sepa-
ration is maintained by ensuring that any values that
an operating system tries to save are encrypted rst.
Likewise, the XOM processor ensures that values the
operating system tries to restore have been properly
encrypted and have not been subsequently tampered
with. The XOM processor employs cryptographic
ciphers and hashes to this end.
Main memory is not trusted by the XOM proces-
sor either. The XOM processor stores cryptographic
hashes along with encrypted values in memory and
will only accept encrypted values from memory if
accompanied by a valid hash. The hash not only pro-
tects the actual value of the data, but saves the virtual
address that the data was stored to by the application,
thus ensuring that an adversary cannot copy or move
data from one location to another. While the appli-
cation does not trust the operating system to create
these hashes, it does require the operating system to
manage the storage of these hashes so that an appli-
cation may access data it has stored to memory.
In principle, an operating system should be able
to virtualize and manage resources without having
to interpret any of the values it is moving, but there
are obstacles to supporting many of the paradigms
that modern UNIX operating systems support, such
as signal handlers, memory management, process
creation and so on. In addition, resources used to
store the cryptographic hashes that the XOM ma-
chine needs to ensure data integrity, must also be
managed. To explore these matters further we used
the SimOS [6] simulation system to model a XOM
processor. We modied a SimOS model of an in-
order processor using the MIPS R10000 [5] instruc-
tion set to behave as a XOM processor. The IRIX
6.5 [14] operating system from SGI was then mod-
ied to boot and run XOM applications in SimOS.
With the experiments performed on this simulation
platform, we demonstrate that it is possible to sepa-
rate resource management from security in an oper-
ating system and estimate the performance overhead.
We also note that the XOM architecture does pre-
clude a set of services that an operating system may
wish to provide. For example, it would be impossible
to perform debugging or proling on XOM-secured
code since there is no way to distinguish between
a legitimate user trying to gather information, and
an adversary trying to extract secrets. On the other
hand, we demonstrate that despite the operating sys-
tem being able to manage system resources, an ac-
tively malicious operating system will still only be
able to gather a limited amount of information about
a client application. The only attack that a malicious
operating system will be able to mount is a denial of
service attack. Because of its resource management
role, the operating system will always be able to pre-
vent an application from making forward progress,
but it will never be able to alter application behavior
in such a way that it leaks undesired information.
Section 2 rst describes the basic hardware inter-
face a XOM processor presents to the processes and
operating system running on it. Section 3 gives an
overview of how an operating system runs a XOM
application. Section 4 details the modications that
are essential to making an operating system work
correctly on XOM hardware and Section 5 describes
the engineering and performance overheads of our
implementation. Section 6 outlines future work and
operating system modications that could be made
to either enhance performance or provide more func-
tionality for processes. Finally, Section 7 presents
our conclusions.
2 2
Hardware Overview
In this section, we describe the interface that a XOM
processor presents to the software. For the most part,
a XOM processor behaves like a typical modern pro-
cessor. However, there are some characteristics that
differentiate XOM processors. The operating system
and other processes can access this additional func-
tionality through a set of