System Design

focus

building software securely

EROS: A Principle-Driven

Operating System from the

Ground Up

Jonathan S. Shapiro, Johns Hopkins University

Norm Hardy, Agorics, Inc.

he Extremely Reliable Operating System1 is a capability-based op-

T erating system designed to support the security and reliability

needs of active systems. Users of active systems can introduce and

run arbitrary code at any time, including code that is broken or

even hostile. Active systems are shared platforms, so they must simultaneously

support potentially adversarial users on a single machine at the same time.

Because active systems run user-supplied uncompromisingly principle-driven. Wher-

code, we cannot rely on boundary security ever a desired feature collided with a secu-

Design principles are to keep out hostile code. In the face of such rity principle, we consistently rejected the

highly advocated code, EROS provides both security and per- feature. The result is a small, internally con-

in software formance guarantees (see www.eros-os.org sistent architecture whose behavior is well

construction for downloadable software). An application specified and lends itself to a careful and ro-

that executes hostile code (such as viruses) bust implementation. Second, the system s

but are rarely

cannot harm other users or the system as a lead architects had prior experience as

systematically

whole and cannot exploit a user s authority processor architects. This helped us avoid

applied. The

so as to compromise other parts of the user s certain kinds of abstraction that modern op-

authors describe

environment. erating systems generally include and seek a

the principles on

The EROS project started as a clean- design that maps directly onto the features

which they built an

room reimplementation of KeyKOS,2 an op- that modern hardware implementations

operating system erating system Norm Hardy and his col- provide; very little performance is lost in

from the ground leagues created for the IBM System/370 (see translating abstractions.

up, and how those www.cis.upenn.edu/ KeyKOS for earlier Figure 1 shows the core EROS design prin-

principles affected documents from the KeyKOS system). The ciples. Jeremy Saltzer and Michael Schroeder

the design, key contributions of EROS are formal veri- first enumerated many of these in connection

with the Multics project3 and incorporated

application fication of some of the architecture s critical

security properties and performance engi- others based on our experiences from other

structure, and

neering. These security and performance ca- projects (see the Related Work sidebar).

system security

pabilities come from two sources. There are no magic bullets in the principles

and testability.

First, the primary system architecture is we adopted for EROS. The system s perform-

26 IEEE SOFTWARE January/February 200*-****-****/02/$17.00 2002 IEEE

Principles from the Multics Project

Economy of mechanism: Keep the design as simple as possible.

I

Fail-safe defaults: Base access decisions on permission rather

I

ance and design coherency results solely from than exclusion.

finding better ways to adhere consistently to Complete mediation: Check every access for authority.

I

these principles at fine granularity without Open design: The design should not be secret. (In EROS, both

I

sacrificing performance. design and implementation are public.)

We maintained strong adherence to de- Least privilege: Components should have no more authority

I

sign principles in the EROS/KeyKOS design than they require (and sometimes less).

for three reasons: Least common mechanism: Minimize the amount of shared

I

instances in the system.

We wanted to know that the system

I

Commonly accepted principles

worked and why it worked. Unless you

can trace each piece of the system code I Separation of policy and mechanism: The kernel should im-

back to a motivating principle or a neces- plement the mechanism by which resource controls are en-

sary correctness constraint, achieving this forced but should not define the policy under which those

is difficult. Traceability of this type is also controls are exercised.

required for high-assurance evaluation. I Least astonishment: The system s behavior should match

I We expected that a clean design would what is naively expected.

lead to a high-performance implementa- I Complete accountability: All real resources held by an appli-

tion. Based on microbenchmarks, this cation must come from some accounted pool.

expectation has been validated.1 I Safe restart: On restart, the system must either already have,

I We wanted to formally and rigorously or be able to rapidly establish, a consistent and secure execu-

verify some of the security mechanisms tion state.

on which the system relies. A rigorous I Reproducibility: Correct operations should produce identical

verification of the EROS confinement results regardless of workload.

mechanism, which is a critical security

Principles specific to EROS

component in the system, was recently

