Kernels

1. Kernels Uri Moszkowicz 04/04/2002

2. Overview • Extensible • Aegis,Xok/ExOS • SPIN • Macro vs micro • Amoeba • CHORUS • Mach

3. Extensible Kernels • Definition / purpose • Can be changed dynamically to meet the needs of an application • Previous work • Better OS abstractions that give better control to application (previous papers) • Implementations • User libraries • Virtual machines • Downloading into kernel

4. Aegis,Xok/ExOS • Monolithic = exokernel + user libraries • Exokernel = Aegis (MIPS), Xok (x86) • Securely expose hardware (little abstraction) • Expose allocation (of resources) • Expose names (of physical resources) • Expose revocation (of resources) • User libraries = ExOS • Resource management (ie time-slices)

5. Aegis,Xok/ExOS

6. Aegis,Xok/ExOS • Resource allocation • Handled by ExOS, but among libraries kernel must allocate • Secure bindings performance considerations • Only at bind time • Hardware, software caching, and downloading application code

7. Aegis,Xok/ExOS • Downloading code into kernel • To deal with real-time constraints • Avoids crossing kernel/user boundary and circumvents resource allocation • Safety limited to code inspection • Resource revocation • For misbehaving applications • Handled by “Abort” protocol

8. Aegis,Xok/ExOS • Case studies • Dynamic Packet Filter • Dynamic code generated at runtime to classify packets • Tested at user-level, but more appropriately downloaded into kernel

9. Aegis,Xok/ExOS • XN • Provides stable storage at disk block level • Eliminates need for fixed partitions • Only provides protection • C-FFS implemented UNIX-like file system

10. SPIN • Monolithic kernel extendable through modules that can be dropped in • Goals • Co-location (located w/in kernel address) • Modularity • Protection domains (namespace/exports) • Dynamic call binding (event handlers) • Similar to Linux modules + Cyclone

11. SPIN • Protection for kernel code relies on type-safe language features of Modula3 • Combination of static and dynamic checks which enforce memory regions and verify memory references • Applications written in any language

12. SPIN • Protection model • Resources accessed through capability pointers located in a table accessible by both kernel and user • Similar to /proc interface + symbol table • Extension components • Events – announces change in system • Handler – Responds to the event • Dispatcher – Notifies handler of events filtered by guards (predicates)

13. SPIN • Overview Event Handler Guards Application Capabilities Resources Protection Domains

14. SPIN • Services • Core services • Provides capabilities to manage processor and memory • Thread management • Can be easily integrated with kernel because application can drop its own thread package into kernel

15. Extensible Kernels • Summary • Goal is to minimize overhead of accessing resources and provide application ability to efficiently use and allocate resources • Ultimately, application needs access and capability to affect resources on a global scale • Comments?

16. Macro vs Micro Kernels • The argument • What, and how much, belongs in the kernel? • Philosophy • Micro-kernel • Kernel should be minimal in size, handling basic operations • Ex: the extensible kernels just described, MACH, OS-X • Macro-kernels • Applications conform to high-level abstractions, knowing little or nothing about hardware

17. Amoeba • Objective • Illusion of single powerful timesharing machine • User has no knowledge of… • Where files are located • Which processors their programs are running on • Etc • Organization • Based around capabilities as in SPIN

18. Amoeba

19. Amoeba • System arranged as a combination of workstations and servers which communication with simple primitives • Get_request (server ready to accept) • Put_reply (server replying with result of operation) • Do_operation (perform the requested operation) • Kernel handles messaging, scheduling, memory management • Servers run at user-level and handle everything else

20. Amoeba • Servers • Network organized into domains of LANs that communicate of WANs • Each domain maintains a Service for Wide-Area Networks server, which maintains a list of published servers • When a user process needs access to a server, it accesses the service transparently

21. Chorus • Another attempt at reorganizing the OS • Like Amoeba, implemented such that the application knows very little about what is underneath it • Intended for distributed systems • Unlike Amoeba, Chorus handles real-time constraints and provides services, such as traditional operating systems, as subsystems running on top of Chorus Nucleus (kernel)

22. Chorus • Basic components • Nucleus – provides generic tools to support subsystems (ie functions of specific OS); handles functions such as transparent IPC, VM, real-time • Subsystems - traditional OS functions separated into groups normally provided by the kernel • Libraries still exist at user level to provide convenient programming interfaces

23. Chorus

24. Chorus • Subsystem components • Actor – encapsulates a set of resources • Thread – sequentially executed code • Port – address used for communication between actors • Segment – data encapsulation (ie files) • Capability – access control

25. Chorus

26. Chorus • Communication • Ports can be grouped, allowing for easy implementation of state machine replicas and reconfiguration

27. Chorus • Virtual memory • Handled in units of segments by a mapper, allowing for easy use of ports

28. Chorus • Chorus/MiX – UNIX subsystem

29. MACH • Another distributed OS based on an extensible micro-kernel • Similar to other distributed systems where OS functions are provided above the kernel • Fast IPC, which forms the basis for communication between all tasks and even the kernel • As before, implementation exists for compatibility with UNIX • Basis for many OS, including OS-X, NeXT OS, and even OS/2

30. Summary • Which is better? A micro or macro kernel? No real good answer • Many systems exist which implement both and have been successful • Comments?