APPLICATION PERFORMANCE AND FLEXIBILITY ON EXOKERNEL SYSTEMS M

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 lib. OSes.

Conventional OS user interface User process System calls Kernel protects and manages all the system resources

Exokernels (I) 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?

Lib. OS (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 lib. OSes coexisting on the top of same exokernel – Allows system to emulate behaviors of several conventional operating systems

Lib. OSes (II) User process lib. OS Exokernel

Lib. OSes (III) • Same interface between application and lib. OS as between application and a conventional kernel • lib. OS 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

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

An Example: The File System • Most file system functions are left to untrusted library file systems (lib. FSes) – 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 lib. Fses while protecting files from unauthorized accesses

Four requirements • Creating new file formats should not require any special privilege • lib. FSes 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 lib. Fses

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 lib. FS may use different metadata

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

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 lib. FS’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 lib. FSes • XN also ensures safe ordering of disk updates (more about it later)

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 lib. OSes • Downloading is powerful