completed.4 I Credible policy: If a security policy cannot be implemented by

correct application of the system s protection mechanisms, do

This article provides some examples of not claim to enforce it.

how these principles affected the EROS sys- I No kernel allocation: The kernel is explicitly prohibited from

tem design. We also describe the application creating or destroying resources. It is free, however, to use

structure that naturally emerged in the re- main memory as a dynamic cache for these resources.

sulting system and how this affected the sys- I Atomicity of operations: All operations the kernel performs

tem s security and testability. are atomic either they execute to completion in bounded

time, or they have no observable effect.

The EROS kernel design I Relinquishable authority: If an application holds some au-

The most direct impact of design princi- thority, it should (in principle) be able to voluntarily reduce

ples in EROS is in the kernel s structure and this authority.

implementation. In several cases, our strict I Stateless kernel: The system s security and execution state

adherence to design principles led to un- should logically reside in user-allocated storage. The kernel is

usual design outcomes, some of which we free to cache this state.

discuss here. (Except where made clear by I Explicit authority designation: Every operation that uses au-

context, references to the EROS system thority should explicitly designate the source of the authority

throughout the article refer interchangeably it is using.

to both EROS and KeyKOS.)

Figure 1. Core EROS

Safe restart

1. The consistency checks are heuristic, design principles.

In secure systems, we must ensure that the

system has restarted in a consistent and se- which makes establishing their correct-

cure state. In most operating systems, there ness difficult. The Unix fsck command,

is an initial set of processes that the kernel for example, must decide which files to

specially creates. These processes perform throw away and which to keep without

consistency checks, reduce their authorities knowing how these files interrelate. Con-

to their intended steady-state authority, and sequently, the state of the group and

then initiate the rest of the programs in the password files might not be consistent

system. This creates two problems: with each other.

27

January/February 2002 IEEE SOFTWARE

Related Work 2. The initial processes receive their author-

ity by means that are outside the normal

Henry Levy1 and Ed Gehringer2 provide overviews of several capability mechanisms of granting or transferring

systems. EROS borrows ideas directly from three prior capability systems. Like authority. The designers must make spe-

Hydra,3 EROS is an extensible capability system. Programs can implement cialized arguments to demonstrate that

new objects that protected capabilities invoke. Like CAL/TSS,4 EROS unifies the system appropriately manages and

processes with protection domains. EROS designers also took to heart most of diminishes this authority. The complex-

the design lessons reported from the CAL/TSS project. The Cambridge CAP ity of these arguments is comparable to

computer,5 while implemented in hardware, similarly used fine-grain capabili- the complexity of the correctness argu-

ties for memory protection. It s also the first example of a stateless kernel. ments for the remainder of the system.

EROS uses kernel-protected capabilities. An alternative Amoeba6 uses

treats capabilities as data, using unguessably sparse allocation for protec- EROS resolves both issues by using a

tion. This approach does not support confinement, because it is impossible transacted checkpointing system. The sys-

to determine which bits of the application represent data and which repre- tem periodically takes an efficient, asyn-

sent capabilities. chronous snapshot of the entire state of

Simple cryptographic or signature schemes share this problem. One solu- the machine, performs a consistency check

tion is password capabilities as used in Monash7 and Mungi,8 which apply on this state, and then writes it down as a

a system-defined XOR before accepting capabilities. A concern with this ap- single disk transaction. Because the system

proach is that any operation simple enough to be efficient (such as XOR) is is transacted as a whole, no possibility of

easily reverse-engineered. True cryptographic checks must be cached to global inconsistency exists. On restart, the

avoid prohibitive computational cost. system simply reloads the last completed

transaction. System installation consists of

References writing (by hand) an initial system image;

1. H.M. Levy, Capability-Based Computer Systems, Digital Press, 1984. the processes of this system image have no

2. E.F. Gehringer, Capability Architectures and Small Objects, UMI Research Press, Ann Arbor, unusual authority.

Mich., 1982.

3. W.A. Wulf, R. Levin, and S.P. Harbison, HYDRA/C.mmp: An Experimental Computer Sys-

