Extensible kernels
Download
1 / 37

Extensible Kernels - PowerPoint PPT Presentation


  • 138 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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


Motivations
Motivations

  • 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


Approaches
Approaches

  • 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




Conclusion
Conclusion

  • 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

handlers

P2

predicates

P1

P3

event

  • 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

IPC

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


Conclusion1
Conclusion

  • Two methods to make OS more flexible & efficient

  • Both reduce kernel crossings

    • Exokernel: libOS

    • SPIN: link extension code to kernel space


ad