Exokernel: An Operating System Architecture for Application-Level - - PowerPoint PPT Presentation

exokernel an operating system architecture for
SMART_READER_LITE
LIVE PREVIEW

Exokernel: An Operating System Architecture for Application-Level - - PowerPoint PPT Presentation

Exokernel: An Operating System Architecture for Application-Level Resource Management Dawson R. Engler, M. Frans Kaashoek, and James O'Tool Jr. M.I.T Laboratory for Computer Science Cambridge, MA 02139, U.S.A Presented by Jennifer Minor What


slide-1
SLIDE 1

Exokernel: An Operating System Architecture for Application-Level Resource Management

Dawson R. Engler, M. Frans Kaashoek, and James O'Tool Jr.

M.I.T Laboratory for Computer Science Cambridge, MA 02139, U.S.A

Presented by Jennifer Minor

slide-2
SLIDE 2

What is a Kernel?

Definition from wiktionary.org:

The core, center, or essence of an

  • bject or system.

(computing) The central part of many computer operating systems which manages the system's resources and the communication between hardware and software components.

So what is an Exokernel?

slide-3
SLIDE 3

A Monolithic Kernel is...

All operating system services run in kernel mode.

Single address space.

High level abstractions given to application.

Must support a wide range of applications.

Slow to change.

System Calls are expensive.

slide-4
SLIDE 4

A Microkernel is...

Separate mechanism from policy.

Only lower level mechanisms are supported in kernel mode. (Address space management, scheduling and basic IPC)

Policies are implemented in user level which are easier to change.

Kernel must protect servers from each other.

Good protection but has to use IPC to communicate.

slide-5
SLIDE 5

So an Exokernel is...

Similar to microkernel in that only minimum functionality is in the kernel.

Unlike the microkernel it exports hardware resources rather than emulating them.

Physical resources are safely allocated to the application, where it can be managed.

All abstractions are implemented in application-level or as part of a library OS that is part of the application address space.

slide-6
SLIDE 6

Exokernel Architecture

Goal: Separate protection from management.

  • 1. Low-level interface:

Provide simple and efficient primitives.

  • 2. Multiplex resources:

Securely and fine-grained.

  • 3. Limit management to protection:

Protect without specific usage knowledge of resource.

  • 4. Export hardware resources:

Expose hardware and kernel data structures.

  • 5. Notify Application:

Event notifications and visible resource revocation.

slide-7
SLIDE 7

Exporting Resources Securely

  • 1. Secure Bindings
  • 2. Visible Resource Revocation
  • 3. Abort Protocol

 Hardware mechanisms  Software caching  Downloading application code  Application level guided deallocation  Application specific knowledge of state needed to be saved  Application notification that resources are scarce  Mechanism for kernel to force-ably take back resources.  Still notifies application after the fact.

slide-8
SLIDE 8

Aegis: an Exokernel

 Processor Time Slicing

Represents CPU as a linear vector partitioned time slices that can be allocated by the application.

 Timer Interrupts

Denote the beginning and end of a time slice to the user-level code where scheduler activations can be implemented.

 Processor Environments

Structures that store information needed to deliver events to applications. (Upcalls)

 STLB

A large software TLB is over the hardware TLB and can be used on a cache miss to map address.

 Guaranteed Mappings

Holds application data and code in memory. Also allows each application a small number of pinned virtual addresses.

 Dynamic Code Generation

Creation of executable code at runtime. Used by the network subsystem to download filters for demultiplexing messages.

 Protected Control Transfers

Changes the program counter to callee, donates current time slice to callee's processor environment and switches to the callee's context. User level efficient IPC abstraction can easily be built on top of PCT's.

slide-9
SLIDE 9

Aegis: Events

Event Handler Contexts Include:

 Program counter to jump to on event.  Memory location to save registers.  Additional status registers are needed for timer interrupts and tlb misses.

Four Types: Exceptions, Interrupts, Protect Control Transfers and Address Translations

What happens on a hardware exception?

 Aegis saves three scratch registers into the “save-area”.  Loads the exception program counter, the last virtual address translation and cause.  Performs a indirect jump into an applications-specified program counter.

Note: After handling the exception the application can resume execution without going back to the kernel.

Special event handlers have to be defined for start-time-slice, end-time-slice, asynchronous control transfers, and synchronous control transfers.

slide-10
SLIDE 10

Aegis: Performance

Machine OS Procedure call Syscall (getpid)

DEC2100 Ultrix 0.57 32.2 DEC2100 Aegis 0.56 3.2 / 4.7 DEC3100 Ultrix 0.42 33.7 DEC3100 Aegis 0.42 2.9 / 3.5 DEC5000 Ultrix 0.28 21.3 DEC5000 Aegis 0.28 1.6 / 2.3

