EXOKERNEL Gabriel Beltran John Blackman David Martin Kurt Rohrbacher Matt Sechrist

Motivation for using an Exokernel Mainstream operating systems are not designed for high performance -- OS abstractions need to satisfy a wide range of applications -- Even when they aren’t necessary, they still require resources Are there benefits to customizing abstractions? Exokernels provide a solution to large and unecessary kernels -- Kernel operations include hardware multiplexing and resource protection -- Higher level abstractions are implemented in libraries (called libOSes)

Kernel Design Considerations The kernel notifies programs of processor events (such as interrupts and hardware exceptions). The kernel allocates physical memory pages to programs and controls the translation lookaside buffer. The kernel ensures that programs access only pages for which they have a capability. It also implements a programmable packet filter

Security Considerations The goal is to give enough control of resources to all applications in a secure, multi-user system. Resource management is restricted to functions necessary for protection. They are as follows: Allocation, Revocation, Sharing information, and Tracking of ownership.

Hardware Multiplexing Distributed Control Exokernel must be responsible for 3 core tasks: Track ownership of resources Perform access control to ensure security policy is not violated Revoke access to certain resources Secure Binding Decouples authorization from actual use of object High-level authorization not required for access privileges Physical Memory, Frame Buffers, Network Devices, etc.

Hardware Multiplexing Physical Memory Exokernel creates secure binding by recording the owner and read/write capabilities specified by the application. Once application is given physical memory page it has the power to change its capability and deallocate the page. Frame Buffers Application can access frame buffer hardware directly because the hardware checks the ownership tag when I/O takes place. Network Devices Packet filters

Hardware Multiplexing Revocation Necessary to reclaim resources. Invisible and Visible revocation. The Abort Protocol Uncooperative Processes Defines what action the exokernel will take. Reposession Vector records the forced loss of a resource and sends application a “reposession” exception to update necessary variables.

Storage System XN Give libFSes as much control over file management as possible while still protecting from unauthorized access. Unauthorized access prevented by using secure bindings. XN follows 3 rules for achieving strict file system integrity Never reuse an on-disk resource before nullifying all previous pointers to it. Never create persistent pointers to structures before they are initialized. When moving an on-disk resource, never reset the old pointer in persistent storage before the new one has been set. XN allows the 1ibFSes to address the file management by enforcing the rules without legislating how to follow them.

File System C-FFS: “co-locating fast file system “ UNIX-like library file system. Four additions to XN: Maps UNIX representation access control (uids and gids, etc.) to those of Exokernel capabilities. UNIX specific file styling. Performs locking to ensure that its data is always recoverable. Ensures that certain state transitions are implicit on certain actions.

Exokernels and Application-Level Networking Network Software Architecture Kernel Functions ExOs Networking Abstractions

ExOs Networking Abstractions UDP/IP TCP/IP Listen/Accept Timers and Timeouts TIMEWAIT Performance

What are the benefits and costs? Unnecessary abstractions and functionality are not present in memory Expect system performance to improve (ex. CPU scheduling…) Library OS functions are easy to modify and debug Modification of a kernel VS. modification of library functions Difficult to port Since the kernel is customized for specific hardware configurations

END