Transcript 8-ExoKernelx

Exokernel: An Operating System
Architecture for Application-Level
Resource Management
by
Dawson R. Engler, M. Frans Kaashoek,
and James O'Toole Jr.
Presented By
Md Atiqur Rahman
Traditional operating systems

Fixed interface and implementation of OS
abstractions.
Applications
FIXED
Abstractions
Hardware
Interface
The Issues

Performance
◦ Denies applications the advantages of domainspecific optimizations
◦ No single way to abstract physical resources
or to implement an abstraction that is best
for all applications.
The Issues

Flexibility
◦ Restricts the flexibility of application builders
◦ Fixed high-level abstractions hide information
from applications.
◦ Difficult or impossible for applications to
implement their own resource management
abstractions.
The Issues

Functionality
◦ Discourages changes to the implementations
of existing abstractions
◦ Only one available interface between
applications and hardware resources.
◦ Because all applications must share one set of
abstractions, changes to these abstractions
occur rarely, if ever
The Solution

End-to-End Argument
◦ Applications know better than OS what the
goal of their resource management decisions
should be

Application level resource management

Separate protection from management
Exokernel
*Taken from Wikipedia
Exokernel
A thin veneer that multiplexes and
exports physical resources securely.
 Lower the level of a primitive.

Exokernel

Resource management

Track ownership and ensure protection


Secure binding
Revoke access


Visible revocation
Abort protocol
Library operating systems
Use the low level Exokernel interface
 Higher level abstractions
 Special purpose implementations
 An application can choose the library
which best suits its needs, or even build
its own.
 Portable

Exokernel-Design Principle

Securely expose hardware


Expose allocation


Kernel should provide secure low-level primitives that
allow all hardware resources to be accessed as directly as
possible.
Allow to request specific physical resources
Expose Names
Export physical names.
 Remove a level of indirection: Translation


Expose Revocation

Utilize a visible resource revocation protocol
Secure Bindings
Exokernel allows libOSes to bind
resources using secure bindings.
 Decouples authorization from the actual
use of a resource.
 Multiplex resources securely
 Performs authorization only at bind time.

◦ Allows the kernel to protect resources
without having to understand them
Secure Bindings

Three basic techniques
◦ Hardware mechanisms
 Appropriate hardware support allows secure
bindings to be couched as low-level protection
operations.
◦ Software caching
 Secure bindings can be cached in an Exokernel.
◦ Downloading application code.
Secure Bindings-Example
• Multiplexing Physical Memory
• Using self-authenticating capability and
address translation hardware
• To ensure protection: guards access by
requiring to present the capability
• To break: change capability and free resource
• Multiplexing the Network
• A software support is provided by packet filters
• Application code, filters, is downloaded into
kernel
Secure Bindings-Downloading code
• Advantages:
◦ Elimination of kernel crossings.
◦ Can be executed in situations where
context switching to the application itself
is infeasible.
 Optimization:
◦ High-level languages provides more
information for optimization.
Secure Bindings-Visible Resource
Revocation

Invisible resource revocation
◦ Efficient – application layer not involved
◦ Library operating systems cannot guide
deallocation.

Visible resource revocation
◦ Allows libOS to guide deallocation and track
availability of resources.
Secure Bindings-The Abort Protocol

Take resources from library operating
systems by force.

Possible ways
◦ Kill any library operating system and its
associated application
◦ Breaks all existing secure bindings.
 Repossession vector.
Status and Experimental
Methodology
Aegis: an exokernel.
 ExOS: a library operating system.
 Experiments test four hypotheses:

◦ Exokemels can be very efficient,
◦ Low-level, secure multiplexing of hardware
resources can be implemented efficiently.
◦ Traditional operating system abstractions can
be implemented efficiently at application level.
◦ Applications can create special-purpose
implementations of these abstractions.
Experimental platforms.
Aegis: an Exokernel
Aegis: an Exokernel

Processor Time Slices
◦ Represents the CPU as a linear vector.
◦ Scheduling is done “round robin”.
◦ Fairness: excess time counter.
Aegis: an Exokernel

Processor Environment
◦ Exception context
 program counter for where to jump to.
 pointer to physical memory for saving registers.
◦ Interrupt context
 program counters
 register-save region.
 separate program counters for start-time-slice and endtime-slice.
◦ Protected Entry context
 synchronous and asynchronous.
◦ Addressing context
Aegis: Base Costs
Aegis: Exceptions
Dispatches all hardware exceptions to
applications.
 Saves three scratch registers into an agreedupon “save area.”
 It loads the exception program counter.
 It uses the cause of the exception to
perform an indirect jump to an applicationspecified program counter value.

Aegis: Exceptions
Aegis: Address Translations

On TLB miss
◦ Aegis checks which segment the virtual address
resides in.
◦ The application looks up the virtual address in its
page-table structure.
◦ Aegis checks that the given capability
corresponds to the access rights requested by
the application.
◦ Cleanup and resumes execution.
Aegis: Protected Control Transfers

Syrrchronous
◦ donate the current time and all future
instantiation.

Asynchronous
◦ Donate only the remainder of the current time
slice to the callee.
Aegis: Dynamic Packet Filter (DPF)

Dynamic code generation approach.
◦ compiling packet filters to executable code
◦ optimize executable code.
ExOS: a Library Operating System

IPC Abstractions
◦ pipe: measures the latency of sending a wordsized message.
◦ 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,
increment a counter and return its value.
ExOS: IPC Abstractions
ExOS: Application-level Virtual
Memory
ExOS: Application-level Virtual
Memory
ExOS: Application-Specific Safe
Handlers (ASH)
Downloaded code
 Direct, dynamic message vectoring.
 Dynamic integrated layer processing (ILP).
 Message initiation.
 Control initiation.

Extensibility with ExOS

Extensible RPC
Extensible Page-table Structures
Applications with Dense address space can
use linear page tables.
 Applications with sparse address space can
use inverted ones.

Extensible Schedulers

Stride scheduling:


Deterministic
proportionalshare
Conclusion


Simplicity and limited number of exokemel
primitives
Exokemel primitives are fast
◦ low-level secure multiplexing of hardware
resources can be implemented efficiently.


Traditional operating system abstractions
can be implemented efficiently at application
level.
Applications can create special-purpose
implementations of abstractions by merely
modifying a library.
Thanks