APPLICATION PERFORMANCE AND FLEXIBILITY ON EXOKERNEL SYSTEMS

1
APPLICATION PERFORMANCE AND FLEXIBILITY ON
EXOKERNEL SYSTEMS

• M. F. Kaashoek, D. R. Engler, G. R. GangerH. M.
  Briceño, R. Hunt, D. Mazières, T. Pinckney, R.
  Grimm, J. Jannottiand K. Mackenzie
• M.I.T. Laboratory for Computer Science

2
Introduction

• In most operating systems only privileged servers
  and the kernel can manage system resources
• User interface must anticipate all application
  needs
• The exokernel architecture delegates resource
  management to user applications.
• Applications that do not want this responsibility
  communicate with the exokernel through libOSes.

3
Conventional OS user interface
User process
User process
System calls
Kernel protects and manages all the system
resources
4
Exokernels (I)
5
Exokernels (II)

• User processes manage their own resources
• Take over tasks previously done by the kernel
  (file system buffering, virtual memory, )
• Kernel still responsible for protection
• Requires a more complex and more powerful
  user-kernel interface

6
Advantages and Disadvantages

• User applications can often manage their
  resources better than the kernel
• They knowor should knowbetter how they will use
  each individual resource
• Most user applications would still prefer to let
  the kernel handle resource allocation for them
• Do you want to do your own paging in all your
  programs?

7
LibOS (I)

• User-level library of functions emulating
  conventional system call interface
• Manages resources for applications that do not
  want to do it themselves
• Can have different libOSes coexisting on the top
  of same exokernel
• Allows system to emulate behaviors of several
  conventional operating systems

8
LibOSes (II)
9
LibOSes (III)

• Same interface between application and libOS as
  between application and a conventional kernel
• libOS runs as part of application
• Cannot be trusted by the kernel or other user
  processes

10
Previous Work

• Other techniques to provide extensible systems or
  to give applications more control over their
  resources include
• Some newer microkernels (SPACE)
• Virtual machines
• Allowing applications to download code into the
  kernel (SPIN, Vino)
• User-level networking
• Application-controlled virtual memory.

11
Five Principles

• Separate protection and management.
• Letting applications allocate resources
  explicitly.
• Using physical names whenever possible.
• Expose revocation let applications choose which
  instance of a resource to give up.
• Expose all kernel information.

12
Three Design Techniques

• Xok performs access control on all resources in a
  uniform manner.
• Software abstractions bind hardware resources
  together, like, disk blocks and the memory pages
  caching them
• Some Xok abstractions let applications download
  code into the kernel to achieve a finer grain of
  protection
• For validating file update times in a file system

13
Features

• Three level of trust
• mutual trust (common case)
• unidirectional trust
• mutual distrust (very infrequent)
• Several library files systems can safely share
  the same disk

14
An Example The File System

• Most file system functions are left to untrusted
  library file systems (libFSes)
• Will share access to the stable storage (disk)
• Can define new file types with arbitrary metadata
  formats
• Problem is to give maximum of flexibility to
  these libFses while protecting files from
  unauthorized accesses

15
Four requirements

• Creating new file formats should not require any
  special privilege
• libFSes should be able to safely share blocks at
  the raw disk block level
• Storage system should be efficient
• Storage system should facilitate cache sharing
  among distinct libFses

16
The Solution XN (I)

• Provides access to stable storage at the level
  of disk blocks
• Exports a buffer cache registry (contains only
  metadata)
• Main problem is to decide when to allow or
  disallow access to a specific block
• Difficult problem because each libFS may use
  different metadata

17
The Solution XN (II)

• XN uses UDF(untrusted deterministic functions)
• Specific to a user-defined metadata type
• own-udfT(m) returns set of blocks to which
  instance m of metadata type T point to
• Stored in templates
• Cannot be changed after they are specified

18
XN Security Issues

• XN uses secure bindings
• Access checks are done once at bind time not at
  each access time
• Individual disk blocks are protected through UDFs
  and libFSs own metadata
• Keeps exokernel simple

19
XN Consistency Issues

• XN has an in-kernel system-wide cache registry
• Maps cached disk blocks to the physical pages
  holding them
• Guarantees that same block cannot be cached in
  two different physical pages by two different
  libFSes
• XN also ensures safe ordering of disk
  updates(more about it later)

20
Some Lessons

• It is a good idea to expose kernel data
  structures
• Leads to much better performance
• Libraries are simpler than kernels
• Exokernel interface design is not simple
• Self-paging is difficult to implement, especially
  in libOSes
• Downloading is powerful