Stateless kernel

tem, McGraw Hill, New York, 1981.

EROS is a stateless kernel the system s

4. B.W. Lampson and H.E. Sturgis, Reflections on an Operating System Design, Comm.

ACM, vol. 19, no. 4, May 1976, pp. 251 265. execution state resides in user-allocated

5. M.V. Wilkes and R.M. Needham, The Cambridge CAP Computer and its Operating System,

storage. The kernel achieves performance

Elsevier, North Holland, 1979.

by caching this state. A caching design facil-

6. A.S. Tannenbaum, S.J. Mullender, and R. van Renesse, Using Sparse Capabilities in a Dis-

itates checkpointing and imposes a depend-

tributed Operating System, Proc. 9th Int l Symp. Distributed Computing Systems, IEEE Press,

Piscataway, N.J., 1986, pp. 558 563.

ency tracking discipline on the kernel. To

7. M. Anderson, R. Pose, and C.S. Wallace, A Password Capability System, The Computer

ensure that user-allocated storage always re-

J., vol. 29, no. 1, 1986, pp. 1 8.

veals correct values when examined, the

8. G. Heiser et al., Mungi: A Distributed Single Address-Space Operating System, Proc.

kernel must be able to restore this state on

17th Australiaision Computer Science Conf., ACM Press, New York, 1994, pp. 271 280.

demand. These dependencies provide a

form of self-checking. The kernel can some-

times compare its cached state to the user

state to detect whether the runtime kernel

Node capability

state has become inconsistent, preventing a

Node

bad state from transacting to disk.

0 31

EROS does not publish a memory map

abstraction, because this would violate the

Node

Node stateless kernel principle. Instead, EROS re-

0 31

0 31

quires that the applications explicitly allo-

cate all of the pieces that comprise the map-

ping structure. Figure 2 shows a small

EROS address space. The application ex-

plicitly allocates (typically by a user-level

Pages fault handler) every node and page in this

address space. The kernel builds the hard-

Page capability

ware-memory-mapping tables by traversing

Void capability

this structure and caching the results in the

Figure 2. An EROS Node capability

hardware-mapping tables.

address space.

28 IEEE SOFTWARE January/February 2002

Table 1

Protection properties of capabilities

Conventional systems Capability systems

Complete mediation Based on (User, object) pair Per-process capabilities

In EROS, resources include pages of Lookup by rights(Object, process.user) rights(process[cap ndx])

memory, nodes (fixed-size arrays of capabil- Authority grant Program run by owning user can Can transfer if an authorized path

ities), CPU time, network connections, and grant authority to anyone of communication exists

anything that is built out of these. Every Name resolution String lookup (via open) Direct designation

individual page, node, or other resource is

named by one or more capabilities. Each ca-

Explicit designation

pability names an object that is implemented

by the kernel or another process in a sepa- In EROS, we can trace every operation a

rate address space. Capabilities are the only program performs to some authorizing ca-

means of invoking operations on objects, pability. If a line of code performs an oper-

and the only operations that can be per- ation that modifies an object, the capability

formed with a capability are the operations to that object is explicitly identified in the

authorized by that capability. This means procedure call arguments. Because this is

that every resource is mediated and fully en- true, there is never any ambiguity about

capsulated. In most cases, a client cannot how and why the operation was permitted,

distinguish between system objects and ob- and it becomes much harder for hostile

jects that the server software implements. clients to entice services into misusing their

We can thus view an EROS system as a sin- authority. Even the right to execute instruc-

gle large space of protected objects. Table 1 tions is not innate an application that does

illustrates some of the key differences be- not hold a schedule capability does not exe-

tween capability systems and current con- cute instructions (least authority).

ventional systems.

Credible policy

Complete accountability This principle might be restated as bad

Although many systems claim complete security drives out good and is best illus-

accountability as a goal, few actually imple- trated by example. A commonly desired se-

ment it at the kernel level. Failures of kernel curity policy is, Fred shouldn t have access

accountability commonly take two forms: to this object. Unfortunately, if program A

