CSE221 - lec09: Extending OS: L4 & Exokernel

09 - Extending OS: L4 & Exokernel

Overview: Extending OS

• Goal: moving OS functionality to user-level
• reduce kernel complexity
• reduce kernel crossings

The Performance of Micro-Kernel-Based Systems (L4)

Goals

• question: are micro-kernel fundamentally slow?

• specialization & extensibility
• specialize: improve exisiting service on certain settings
• extend: add new features

• question: do we need co-location?

L4 Abstractions

• address space

• threads

• IPC (messages)

L4 Architecture

• L4 kernel in kernel level, with both applications and “guest OS” running at user level as processes.

L4 System Calls

• the language library will translate syscall to “guest OS” as messages to L4 kernel, L4 kernel will forwarded the messages to “guest OS”, retrieve result, and return to applications.

• extra messages → more overhead

L4 Page Fault Handling

• when a page fault occurs, L4 send a message to Linux

L4 Memory Management

• hierarchical address spaces

• Linux delegates memory to applications

• both L4 & Linux maintain their own page table and keep in sync (sync change in L4 pgtbl by syscall to L4)
• more memory consumption
• more kernel crossings in update scene.

L4 Implementation

• Linux: archietecture dependent part + architecture independent part
• L4Linux only modify the first part
• this is an easy way to port monolithic kernel OS to micro-kernel system

Evaluation

• Performance Analysis:
• penalty of using L4 micro-kernel is low
• performance of micro-kernel matters

• Extensibility Analysis:
• extensible
• extension performs well

Summary

• design of a modern micro-kernel

• micro-kernel based system’s performance could approach monolithic kernel

• opportunities for specialization & extensibility

Exokernel: An Operating System Architecture for Application-Level Resource Management

Goal

• push OS functionality → user level even further

• expose hardware

• benefits v.s. L4:
• lower overhead (less kernel-crossing, only procedure call into Lib OS when syscall)
• more capable for speicialization & extension

Design Principles

• securely export hardware: only manage resources to the extent required by protection

• expose allocation: let lib OS pariticipate

• expose names: export physical names and book-keeping data structures, this helps the second principle

• expose revocation: let lib OS participate in revocation

Manage Hardware Resources

• tracking ownerships → using tables

• protection via secure bindings (decouple authorization from use, authorize once at bind time)

• revoke resources when necessary

Summary

• untrusted lib OS manages hardware directly

• protection via secure bindings