Exokernel
Summary
- Exokernel Approach to Extensibility
- Examples of Candidate Resources
- Implementing Secure Bindings
- Default Core Services in Exokernel
- Revocation of Resources
- Exokernel Data Structures
- Performance of SPIN and Exokernel
Exokernel Approach to Extensibility
Kernel exposes hardware explicitly to extensions living above it
Decouple authorization of hardware from use
Binds library requests to hardware resources
- returns encrypted key to library
Examples of Candidate Resources
If everything needed an access key, performance would tank due to excess validation. So we limit what needs a key to some examples:
- TLB Entry
- Virtual to physical mapping done by library
- Binding presented to exokernel
- Exokernel puts into hardware TLB
- Process in library OS uses multiple times without exokernel intervention
- Packet Filter
- Predicates loaded into kernel by library OS
- Checked on PKT arrival by exokernel
Implementing Secure Bindings
3 Methods:
- Hardware mechanisms
- e.g. TLB entry
- Software Caching
- “Shadow” TLB in software for each library OS
- Downloading code into exokernel
- Functionally equivalent to SPIN
Default Core Services in Exokernel
- Memory Management
- Library OS can register handler/callbacks to be executed on events like pagefault
- CPU Scheduling
- Linear vector of “time slots”
- Each Library OS gets its own quantum
Revocation of Resources
Exokernel has capability to revoke resources
- Triggers a “clean up” on library OS side
Exokernel Data Structures
Exokernel maintains state on every Library OS that is running
- Timeslice vector
- Software TLB
- PE data structure
- Handlers for different event types
- Entrypoint
- Interrupt
- Syscalls
- Mmap
- Handlers for different event types
Exokernel is basically a large event-handler
Performance of SPIN and Exokernel
SPIN and Exokernel are faster than MACH and as fast as monolithic kernels