has a capability letting it speak to program B,

The kernel might fail to account for ker- and A also has a capability to some resource

I

nel metadata. Mapping metadata is par- R, then A is in a position to access R on be-

ticularly hard to account for, because half of B (that is, to act as a proxy). If two

there is no direct correlation between programs can communicate, they can col-

the number of pages mapped and the lude. An Interface Definition Language (IDL)

amount of required metadata on most compiler can automatically generate the code

hardware. to do so. The only way to really prevent

I The kernel might account for synthesized Fred s access is to isolate his programs com-

resources rather than real resources. A pletely from all other programs, which is gen-

process consists of two nodes. Because erally not the policy that people want.

they are not a fundamental unit of stor- Because of this, EROS does not attempt

age, EROS does not maintain a separate to prevent the transmission of capabilities

quota category for processes. over authorized channels. Security is not

achieved by preventing this copy. EROS

In EROS, all space-consuming resources stops programs from colluding if there is no

are in terms of two atomic units of stor- authorized communication path between

age nodes and pages and these are the them, but its goal is to ensure that such

units that are accounted for. Applications paths cannot arise. We have yet to identify a

explicitly perform all object allocations, feasible security policy that cannot be im-

and user-level fault handlers handle page plemented this way.

faults. This is because a new page might

Least astonishment

need to be allocated to service the page

fault, and the kernel can t know the re- For the most part, we can implement the

source pool from which the new page principles shown in Figure 1 without con-

should come. flict. One exception is the principle of least

29

January/February 2002 IEEE SOFTWARE

User file space

Open/ Word processor to hold the entire file. The file application s

Edit buffer

save-as application view

tool Shell responsibility is to implement operations

container

such as read and write that act on the file.

(Trusted Non-TCB

The checkpoint mechanism provides stabi-

Computing Non-TCB Interface Non-TCB

Base) Interface Interface lization. Because a distinct object implements

Interface

each file, this implementation maintains the

principle of least common mechanism.

Window system

This design pattern creating higher-

level functions by composing the underlying

primitives of the operating system in

Figure 3.

astonishment, which is violated in the capa- reusable components is the basic strategy

Components

bility invocation specification. If a process for building EROS applications. A separate

connected by

specifies an undefined address as the desti- process implements each component instance,

capabilities.

nation of an incoming data string, the kernel and the kernel provides a high-performance

will truncate the message rather than let the interprocess communication mechanism

fault handler for that region run. The prob- that enables these components to be effi-

lem is that messages are unbuffered (as re- ciently composed. In fact, it is rare for

quired by the stateless kernel principle), the EROS applications to manipulate kernel-

fault handler is untrusted, and the process supplied objects directly. Most applications

sending the message might be a shared serv- reuse components that the system supplies

ice. A denial-of-service attack against the or implement new components that provide

service can be constructed by providing a a needed function in a structured way. This

fault handler that never returns. The kernel naturally leads programmers to apply the

therefore truncates the message rather than principle of least privilege in their applica-

risk a denial of service. tion designs, because these components are

This is astonishing to such a degree that designed to use only the capabilities they

one conference publication has cited it as a need.

design flaw. On examination, there is a fun-

Application structure

damental collision of principles in this area,

and there are only three possible resolu- EROS applications are structured as pro-

tions: buffering, timeouts, or truncation. tected, capability-connected components

Buffering violates several design principles (see Figure 3). Each instance of a component

(stateless kernel, least common mechanism, runs with individually specified capabilities

complete accountability, and no kernel allo- that define its authority. Capabilities are ker-

cation), and timeouts preclude repeatability nel protected, as are the objects they desig-

under heavy load. So, given that a well- nate. The only operations that can be per-

intentioned application is always in a position formed with a capability are the operations

to provide a valid receive region, truncation the object defines. Because of this combina-

appears to be the least offensive strategy for tion of protection and mediation, an appli-

preventing denial of service. cation that executes hostile code (such as a

virus) cannot harm the system as a whole or

Component-based applications other users and can t exploit the user s au-

