An Operating System Architecture for Application-Level Management Dawson R. Engler, M. Frans Kaashoek, and James O

1
An Operating System Architecture for
Application-Level ManagementDawson R. Engler,
M. Frans Kaashoek, and James OToole Jr.M.I.T.
Laboratory for Computer Science
Exokernel

• Presenter Phillip Sitbon

Spring 2006
2
Motivation

• Interface between OS and applications are
  typically hard-coded as high-level abstractions
• Processes, files, address spaces, IPC, etc.
• These abstractions define a kind of VM for
  applications
• Hard-coded into the kernel means that generality
  sacrifices flexibility and optimization
  opportunities
• Part of the motivation for SPIN as well

3
Motivation

• Whether microkernel or monolithic, abstractions
  must be used system-wide
• All apps use the same kernel or user-level server
  features
• There isnt a best way to implement for all
  applications
• Abstractions hide information
• Upcalls were used before to address this
• Hard to add new features that break abstractions,
  because all applications are dependent

4
Solution

• Allow abstractions to be implemented at
  application (non-kernel) level
• Specialization is now a matter of using different
  libraries
• Do all the work in library operating systems that
  communicate with the exokernel
• Do secure multiplexing in the exokernel so the
  users of resources dont need to

5
Design
6
Design

• Securely exposed hardware resources
• Low-level primitves to access hardware as
  directly as possible
• This includes less tangible resources, such as
  interrupts and privileged instructions
• Exposed allocation
• Can request specific physical resources
• Library OS participates in every allocation
  decision
• Names
• Physically named access to resources such as
  freelists, disk arm positions, etc.
• Visible Revocation
• Allows Library OSes to choose which resources to
  relinquish and allows the exokernel to gracefully
  reclaim resources.

7
Secure Bindings

• Protection mechanism to decouple authorization
  from actual use of a resource
• Allows access checks to be efficiently be
  implemented at access time
• Done by doing actual authorization at bind time
• Allows the kernel to protect resources without
  understanding them
• Implemented by
• Hardware Set appropriate access from the kernel
• Software caching i.e. software TLB
• Downloading code Code runs in the kernel upon
  events

8
Multiplexing Memory

• Library OSes specify capabilities when allocating
  physical pages
• Becomes owner, able to set r/w access
• Bind-time authorization
• Capabilities presented to the kernel for access
• Example of a low-overhead access of a secure
  binding
• Allows applications to grant rights to others
  without kernel intervention

9
Multiplexing the Network

• Protocol-specific knowledge required to determine
  message recipient
• Some hardware support, such as binding virtual
  ATM circuits securely to applications
• Only packet filters available in Aegis/ExOS
• Special language used to compile packet filter
  rules to machine code
• Allows applications to specify packet filters
• Basic checks disallow stealing of packets

10
Downloading Code

• Eliminates kernel crossings
• Can be run when application is not scheduled
• Bounded runtime for situations where context
  switches arent a good idea
• Packet filters without this, each potential
  packet consumer must be scheduled
• Can also react ASHes
• Mostly run as machine-readable object code, but
  the instruction set is extended in a few places

11
Visible Resource Revocation

• Must have a way to break secure bindings
• Notifying library OSes allows specific action to
  be taken
• For example, processor is revoked at the end of a
  time slice can react by saving only needed
  registers
• Must also be able to take resources by force
• After some time, requests become an imperative
• Secure bindings then broken forcefully
• The offending library OS can update/recover when
  it gets a reposession exception

12
Aegis

• Uses a set of primitives as pseudo-instructions
  to encapsulate privileged instructions
• Applications responsible for general-purpose
  context switching
• Gives applications all the control
• Fairness achieved by tacking time usage
• Extra time slices paid for by subseqent time
  slices being taken away
• Too much excess causes environment to be destroyed

13
Aegis

• Four kinds of events
• Exceptions
• Interrupts
• Protected entry
• Addressing
• Each event has an associated context and resource
• Exceptions are given to applications so they can
  resume execution

14
Aegis

• Applications virtual address space split into
  two segments
• First holds normal data and code, can be pinned
  using guaranteed mappings
• On a TLB miss,
• Guaranteed mappings are handled automatically
• Otherwise, the application looks up the address
  in its page table
• Aegis checks the applications capability to
  determine access

15
Protected Control Transfers

• For efficient implementation of IPC
• Time slice of call donated to callee
• Synchronous and asynchronous
• Asynchronous donates only remainder of current
  time slice to callee
• Synchronous donates all time slices until
  control is returned to the caller
• Minimal requirements allow high performance
• Results 6.6x faster than scaled L3 results

16
ASH

• Application-specific safe handlers can perform
  general computations
• Allows reaction to messages without leaving the
  kernel
• Untrusted made safe by sandboxing and code
  inspection
• Allows for
• Direct dynamic message vectoring (eliminates
  copying)
• Integrated processing (i.e. checksumming)
• Message and control initialtion

17
Performance with ASH
18
Conclusion

• Different angle export hardware interface rather
  than virtualize
• Supports specialized OS (like Disco)
• Packet filtering for network multiplexing (like
  Xen)
• More efficient than virtual machines
• Only real abstractions are in the library
  operating systems
• Shows substantial improvement while allowing
  traditional abstractions modifications trivial