Kernel data structures are not mapped. No need to worry

about a interrupted TLB miss.

Two paths for system calls, one for calls that require a

stack and a second for ones that do.

Why is performance so much better on Aegis?

slide-11
SLIDE 11

ExOS: a Library Operating System

Implements traditional operating system abstractions at the application level, since it runs in the applications address space.

 Fault Isolation

  • Each application runs in it's own address space.

 Efficient

  • No protection domain crossing to manage

resources after they have been allocated.

  • System calls are near procedure call speed.

 Extensible

  • Policies can be altered at application level.

 IPC abstraction

  • Built on top of protected control transfers.

 Virtual Memory

  • Using low-level hardware abstractions

ExOS provides a rudimentary VM system.

 Remote Communications

  • Downloading code into the kernel allows

the demultiplexing of the messages without a context switch.

slide-12
SLIDE 12

ExOS: IPC Performance

Machine OS pipe pipe' shm lrpc

DEC2100 Ultrix 326.0 n/a 187.0 n/a DEC2100 Aegis 30.9 24.8 12.4 13.9 DEC3100 Ultrix 243.0 n/a 139.0 n/a DEC3100 Aegis 22.6 18.6 9.3 10.4 DEC5000 Ultrix 199.0 n/a 118.0 n/a DEC5000 Aegis 14.2 10.7 5.7 6.3

 ExOS built a lrpc abstraction on top of the low-level protected

procedure call interface given by Aegis.

 Ultrix does not currently have a lrpc implementation to add new

functionality it would need to build on top of one of the existing high-level abstractions such pipes.

slide-13
SLIDE 13

ExOS: VM Performance

Machine OS dirty prot1 prot100 unprot100 trap appel1 appel2

DEC2100 Ultrix n/a 51.6 175.0 175.0 240.0 383.0 335.0 DEC2100 Aegis 17.5 32.5 213.0 275.0 13.9 74.4 45.9 DEC3100 Ultrix n/a 39.0 133.0 133.0 185.0 302.0 267.0 DEC3100 Aegis 13.1 24.4 156.0 206.0 10.1 55.0 34.0 DEC5000 Ultrix n/a 32.0 102.0 102.0 161.0 262.0 232.0 DEC5000 Aegis 9.8 16.9 109.0 143.0 4.8 34.0 22.0

Kernel transitions can be eliminated by implementing abstractions at application level.

Application-level software can implement functionality that is frequently not provided by traditional operating system.

slide-14
SLIDE 14

ExOS: Application-Specific Safe Handlers

1 2 3 4 5 6 7 8 9 10 250 500 750 1000 1250 1500 1750 2000 2250 2500 2750 3000 3250 3500

ExOS without ASH ExOS with ASH

Roundtrip Latency (microseconds) Number of Processes

ASH: Untrusted application- level message-handlers that are downloaded into the kernel, made safe with code inspection and sand boxing.

  • Reduces intermediate

copies of message.

  • Can integrate check

summing in transfer mechanism.

  • Low-latency message

replies

  • Control initiation
slide-15
SLIDE 15

Why are Exokernels important?

 Fixed high level abstractions hurt application performance  Fixed high level abstractions hide information  Fixed high level abstractions limit the functionality

"Because all applications must share the core abstractions, changes to core abstractions

  • ccur rarely, if ever. This is perhaps why few good ideas from the last decade of
  • perating systems research have been adopted into widespread use. What operating

systems support scheduler activations [3], multiple protection domains within a single address space [10], efficient IPC [29], or efficient and flexible virtual memory primitives [4, 21, 25]?”

slide-16
SLIDE 16

Exokernel Design Proves:

 Resources can be securely partitioned with low overhead  Low-level interfaces and exposed kernel data structure

can produce efficient implementation due to simplicity

 Downloadable application code into the kernel increase

performance and responsiveness

 Library Operating Systems provide extensible and

customizable services at application level.

slide-17
SLIDE 17

References

 MIT Exokernel Operating System http://pdos.csail.mit.edu/exo.html  Wikipedia: Exokernel http://en.wikipedia.org/wiki/Exokernel  Wikipedia: Kernel (computer science)

http://en.wikipedia.org/wiki/Kernel_%28computer_science%29

 Wikipedia: MicroKernel http://en.wikipedia.org/wiki/Microkernel  Wikipedia: Monolithic Kernel http://en.wikipedia.org/wiki/Monolithic_kernel Wiktionary: kernel http://en.wiktionary.org/wiki/kernel