We now turn our attention to the struc- thority to compromise other parts of the

ture of EROS applications. It is now hope- user s environment. Similarly, capabilities

fully clear that the facilities the EROS ker- control access to resources, preventing hos-

nel directly provides are relatively low-level. tile code from overconsuming resources and

Application code implements most of the making the rest of the system unusable.

system functions even trusted functions. In Figure 3, the word processor is fac-

For example, the EROS kernel directly tored into a container component and indi-

provides pages of disk storage but not a file vidual editing components. The container

system. The file abstraction is built entirely at component has access to the user s file sys-

the application level (separation of mecha- tem only through a trusted open/save-as

nism and policy), and the file application dialog system, but the editing components

simply stores the file content in an address have no access to the user s file system.

space, growing the address space as necessary While the word processor has nontrusted

30 IEEE SOFTWARE January/February 2002

access to the window system, the open/save-as the original application didn t actually use

tool has access through a special, trusted in- that authority. A Unix-based email reader

Because they

terface. The window system decorates has the authority to overwrite any file that

trusted components with different window the user can overwrite. The reader doesn t

tend to be small

decorations, letting users know that they are do this because the program is well-behaved,

and well

interacting with a component that has po- but when a virus takes over the email

tentially sensitive authority. reader, it can run any code that it wishes,

isolated, EROS

usually with the full authority of the user

components

Testability and defense in depth running the application. In a capability sys-

also tend to be

Designing applications as compositions tem, this is not true.

of small components simplifies testing. Due

easily tested.

Constructors

to complete mediation, each component can

be invoked only through its intended inter- Closely related to the EROS component

face. Because they tend to be small and well model is a generic system utility component

isolated, EROS components also tend to be called the constructor. When a developer

easily tested. A well-written test suite can writes code for a new component, she needs

typically reproduce and test all the states some mechanism to instantiate new copies

that are actually reachable by client code. of this component. This is the constructor s

An IDL compiler commonly generates ex- job. There is a distinct constructor for each

ternal interfaces to components, which type of object in the system. To instantiate

largely eliminates the risk of buffer overrun an object, the client invokes a capability to

attacks. Because each component has a its constructor.

well-defined, protected interface, it is often The constructor s second, more impor-

possible to deploy new component versions tant task is to prevent information leakage.

into the field and test them against real ap- One of the key questions that a programmer

plications by running them side by side with would like to ask about a component is, If

the current working version and comparing I were to create one of these components

the results. and give it some vital piece of information,

Mediated components and least privilege could the information be disclosed without

also make the propagation of viruses more my permission? The constructor can deter-

difficult. Compromising any single compo- mine whether the component it creates is

nent doesn t really buy the attacker very leak free.

much, because the component s actions are This is possible because all of a compo-

restricted by the capabilities it can invoke. nent s possible actions are determined by

Assuming that an attacker does compromise the capabilities that the component initially

some part of the system, he has no readily holds. If these initial capabilities are (transi-

exploited communication path by which to tively) read-only, then the only way the

expand the compromise. All his interactions component can communicate is by using ca-

with the rest of the system are constrained pabilities supplied by the program creating

by the protocols defined at the capability the component. Such a component is said to

be confined.5 As long as the creator is selec-

boundaries. Unlike firewalls, which must

operate at the network level with relatively tive in giving capabilities to the new compo-

little knowledge of the application state, the nent, information cannot leak. Because the

capability interfaces operate at the applica- constructor creates the component in the

tion level with narrowly defined component- first place, it is in a position to know all the

specific interfaces. This provides the system capabilities that the component holds and

overall with a type of defense in depth therefore can certify the component s safety.

that is difficult (perhaps impossible) to In spite of its security features, the construc-

achieve in applications that are structured as tor creates new processes very quickly. In

a single, undifferentiated address space. practice, we find that programmers use con-

Contrast this with current systems. Once structors as the generic program instantia-

something compromises a piece of an appli- tion tool for all programs (whether or not

cation, the entire application is compro- they are confined).

