Operating System Architectures

1
Operating System Architectures

• Kernel Design

2
Kernel Architectures

• MicroKernels
• Extensible Operating Systems

3
Microkernels

• Original concept due to Per Brinch-Hansen
• RC 4000 Multiprogramming System, 1969
• Poor performance, due partly to the IPC overhead.
• Nevertheless, the concept remained popular.

4
Basic Idea

• OS kernel is very small supports process
  management, not much else.
• Other OS functions provided at user level by
  trusted servers.
• Windows, later versions of Mach, are examples of
  systems that use modified microkernels.
• L4 is a publicly available, pure microkernel

5
Major Advantages - Claim

• Modularity
• Flexibility (easy to replace modules)
• Safety (each server is protected by the OS from
  other servers)
• Correctness (easier to verify a small kernel)

6
Major Disadvantagesof Early Microkernels

• Slow based on cross-domain information
  transfers.
• Server-to-OS, OS-to-server communication involves
  mode switches.
• Much faster to communicate between two modules
  that are both in OS
• Other problems cost of creating new processes
  whenever a server is activated,

7
Can MicroKernels Perform Well?

• Jochen Liedtke argued that microkernels can give
  the same level of performance as a traditional
  OS, and conducted experiments using his µ-kernel
  (L4) to prove his claim.
• Liedtke argued that 1st generation µ-kernels
  just werent small enough.

8
L4

• Highly tuned, small, very efficient
• Kernel implements threads, address spaces, very
  efficient thread communication, and simple
  scheduling.
• Other operating systems can be configured to run
  as servers on top of L4

9
Extensible Operating Systems

• L4 and other microkernels popularized small
  kernels and the idea of OS flexibility
• Extensible operating systems build on this idea

10
Hierarchy of Communication Mechanisms (Fastest to
Slowest)

• Procedure calls within same process
• Switch between user-level threads
• System calls (mode switch)
• Switch between kernel-level threads
• Shared memory between processes
• Context Switch (process switch)
• IPC between processes (message passing, on the
  same or different machines)

11
Extensible Operating Systems

• Specializing General Purpose Operating Systems

12
Extensible Operating Systems

• Motivation
• Exokernel
• SPIN

13
Motivation for New OS Designs

• Desire to make operating systems more responsive
  to applications needs e.g.,
• Do your own scheduling
• Choose your own page replacement algorithm
• Similar to micro-kernel motivation

14
Traditional General Purpose OS

• Provides various abstractions of system resources
  (virtual address spaces, processes, files, etc.)
• Provides general-purpose resource management
  algorithms
• Able to handle most applications, but handles no
  applications perfectly because theres no easy
  way to specialize the OS to individual needs.

15
Extensibility

• Microkernels provide one kind of extensibility,
  SPIN and exokernel architectures take somewhat
  different approaches.
• Exokernel a very small kernel allocates raw
  resources to applications. Resource management
  is done by untrusted user level code, in the form
  of library operating systems.
• SPIN provides a basic set of services
  applications modify/extend the services by
  linking code into the kernel (extension model).

16
SPIN

• Extensibility, Safety and Performance in the
  SPIN Operating System
• Brian N. Bershad, et. al.

17
SPIN Motivation

• SPIN is motivated by the need to support
  applications that present demands poorly matched
  by an operating systems implementation or
  interface.
• Implementation what the system does its
  functionality
• Interface how an application accesses the system
  functionality.

18
Implementation and Interfaces

• OS implementation decisions (file system design,
  page replacement algorithm, etc.) may not be a
  good fit for some applications
• Interface design limits how we can use the
  functionality of the operating system.

19
SPINs Goal

• To build an operating system that provides
  extensibility, safety, and performance.
• Extensibility the ability of an application to
  change/extend basic system services,
• Safety but no application can interfere with any
  other application
• Performance and it cant be slow - guarantee low
  overhead communication between OS and application

20
Goals

• Extensibility comes from letting app.s access
  low-level kernel primitives and compose them into
  larger abstractions.
