This document discusses exokernels as an alternative to traditional monolithic operating systems. Exokernels export physical resources like processors and memory directly to applications instead of emulating hardware. Library operating systems provide specialized abstractions to applications and run at the application level rather than being trusted components. The document outlines exokernel design principles like secure bindings and visible resource revocation. Testing showed exokernels had significantly better performance than traditional operating systems and specialized libraries could efficiently implement OS abstractions. However, exokernels do not provide total mediation of resources and only authorize usage during binding.
Download as PPTX, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
230 views
Exo Kernel
This document discusses exokernels as an alternative to traditional monolithic operating systems. Exokernels export physical resources like processors and memory directly to applications instead of emulating hardware. Library operating systems provide specialized abstractions to applications and run at the application level rather than being trusted components. The document outlines exokernel design principles like secure bindings and visible resource revocation. Testing showed exokernels had significantly better performance than traditional operating systems and specialized libraries could efficiently implement OS abstractions. However, exokernels do not provide total mediation of resources and only authorize usage during binding.
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 17
Exokernels as an alternative to
Traditional Operating Systems
Akhand pratap singh Contents Exokernels Overview vs. traditional kernels Library Operating Systems Design Principals Secure Bindings Visible Resource Revocation Abort Protocol Testing Hypothesizes Results/Conclusion Is it secure?
Exokernels The main goal of an exokernel: The separation of protection from management
Instead of emulating hardware resources, it exports them directly to the applications
In addition to the exokernel, a Library OS can act as an abstraction layer between hardware and application
Exokernels vs. Traditional Kernels Fixed, high-level abstractions, provided by kernels to enable as many types of applications to run on the system, tend to have a very high cost in system resources Hurts the performance of applications Hides information from applications Limits the functionality of applications Exokernels vs. Traditional Kernels Exokernels exist as a thin layer on top of the hardware that multiplexes and exports physical resources securely
The idea is that an application will better know how it wants to manage its resources than a monolithic kernel or microkernel Exokernels Library OS Multiple Library Operating Systems can exist Exist to provide specialized abstractions One OS might cater specifically to networking
Library OS are not trusted by the exokernel They are free to trust the applications They run on the application level themselves
Allow applications to be ran on any hardware
Exokernel Diagram
Exokernel Design Principals Securely expose hardware Avoid hardware management, except when required for the protection of the system
Expose allocation to Library OS Expose names of physical resources Expose revocation protocol Techniques of Secure Exportation Secure Bindings Allows applications to securely bind themselves to resources Visible Resource Revocation Applications participate in a resource revocation protocol Abort Protocol The exokernel can forcibly break secure bindings of uncooperative applications Secure Bindings Protection mechanism that separates authorization from the use of a resource Authorization only checked at bind time Applications responsible for resources with complex hardware semantics (networks, file systems, etc.) This frees up the exokernel to perform access checks at access time Allows the kernel to protect hardware resources without needing to understand them Visible Resource Revocation Traditionally, resource revocation is invisible to applications in monolithic and micro-kernels
By exposing resource revocation, the exokernel allows applications and Library OSs to monitor resource usage and act accordingly
Abort Protocol Allows the exokernel to retrieve resources from a Library OS that is not responding to revocation requests Revocation request Please return a memory page Revocation imperative Return a memory page within 50 microseconds Secure binding is broken, and the Library OS sent a repossession exception Exokernel Testing Aegis an experimental exokernel Exports the processor, physical memory, exceptions, interrupts, and network resources ExOS an experimental Library OS Provides processes, virtual memory, user-level exceptions, interprocess abstractions, and several network protocols Ultrix is a mature monolithic Unix-based OS
Hypothesizes Exokernels are very efficient
Low-level, secure multiplexing can be efficient
Traditional OS abstractions can be implemented efficiently at application level
Applications can create special-purpose implementations of these abstractions Results vs. Ultrix Both Aegis and Ultrix ran on the same hardware
No overhead added to procedure calls
Exception dispatch about 100x faster in Aegis
ExOSs implementation of pipes about 100x faster
Conclusion to Testing All four hypothesizes were proven to be correct when compared to Ultrix
Results show that the exokernel design is well suited as a high-performance, extensible OS. Additionally, previous research found that applications benefit greatly from specialized abstractions, and ExOS backed those conclusions up as well Is it secure? Total mediation: NO OS does very little resource management and only authorizes resource usage at bind time Trustworthy: YES Only the exokernel is part of the TCB, with the Library OSs being ran at application level Verifiable: YES Kernel is extremely small, with only two goals: Present hardware resources Do so securely