mised. As a result, the virus gains all the au- Surprisingly, the all capabilities must be

thority that the application holds even if transitively read-only restriction is almost

31

January/February 2002 IEEE SOFTWARE

always enough. To date, the only applica- email agents, and word processors. In cur-

tions we have seen that can t be straightfor- rent software, the refactoring points in these

The use of wardly built under this restriction are things applications often already exist and are eas-

like networking subsystems. The network ily modified. Word processors, for example,

capabilities and subsystem needs access to external devices, typically open files for writing only after

transparent and because of this, it is necessarily a poten- putting up some form of a file dialog box.

tial source of information leakage. The whole Modifying the dialog box mechanism to be a

persistence point of a network, after all, is to leak infor- protected subsystem and return an open de-

distinguish mation. Leaky programs aren t inherently scriptor rather than a string would go a long

EROS from most bad, but they must be carefully examined. way toward eliminating macro viruses.

The constructor is therefore the key to Comparable protection can t be achieved by

other operating safely executing untrusted code. If untrusted access control lists in an access control list

systems. code is executed within a confinement bound- system, the application runs with the same

ary, it can t communicate with the rest of authority as the user.

the system at large. Although resource at-

Trusting the user interface

tacks (on the CPU or space, for example)

are possible, we can restrict both the CPU The preceding discussion glosses over an

time and space allocated to a confined sub- important point. As a user, how do I know

system. This means, for example, that a that I am talking to the real file dialog box?

Web browser might be designed to instanti- This is a trusted user interface design issue,

ate a new HTML rendering component for and although work has been done on this, it

each page. Within this component, it is per- isn t a simple problem. A capability-based

fectly safe to run untrusted scripting code, design helps, because, for example, the win-

because the component as a whole is con- dow system can implement distinguished

fined. The scripting code therefore does not trusted and untrusted interfaces (see Figure

have access to anything sensitive. 3) and decorate trusted windows in a user-

visible way. Because capabilities are un-

Costs and benefits forgeable, an untrusted application cannot

The use of capabilities and transparent contrive to appear trustworthy. In two short

persistence distinguish EROS from most sentences, we have reduced the problem of

other operating systems. Although compo- application security to properly designing

nent-based designs are well accepted, they the file dialog and ensuring the operating

require restructuring the application. Pro- system s security and trustworthiness, which

tection carries an associated performance is something we can solve.

overhead, so it is reasonable to ask what In a capability system, this type of mech-

this design approach costs. anism is readily enforceable. If the installer

doesn t give the application trusted access to

Adapting applications the window system, there is no way that the

Even if compatibility environments for application can forge a trusted dialog box.

existing applications can be constructed (a Similarly, if the only access to the user file

binary compatible Linux environment is in system is provided through the file dialog

progress), EROS imposes a significant cost tool, the application has no means to bypass

in development effort. To gain advantage the user s consent when writing user files.

from the underlying kernel s security prop-

Performance

erties, we must refactor critical applications

into components. The most critical of these Current performance measurements for

EROS are based on microbenchmarks.1 The

applications are external interfaces, such as

SMTP, LDAP, HTTP, and FTP servers. results are limited but encouraging. Process

These services run with a great deal of au- creation in EROS, for example, involves five

thority and use security-critical code. When components: the requesting application, a

completed, the EROS system will ship with constructor, a process creator, a storage al-

all these services. locator, and the newly created components.

After servers, the next most important cat- In spite of this highly decomposed design,

egory is applications that execute active con- the EROS process creation mechanism is

tent such as scripting languages: browsers, three times faster than the Linux fork and

32 IEEE SOFTWARE January/February 2002

About the Authors

Jonathan Shapiro is an assistant professor in the Department of Computer Science at

Johns Hopkins University. His research interests include computer security, operating systems,

and development tools. He received a PhD in computer science from the University of Pennsyl-

exec mechanism. Page faults and mapping vania. Contact him at ****@**.***.***.

management in EROS are over 1,000 times

faster than Linux. This is not a noticeable

source of delay in typical Linux applica-