• Modify/replace
• The kernel provides fine-grained interface to
  system services. Something that would be a large
  module in a traditional OS (e.g. the paging
  system) is broken down into smaller modules
  each with its own interface. (See figure 3 in the
  paper.)

21
Safety

• Safety is provided by a trusted compiler.
• Written in Modula-3, the compiler is trusted to
  generate safe code.
• It allows one module to access another only
  through the defined interface.
• It provides type safety, which among other
  things always checks for array indexing errors
  and prevents pointers from referencing objects of
  the wrong type

22
Performance

• Applications modify the system by writing
  extensions, code that changes the way in which a
  system provides service.
• Extensions are linked directly to kernel code
  when they are needed. Because they run in kernel
  space, communication between OS code and
  extension code is fast no system calls

23
Fundamental Techniques

• The success of SPIN is based in large part on the
  following techniques, implemented by the language
  and its runtime environment
• Co-location
• Enforced modularity
• Logical protection domains
• Dynamic call binding

24
Co-location

• Refers to the linking of extension code and
  system code, which results in low overhead
  communication
• This process is done dynamically an extension
  is linked in only when the application needs it.

25
Enforced Modularity

• Extensions are written as Modula-3 modules with
  well-defined interfaces enforced by the compiler.
• Access to memory or privileged instructions only
  through explicitly granted interfaces.
• Compiler-enforced modularity ensures low cost
  isolation between modules.

26
Logical Protection Domains

• Protection domain an abstract notion to provide
  access control on resources, both hardware and
  software.
• A protection domain specifies (by name) the
  resources a process may access.
• SPIN domains contain code exported interfaces
  to system resources/core services

27
Protection Domains

• An extension exists within a specific domain and
  can reference anything in the domain
• A dynamic linker in the kernel links code in
  separate domains with proper permission
• Once this is done, domains can share resources at
  memory speed.

28
Protection Domains Capabilities

• Capability an unforgeable reference to a
  resource think of it as a key
• When a process is granted access to a resource it
  receives a capability
• SPIN implements capabilities as pointers
• the compiler can prevent them from being forged,
  or dereferenced incorrectly.
• this is done at compile-time, which is fast

29
Dynamic Call Binding

• Events activate the execution of an extension
  (think of interrupt processing or exception
  processing)
• Applications are allowed to define handlers for
  the event.
• Procedures that process the event.
• Extensions are registered with a central
  dispatcher and can be executed with the overhead
  of a procedure call.

30
SPIN versus Other Systems

• The authors claim that microkernels are also
  extensible, but that they are too slow (kernel
  crossings).
• So less incentive to provide fine-grained
  interaction with the kernel.
• They also claim that compared to other systems
  that allow insertions into the kernel SPIN is
  more flexible and safer.

31
Summary

• SPIN enables extensibility without compromising
  safety or performance
• SPIN provides a set of core services for managing
  system resources
• Extensions allow applications to modify or
  replace the core services
• Extension are supported by co-location, enforced
  modularity, logical protection domains, and
  dynamic call binding.

32
Exokernels

• Exokernel An Operating System Architecture for
  Application-Level Resource Management
• By
• Dawson R. Engler, M. Frans Kaashoek, and James
  OToole Jr 1995.

33
Exokernel

• Exokernel is not the name of a particular
  operating system it designates a type of
  operating system architecture, much like a
  microkernel is an OS architecture.
• An exokernel-based system consists of a very
  small kernel (the exokernel) and one or more
  library operating systems.
• The paper describes a proof-of-concept exokernel
  called Aegis and ExOS, a library operating system.

34
Exokernel Motivation

• Motivated by the belief that the OS should not
  provide high-level abstractions upon which
  applications are built
• Instead, the OS should manage physical resources
  and allow applications to develop abstractions
  which match the requirements of the application
• Ex The authors cite measurements showing that
  application-controlled file caching can reduce
  run time by up to 45.

35
Premise Goal

• The basic premise of exokernel architectures is
  the lower the level of a primitive, the more
  efficiently it can be implemented.
• Its goal is to separate resource protection from
  resource management.
• The goal is achieved by providing kernel
  interfaces at the lowest possible level if
  possible, directly to the hardware.

