Extensible kernels
1 / 37

Extensible Kernels - PowerPoint PPT Presentation

  • Uploaded on

Extensible Kernels. Mingsheng Hong. OS Kernel Types. Monolithic Kernels Microkernels Flexible (?) Module Design Reliable Secure Extensible Kernels Can be customized (extended, specialized, replaced) More functionality Better performance. Motivations.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Extensible Kernels' - kirby-terrell

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Extensible kernels

Extensible Kernels

Mingsheng Hong

Os kernel types
OS Kernel Types

  • Monolithic Kernels

  • Microkernels

    • Flexible (?)

    • Module Design

    • Reliable

    • Secure

  • Extensible Kernels

    • Can be customized (extended, specialized, replaced)

      • More functionality

      • Better performance


  • Problems in traditional OS kernels

    • Implementation cannot be modified

      • LRU as general page replacement strategy

    • Hide information of machine resources

      • Not always appropriate in achieving high performance

        • database on top of file system

    • Provide a unified interface (overly general)

      • Trade-offs for different applications

        • page table structure


  • Exokernel: safely expose machine resources

    • Higher-level abstractions are implemented in applications

    • The concept of Library OS

    • Safety ensured by secure bindings

  • SPIN: use kernel extensions to safely extend/change OS services/implementations

    • Event-driven model to customize services

    • Efficiency preserved

    • Safety ensured by PL facilities

Exokernel overview
Exokernel: Overview

  • An extension of RISC philosophy

  • Kernel provides minimum services

    • Hardware resource protection

      • Allocation

      • Revocation

      • Sharing

      • Tracking of ownership

    • Resource usage arbitration

      • Including an abort protocol

  • LibOS as powerful as traditional OS

A motivating example
A Motivating Example

*This example is borrowed from MIT website

Exokernel design principle
Exokernel: Design Principle

  • To separate protection from management

    • Can protect resources without understanding them

  • When knowledge of resource is required

    • Can leave decisions to applications by downloading code

    • Another level of indirection without sacrificing performance

Exokernel secure bindings
Exokernel: Secure Bindings

  • Why?

    • Library OSes are untrusted

  • How?

    • Hardware mechanism

      • TLB entry

    • Software caching

      • STLB

    • Downloading application code

Secure bindings
Secure Bindings

  • Multiplexing physical memory

    • Records capabilities: ownership, R/W permissions (authorization at bind time)

    • Checks capabilities(authentication at access time)

    • Enables resource sharing (How?)

Secure bindings via downloading code
Secure Bindings via Downloading Code

  • Multiplexing the network

    • Uses Application-specific Safe Handlers (ASHs)

    • Performance

      • Eliminate kernel crossings

      • Decouple latency-critical operations from process scheduling

    • Safety

      • Can be verified and trusted

More on ashs
More on ASHs

  • An ASH can serve as a

    • Packet filter

    • Computation unit

      • checksumming

    • Message initiator

    • Control initiator

Issues in resource revocation
Issues in Resource Revocation

  • Visible deallocation of resource

    • So that library OS has a chance to react

      • e.g. when physical page “5” is deallocated

    • But could be less efficient

      • Can combine invisible revocation

      • Library OS can be prepared for such occasions

  • But when application does not cooperate…

    • Abort Protocol – imperative revocation

      • e.g. cpu time slice

  • Need to leave some resource for each libOS

    • Guaranteed mapping

Experiment aegis exos
Experiment: Aegis & ExOS

  • Aegis: an exokernel on MIPS-based DECstation

    • Xok: another exokernel for Intel x86 computers

  • ExOS: the corresponding library OS

    • Virtual memory, IPC are managed at application level

    • Can be extended

  • Performance compared with: Ultrix

Protected control transfers
Protected Control Transfers

  • Suggested reasons (?)

    • Kernal crossing

    • TLB flush


  • Securely multiplexes hardware resources, to achieve more flexibility & efficiency

    • OS primitives

    • High level abstractions: VM, IPC

    • Implementation can be customized (libOS)

Some issues
Some Issues

  • Exokernel

    • Portability

  • Library OS

    • Too much code in user space?

    • Not easy to customize?

      • OSKit, SPIN

    • Should provide a standard interface?

    • Security

Spin an extensible os
SPIN: an Extensible OS

  • Uses language features to make a system

    • Extensible

      • Dynamic linking & later binding

    • Safe

      • Type safe language

    • Efficient

      • In kernel space

  • Modula-3 features: memory safe; interfaces

Traditional oses
Traditional OSes

*This picture is borrowed from Univ. of Washington website

Spin structure
SPIN Structure

*This picture is borrowed from Univ. of Washington website

The protection model
The Protection Model

  • Pointers as capabilities

    • Types not forgeable

    • Determined at compile-time => efficient

    • Externalized when passed across domains

  • An object is safe if

    • Verified by the compiler

    • Or asserted so by the kernel (objected implemented in other languages)

The extension model
The Extension Model

  • Events and handlers







  • Execution of handlers can be

    • Synchronous/ asynchronous

    • Bounded in time

    • Ordered/unordered

Core services
Core Services

  • Services that cannot be safely implemented by extensions

  • Simple functionality

  • Fine grained control

Core services memory management
Core Services: Memory Management

  • Manage memory and processor resources

    • MM interfaces

      • Storage: allocate, deallocate, reclaim

      • Naming : allocate, deallocate

      • Translation: add/remove/examine mapping

        • Exceptions

          • PageNotPresent

          • BadAddress

          • ProtectionFault

    • Address space model can be defined on top of the primitives

Core services thread management
Core Services: Thread Management

  • Thread Management

    • Strand interface

      • block/unblock

      • checkpoint/resume

    • Global and application-specific schedulers

    • Thread model can be defined on top of the primitives

  • Core services are trusted

    • Extensions should be fault-isolated

Performance i competitors
Performance I: Competitors

  • DEC OSF/1: monolithic kernel

  • Mach 3.0: microkernel

  • SPIN: extensible kernel

Performance ii microbenchmarks
Performance II: Microbenchmarks


Thread management

Vm primitives
VM primitives

  • Kernel crossings

  • Overhead in demultiplexing exception (?)

Performance iii networking
Performance III: Networking

Latency and bandwidth

Packet forwarding

End to end performance
End-to-End Performance

Networked Video System

A dilemma in web server buffer management

-- hybrid cache policy

Issues in spin
Issues in SPIN

  • Scalability of the event/handler model

  • How to prioritize handlers?

    • Throughput vs. fairness

  • Extensibility limited by interfaces


  • Two methods to make OS more flexible & efficient

  • Both reduce kernel crossings

    • Exokernel: libOS

    • SPIN: link extension code to kernel space