Transcript Xok - Department of Computer Science

APPLICATION PERFORMANCE
AND FLEXIBILITY ON
EXOKERNEL SYSTEMS
M. F. Kaashoek, D. R. Engler, G. R. Ganger
H. M. Briceño, R. Hunt, D. Mazières,
T. Pinckney, R. Grimm, J. Jannotti
and K. Mackenzie
M.I.T. Laboratory for Computer Science
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.
Conventional OS user interface
User process
User process
System calls
Kernel
protects and manages
all the system resources
Exokernels (I)
User process
User process
Exokernel
protects but
does not manage
system resources
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
Advantages and Disadvantages
• User applications can often manage their
resources better than the kernel
– They know—or should know—better 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?
LibOSes (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
LibOSes (II)
User process
User process
libOS
libOS
Exokernel
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
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.
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.
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
Protected Sharing (I)
• Four mechanisms:
– software regions: areas of memory that can
only be accessed through system calls
– on-the-fly_creation of hierarchically named
capabilities
– wake-up predicates: wake up processes
when arbitrary conditions become true
– robust critical sections: implemented by
disabling software interrupts
Protected Sharing (II)
• Three level of trust:
– mutual trust (common case)
– unidirectional trust
– mutual distrust (very infrequent)
• Several library files systems can safely share the
same disk
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
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
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
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 (one per file type)
– Cannot be changed after they are specified
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 libFS’s own metadata
– Keeps exokernel simple
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)
Xok
• Runs on Inter x86-based computers
– Since TLB misses are handled by hardware,
cannot change the page table structure.
• Xok exposes
– The capabilities of the hardware (like all MMU
protection bits)
– Many kernel data structures (like free lists and
inverse page mappings)
• Paging is handled by applications.
ExOS 1.0
• libOS that supports most 4.4 BSD abstractions
• Runs many unmodified UNIX applications:
– Most shells and utilities, many networking
applications.
– see page 10
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