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

Reading notes

Overview

• providing application-level management of physical resources.
• Traditionally, operating systems hide information about machine resources behind high-level abstractions such as processes, tiles, address spaces and interprocess communication. Disadvantages:
  • it denies applications the advantages of domain-specific optimizations
  • it discourages changes to the implementations of existing abstractions
  • it restricts the flexibility of application builders, since new abstractions can only be added by awkward emulation on top of existing ones (if they can be added at all).

Application level resource management

• Exokernel/(Aegis) (a minimal kernel) securely multiplexes available hardware resources (defines a low-level interface).
• Library operating systems/(ExOS), working above the exokemel interface, implement higher-level abstractions.
• Exokernel overriding goal: to separate protection from management.

3 Techniques to export resources securely.

1. by using secure bindings, applications can securely bind to machine resources and handle events.
2. by using visible resource revocation (撤回), applications participate in a resource revocation protocol.
3. by using an abort protocol, an exokernel can break secure bindings of uncooperative applications by force.

Aegis

• virtual memory is implemented at application level,
• allows applications to construct a wide array of efficient IPC primitives

Motivation

The Cost of Fixed High-Level Abstractions

• Fixed high-level abstractions hurt application performance be- cause there is no single way to abstract physical resources or to implement an abstraction that is best for all applications.
• Fixed high-level abstractions hide information from applications. Unfortunately, hiding this information makes it difficult or impossible for applications to implement their own resource management abstractions.
• Fixed high-level abstractions limit the functionality of applications, because they are the only available interface between applications and hardware resources.

Exokernels: An End-to-End Argument

• Our solution is to allow traditional abstractions to be implemented entirely at application level.

• (For brevity, we sometimes refer to “library operating system” as “application.”)
• the number of kernel crossings in an exokernel system can be smaller, since most of the operating system runs in the address space of the application.
• portability

Exokernel Design

3 important tasks

• (1) tracking ownership of resources
• (2) ensuring protection by guarding all resource usage or binding points
• (3) revoking access to resources.

Design Principles

• An exokernel designer therefore strives to safely export all privileged instructions, hardware DMA capabilities, and machine resources.

• avoid resource management (将资源管理的权利、操作交给了App)

• Expose allocation: An exokemel should allow library operat- ing systems to request specific physical resources.

• Expose Names: An exokernel should export physical names. Physical names are efficient and also encode useful resource attributes.
• Expose Revocation: An exokemel should utilize a visible re- source revocation protocol so that well-behaved library operating systems can perform effective application-level resource manage- ment.

Secure Bindings

• First, the protection checks involved in enforcing a secure binding are expressed in terms of simple operations that the kernel (or hardware) can implement quickly.
• Second, a secure binding performs authorization only at bind time, which allows management to be decoupled from protection.

• A secure binding allows the kernel to protect resources without understanding them.

• 3 basic techniques to implement

  • hardware check (ownership tag)
  • software caching (e.g. software TLB)
  • Downloading code into the kernel allows an application thread of control to be immediately executed on kernel events.

• Multiplexing Physical Memory
  • The owner of a page has the power to change the capabilities associated with it and to deallocate it.
  • the page table should be visible (read only) at application level.
  • Using capabilities to protect resources enables applications to grant access rights to other applications without kernel interven- tion.

• Downloading code into kernel. Performance advantages:
  • elimination of kernel crossings.
  • the execution time of downloaded code can be readily bounded

Visible Resource Revocation

• Revocation can be visible or invisible to application.
• Invisible revocation
  • lower lantency (invisible revocation can perform better when revocations occur very frequently)
  • requires no application involvement
  • disadvantages: library operating systems cannot guide deallocation and have no knowledge that resources are scarce.

Aegis

• Aegis represents the CPU as a linear vector, where each element corresponds to a time slice.
• Scheduling is done “round robin” by cycling through the vector of time slices. (This simple scheduler can support a wide range of higher-level scheduling policies. )
• Timer intemrpts denote the beginning and end of time slices, and are delivered in a manner similar to exceptions
• Aegis dispatches all hardware exceptions to applications (save for system calls) . After processing an exception, applications can immediately resume execution without entering the kernel.

ExOS: a Library Operating System

Q: Compare and contrast an exokernel with a microkernel.

• As in microkemel systems, an exokemel can provide backward compatibility(向后兼容性) in three ways: one, binary emulation of the operating system and its programs; two, by implementing its hardware ab- straction layer on top of an exokemel; and three, re-implementing the operating system’s abstractions on top of an exokemel.

Class notes

Main point

• Customize OS interface/abstractions by moving everything to user-level

• OS services implemented using untrusted library OS

  • all is library. File system is library. Open call becomes a library call.

• Micro v.s. Exo Difference?

  • M: use IPC communicate. Easy to share files
  • Exo: just library call. Application have own file system. Hard to share files. No cross kernel, no ipc, much fast to call.

Three function of Exokernel

• Track resource ownership
  • A matter of maintaining tables.
• Protection
  • ensures correct operation.
• Resource revocation
  • Exo multiplexes h/w resources via allocation and revocation

Protection

• secure bindings
• decouple authorization from use
• examples
  • TLB entries pre-authorized, maintained in a software cache
• missing?
  • most in user-level
  • VAS ( virtual address space) protect across apps (but no protection)

Make computation close to data.

Resource Revocation

• problem: rely upon libOS to cooperate
• solve
  • “abort protocal”
  • take resources by force
  • still notify libOS waht was taken so that it can update its data structures

Difference

Micro: privileged, cannot safely share data; Exo: unprivileged, can safely share data; needs library OS

Questions

Where would the file system be and how would it work?

• it's part of the library OS
• app just 'call' into it

what is worrisome about having the FS be a library?

• no protection
• memory errors by apps can potentially corrupt on-disk data structure

How to address this problem

• SFI