Exokernel

Download as pdf or txt
Download as pdf or txt
You are on page 1of 15

Exokernel: An Operating System Architecture for

Application-Level Resource Management

Dawson R. Engler, M. Frans Kaashoek, and James O’Toole Jr.

M.I.T. Laboratory for Computer Science

Cambridge, MA 02139, U.S.A

(1995)

Presented – Arun Hariharan


CS 574, Paper 15
1
Traditional Vs Exokernel Operating Systems

• Traditional OS limit the • Exokernel provides


performance of applications by application level management of
fixing interfaces and abstraction. physical resources.

• Traditional kernels are large and • Exokernel provides interfaces


hide physical resources for to application to be as low as
applications. They present the possible (ideally, hardware
application with a virtual machine to interface). Thus reducing the
run on using these abstractions. burden on the kernel and making it
extremely small.
2
WHY GIVE APPLICATION MORE CONTROL?
Fixed high-level abstractions hurt application performance

• there is no single way to abstract physical resources best for all


applications
• trade-offs are made to support different applications and such tradeoff
penalizes some class of applications

Example - RDBMS performance suffers when a general purpose


page replacement strategy such as LRU is imposed by the operating
system. Spatial page-replacement strategies are better.

It is best if the application chooses its implementation from the library OS or


extend and specialize them or replace them completely.

There exist research that suggest that – the lower the level of primitives, the
more efficiently application implementors can use the hardware.

3
Approach
The responsibility for managing hardware resources is transferred to untrusted
software applications
The Exokernel is only responsible for protection of hardware from competing
applications
The applications may use a library operating system for high-level abstraction
on the Exokernel interfaces based on application requirements.

} Distributed Shared
Memory library

4
How can we implement this intuition?

The goal is to separate PROTECTION from MANAGEMENT

The kernel needs to securely export hardware resources to applications

By PROTECTION and SECURELY EXPORT we mean that the resources


must be protected from contending applications to maintain atomicity of
processes.
Made possible by

• Secure Bindings

• Visible Resource Revocation Protocol

• Abort Protocol

5
Design Decisions
To export resources the Exokernel
• Expose Hardware – Lets the applications know what resources can be offered
readily
• Expose Allocations – Lets the application what resources are currently busy, but
can be requested
• Expose Names – Give out physical address and names by which resources are
addressed
• Exposes Revocation – Lets the application know what resource is it taking away
from the application

Resource management policy is left to application


But Exokernel reserves rights to resources allocations

6
Secure Binding

This is a protection mechanism that decouples


authorization from the actual use of a resource.

- Protection check at bind time only


- Implementation is simple
- Hardware
- Software
- Downloading Code into kernel

7
Visible Revocation

If a resource is securely bound to a application


and is requested by another application
- Visible Revocation protocol is use
The lets the application know, that a particular
resource has to be returned within a certain time.

8
Abort Protocol

After revocation order if the application does not


follow the return resource policy

- Abort Protocol is used.

The resource is taken back by force


Resource data and information backed up and
repossession vector used.

9
Performance Test

Exokernel – Monolithic Kernel –


Aegis & ExOS Ultrix

Vs

10
Base Cost for null procedure
call and a simple System Call

Reason : Demultiplexing system calls in Ultrix is expensive


Care is taken not to disturb registers.

Aegis does not bother about such intricate details

11
Exceptions
Aegis dispatches all hardware exceptions to applications
1. It saves three scratch registers in save area
2. Loads exception PC, last virtual address and cause of exception
3. Exception code is run with appropriate permissions set and
execution resumes without involving kernel.

Time to dispatch an exception


in Aegis and Ultrix (in microseconds.)

12
ExOS: IPC Abstraction

pipe: measures the latency of sending a word-sized message from one process to
another using pipes by “ping-ponging” a counter between two processes.

(pipe’) exploits the fact that this library exists to simply inlining the read and
write calls.

shm: measures the time for two processes to “ping-pong” using a shared
counter.

lrpc: this experiment measures the time to perform an LRPC into another
address space
13
ExOS: Application-level Virtual Memory Test

14
Conclusion
An Exokernel securely multiplexes available hardware resources among
applications

Library operating systems, work above the low-level Exokernel interface,


implement higher-level abstractions that best meet the performance and
functionality goals of applications

To achieve low-level interface, the Exokernel separates management from


protection

To make this separation efficient it uses secure bindings, visible revocation and
abort protocol

The system performs very well on all benchmark test

Based on the results of these experiments, we conclude that the Exokernel


architecture is a viable structure for high-performance, extensible operating
system

15

You might also like