36
Goal Statement

• In another paper, Engler et.al. state that The
  exokernels only function is to allocate,
  deallocate, and multiplex physical resources in a
  secure way. Resource access is controlled
  through 64-bit capabilities. The resources
  include physical memory (in pages), the CPU (in
  time-slices), the TLB, context-identifiers, and
  disk memory (divided into blocks).

37
Basic Principles

• Resource protection is the function of the
  kernel, and is applied to raw resources (e.g. a
  section of physical memory) rather than to an
  abstraction (e.g., a virtual address space).
• Resource management can be left to the
  application (untrusted)
• The exokernel will forward exceptions (e.g., a
  page fault) to the application for processing.
• Compare to SPIN event handling

38

• Claim OS use of high-level abstractions hides
  info that applications could use to manage their
  own resources. For example
• Database systems may be forced to build
  random-access files on top of the OS file system
  instead of being able to interact directly with
  the disk using raw I/O statements
• Claim a large, unmodifiable OS cant easily
  incorporate new research developments.

39
Library Operating Systems

• Untrusted - Built on top of an exokernel
• Can be tailored to a set of applications with
  similar requirements.
• Run in user space fewer system calls to the
  exokernel gt enhanced performance.
• Applications can interact with a library OS or
  interface directly to the exokernel.
• Possible to provide a standard interface (e.g.
  POSIX) for a familiar look.

40
Design Principles

• The interface between the exokernel and library
  OSs is defined by the exokernel according to
  these principles
• Securely expose hardware
• Expose allocation
• Expose names
• Expose revocation
• In this context expose means to make visible to
  the application or library OS that interfaces to
  the kernel

41
Design Principle 1Expose Hardware

• The kernel aims to export very low-level hardware
  resources such as privileged instructions, as
  well as more abstract resources such as
  interrupts.
• The library OS must be free to use the resources
  as it desires.
• Exported resources are accessed via system calls
  that verify the callers permission to use the
  resource.

42
Design Principle 2Expose Allocation

• The library OS should be allowed to ask for
  specific physical resources.
• For example access time to files that are always
  used together may be improved by storing them
  close together on the disk. If the library OS can
  request specific disk blocks, it may be able to
  get better performance.

43
Design Principle 3Expose Names

• Physical names are things like page numbers and
  disk block addresses.
• It is more efficient to have the physical address
  so no translation is needed.
• Names of system data structures which contain
  info such as disk arm positions or TLB contents
  should also be made available to the application
  level.

44
Design Principle 4Expose Revocation

• Provide details under which resources are
  revoked, so library OS can manage its resources
  efficiently.
• When a page fault occurs the library OS (not the
  kernel) will decide which page to replace. Since
  it knows the actual physical names of pages, it
  can do this easily.

45
Secure Bindings

• decouple authorization from the actual use of a
  resource.
• Secure bindings are implemented in such a way
  that the kernel can perform access- checking
  quickly when the access is performed.
• Binding takes place when the resource is
  allocated
• Access checking is thus quick e.g., a capability

46
Summary

• Exokernels are responsible for resource
  allocation/protection, user applications are
  responsible for resource management.
• Exokernel primitives can be implemented
  efficiently because they are simple
• Low-level multiplexing of hardware is fast.
• Library OSs enable applications to create
  appropriate abstractions.
• Secure bindings provide protections

47
End-to-end Argument

• The end-to-end argument argues that (high-level)
  applications know their own needs best. Services
  provided by low-level system components (the OS,
  for example) are often expensive and redundant
  (they will need to be done again, correctly, at a
  higher-level)
• Exokernel authors use this argument to support
  their claim that OS should give applications
  almost total control over high-level
  abstractions.
• SPIN has a similar philosophy.
• End-To-End Arguments In System Design, by
  Jerome H. Saltzer, David P. Reed, David D. Clark,
  ACM Transactions on Computer Systems, Nov., 1984.

48
Questions

• Think about similarities and differences between
  SPIN and Exokernel architectures.
• Basic philosophy
• Motivation
• Approach