tions, but it is an absolutely critical per-

Norm Hardy is a senior architect at Agorics, Inc. His research interests include operating

formance issue in component systems.

systems, security, and programming languages. He received a BS in mathematics and physics

Because EROS does not yet have a Unix from the University of California at Berkeley. Contact him at ****@*******.***.

emulator, it is difficult to directly compare

applications. KeyKOS included a binary-

compatible Posix implementation that was

directly comparable with the performance

of the Mach-based Unix implementation.6

We expect that the EROS compatibility im- developers. The system architecture encour-

plementation will do significantly better. ages them to factor applications into man-

ageable pieces, and the protection bound-

aries help make these pieces more testable.

I

t is difficult to measure how much of There are other features of the system that

the testability and performance of the encourage this as well most notably, the

EROS family is due to principles versus event-driven style of component code. EROS

careful implementation and design. Proba- is the first system in the EROS/KeyKOS fam-

bly the clearest impact of principles on the ily that has been exposed to a significant

design results is from the accountability number of programmers. It is still too early

principle, because it has forced us as archi- for a list of design patterns to clearly emerge.

tects to think carefully about resource ma- It is striking, however, that students can

nipulation and protection. master the system and build applications

In terms of impact, security principles quickly, even though various simplifying ab-

run a close second. Whether EROS will ul- stractions are not provided. The greatest

timately be successful remains to be seen, practical impediment to learning seems to be

but the EROS family has achieved some- abandoning their Unix-based assumptions

thing fairly unusual: a verified security ar- about how processes work. Often, we find

chitecture with a running, high-perform- that they ask questions such as, How do I

ance implementation. As a result, EROS is duplicate this Unix functionality? when

currently being evaluated for incorporation they can achieve their real objective more

into various commercial consumer devices. simply using the mechanisms provided.

EROS is also being evaluated for reliability-

critical services such as lightweight direc- References

tory access protocol implementations and 1. J.S. Shapiro, J.M. Smith, and D.J. Farber, EROS: A

Fast Capability System, Proc. 17th ACM Symp. Oper-

Web servers.

ating Systems Principles, ACM Press, New York, 1999,

Two anecdotal facts are encouraging indi- pp. 170 185.

cators: it has been well over eight years since 2. N. Hardy, The KeyKOS Architecture, Operating Sys-

tems Rev., vol. 19, no. 4, Oct. 1985, pp. 8 25.

we have found an EROS kernel bug that an

3. J.H. Saltzer and M.D. Schroeder, The Protection of In-

assertion check didn t catch. This suggests formation in Computer Systems, Proc. IEEE, vol. 9,

that the principle-driven design has helped no. 63, 1975, pp. 1278 1308.

4. J.S. Shapiro and S. Weber, Verifying the EROS Con-

us build a more reliable system by letting us

finement Mechanism, Proc. 2000 IEEE Symp. Security

check for errors effectively. and Privacy, IEEE Press, Piscataway, N.J., 2000, pp.

The Systems Research Laboratory at Johns 166 176.

5. B.W. Lampson, A Note on the Confinement Problem,

Hopkins University is building a second ver-

Comm. ACM, vol. 16, no. 10, 1973, pp. 613 615.

sion of EROS, restructured to support real- 6. A.C. Bomberger et al., The KeyKOS Nanokernel Archi-

time and embedded applications. We antici- tecture, Proc. Usenix Workshop Micro-Kernels and

other Kernel Architectures, Usenix, San Diego, 1992, pp.

pate seeking EAL7 assurance evaluation the 95 112.

highest level currently defined for this sys- 7. Common Criteria for Information Technology Security,

tem under the Common Criteria process.7 ISO/IS 15408, Int l Standards Organization, Final Com-

mittee Draft, version 2.0, 1998.

We have also observed that programmers

using EROS develop their programs in a For more information on this or any other computing topic, please visit our

qualitatively different way than, say, Unix Digital Library at http://computer.org/publications/dlib.

33

January/February 2002 IEEE SOFTWARE

Contact this candidate