An Introduction to Exokernels

1
An Introduction to Exokernels

• Ref Engler, Kaashoek, OToole paper

2
Basic Premise

• OS builds abstractions (processes, files, address
  spaces, IPC) to hide applications from low-level
  information about machine resources
• This is a bad thing!
• Applications cannot use knowledge about the
  application to optimize performance (e.g., memory
  access patterns)
• Applications cannot easily change implementations
  of the OS abstractions, e.g., to optimize
  performance
• Restricts flexibility of application builders
  because new abstractions can only be built on top
  of existing ones (if at all)
• Solution Application level (i.e., untrusted)
  resource management
• Exokernel abstractions such as VM, IPC
  implemented at application level
• Philosophy not unlike micro-kernels, but more
  extreme, e.g., virtual memory and IPC implemented
  in application rather than microkernel

3
Exokernel-Based System
Applications
Mosaic
Barnes-Hut
WWW
DSM
POSIX
TCP
VM
IPC
Library OS
traps
Secure bindings
Exokernel
Frame buffer
TLB
Network
Memory
Disk
Hardware

• Thin exokernel veneer exports resources to
  library OS (application) through secure bindings
• Multiplex usage of resources tables track
  ownership
• Each library OS implements its own system objects
  and policies
• Applications link against standard libraries,
  e.g.,
• WWW, POSIX, TCP for web applications
• Shared memory abstractions for parallel
  applications

4
Exokernel Design Principles

• Securely expose hardware
• Examples priveleged instructions, hardware DMA,
  resources such as physical memory, CPU, disk,
  TLB, address content identifiers, interrupts
• Each exported operation wrapped in a system call
  that checks ownership
• Exokernel does not manage resources
• Expose allocation
• For example, Library OS can request specific
  physical pages to reduce cache conflicts
• Expose names
• For example, physical page numbers
• Expose revocation
• Visible resource revocation protocol to manage
  resources among Library OSes
• Resource policy decisions given to Library OSes

5
Exokernel Design

• Main challenge give library OS freedom to manage
  physical resources while protecting them from
  each other
• Track ownership of resources
• Guard resource usage or binding points
• Revoke access to resources
• Three techniques
• Secure bindings of applications to machine
  resources
• Visible resource revocation applications
  participate in resource revocation protocol
• Abort protocol to break secure bindings to
  uncooperative applications

6
Secure Bindings

• Multiplex resources securely among Library OSes
• Authorization to use resource only done at bind
  time
• Simple, fast, protection check done when resource
  is accessed
• Example multiplexing physical memory
• Hardware support
• Allocate physical page bind page, recording
  owner and read/write capability specified by
  library OS
• TLB hit accesses checked by hardware
• TLB miss virtual to physical translation done in
  library OS, loaded in kernel capabilities
  checked
• Break secure binding Flush TLB mappings
• Software caching
• Store virtual-to-physical translations in large
  software TLB cache to improve performance - cache
  of frequently used secure bindings

7
Visible Resource Revocation

• Traditional OSes revoke resources w/o application
  involvement (e.g., deallocating physical memory)
• Application cannot guide deallocation (e.g.,
  which page?) is not informed resource is scarce
• Exokernel uses visible revocation of resources
• For example, when giving up CPU, need not save
  (say) floating point registers if Library OS
  knows registers are not being used

8
Abort Protocol

• Some library OSes might not respond
  satisfactorily to revocation requests (e.g., give
  up memory)
• Kernel can revoke resource and break secure
  bindings by force
• Library OS receives repossession exception to
  indicate resource has been removed

9
Summary

• Argue OS abstractions are bad for applications
• Traditional OS abstractions implemented in
  Library OS, at application level
• Idea securely export hardware resources without
  abstraction
• Measurements indicate substantial performance
  benefit using this approach - primitive kernel
  operations 10x to 100x faster than Ultrix
• Some issues to ponder
• Potential for many different Library OSes!
  Assume far more application developers than
  hackers
• Portability?
• Security?