1. EXOKERNEL Gabriel Beltran John Blackman David Martin Kurt Rohrbacher
Matt Sechrist

2. 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)

3. 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

4. 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.

5. 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.

6. 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

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

8. 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.

9. 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.

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

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

12. 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

13. END