Document Sample
ppt Powered By Docstoc
					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 is a Kernel?
            Definition from

               The core, center, or essence of an
                object 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?
A Monolithic Kernel is...
                All operating system services run in
                 kernel mode.

                Single address space.

                High level abstractions given to

                Must support a wide range of

                Slow to change.

                System Calls are expensive.
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
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

            All abstractions are implemented in
             application-level or as part of a library
             OS that is part of the application address
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.
  Exporting Resources Securely
1. Secure Bindings
     Hardware mechanisms
     Software caching
     Downloading application code

2. Visible Resource Revocation
     Application level guided deallocation
     Application specific knowledge of state needed to be saved
     Application notification that resources are scarce

3. Abort Protocol
     Mechanism for kernel to force-ably take back resources.
     Still notifies application after the fact.
                         Aegis: an Exokernel
   Processor Time Slicing                                   Guaranteed Mappings
    Represents CPU as a linear vector partitioned time        Holds application data and code in memory.
    slices that can be allocated by the application.          Also allows each application a small number of
                                                              pinned virtual addresses.
   Timer Interrupts
    Denote the beginning and end of a time slice to the      Dynamic Code Generation
    user-level code where scheduler activations can be        Creation of executable code at runtime. Used
    implemented.                                              by the network subsystem to download filters
                                                              for demultiplexing messages.
   Processor Environments
    Structures that store information needed to deliver      Protected Control Transfers
    events to applications. (Upcalls)‫‏‬                        Changes the program counter to callee, donates
                                                              current time slice to callee's processor
   STLB                                                      environment and switches to the callee's
    A large software TLB is over the hardware TLB             context.
    and can be used on a cache miss to map address.
                                                              User level efficient IPC abstraction can easily be
                                                              built on top of PCT's.
                                  Aegis: Events
Four Types: Exceptions, Interrupts, Protect Control Transfers and Address Translations

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.
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.
         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

Why is performance so much better on Aegis?
      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.
ExOS: a Library Operating System
  Implements traditional operating system abstractions at the
application level, since it runs in the applications address space.
   Fault Isolation                                           IPC abstraction
       Each application runs in it's own address space.          Built on top of protected control transfers.

   Efficient                                                 Virtual Memory
     No protection domain crossing to manage                  Using low-level hardware abstractions
    resources after they have been allocated.                  ExOS provides a rudimentary VM system.

        System calls are near procedure call speed.
                                                              Remote Communications
   Extensible                                                  Downloading code into the kernel allows
                                                               the demultiplexing of the messages without
       Policies can be altered at application level.
                                                               a context switch.
       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.
          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.
ExOS: Application-Specific Safe Handlers
                                    3500                                                       ASH: Untrusted application-
Roundtrip Latency (microseconds)‫‏‬

                                    3250           ExOS without ASH                             level message-handlers that
                                    3000           ExOS with ASH                                are downloaded into the
                                                                                                kernel, made safe with code
                                                                                                inspection and sand boxing.

                                                                                               • Reduces intermediate
                                                                                                 copies of message.

                                                                                               • Can integrate check
                                                                                                 summing in transfer

                                                                                               • Low-latency message
                                           1   2   3        4         5   6   7   8   9   10     replies

                                                           Number of Processes                 • Control initiation
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
 occur rarely, if ever. This is perhaps why few good ideas from the last decade of operating
 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]?”
      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.
 MIT Exokernel Operating System
 Wikipedia: Exokernel

 Wikipedia: Kernel (computer science)
 Wikipedia: MicroKernel

 Wikipedia: Monolithic Kernel

Wiktionary: kernel

Shared By: