1 / 44

Extensible Kernels: Enhancing OS Services Management and Security

This document explores the concept of extensible kernels, emphasizing their role in the management and protection of traditional operating system services. It presents a comprehensive set of abstractions including processes, threads, virtual memory, and inter-process communication (IPC). Key challenges in concurrent execution, resource allocation, and security are discussed, along with the impact on performance and extensibility. The paper delves into exokernels and library operating systems, advocating for application-controlled management to optimize resource management and improve application performance.

ulf
Télécharger la présentation

Extensible Kernels: Enhancing OS Services Management and Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extensible Kernels Amar Phanishayee

  2. Traditional OS services – Management and Protection • Provides a set of abstractions • Processes, Threads, Virtual Memory, Files, IPC • Sys calls and APIs (eg: Win32, POSIX) • Resource Allocation and Management • Accounting • Protection and Security • Concurrent execution

  3. Problems(examples coming-up) • Extensibility • Abstractions overly general • Apps cannot dictate management • Implementations are fixed • Performance • Crossing over into the kernel is expensive • Generalizations and hiding information affect performance • Protection and Management offered with loss in Extensibility and Performance

  4. Need for Application controlled management (examples) • Buffer Pool Management In DBs (*) • LRU, prefetch (locality Vs suggestion), flush (commit) • Shared Virtual Memory (+) • use a page fault to retrieve page from disk / another processor

  5. Examples (cont.) • Concurrent Checkpointing (+) • Overlap checkpointing and program being checkpointed • Change rights to R-only on dirty pages • Copy each page and reset rights • Allow reads; Use write faults to {copy, reset rights, restart} * OS Support for Database Management (Stonebraker) + Virtual Memory Primitives for User Programs (Andrew W. Appel and Kai Li)

  6. Examples (cont.) Feedback for file cache block replacement [Implementation and Performance of Application-Controlled File Caching - Pei Cao, et al.]

  7. Down with monarchy! French Revolution - Execution of Louis XVI

  8. Challenges • Extensibility • Security • Performance

  9. Extensible Kernels • Exokernel (SOSP 1995): safely exports machine resources • Higher-level abstractions in Library OS • Secure binding, Visible resource revocation, Abort • Apps link with the LibOS of their choice • SPIN (SOSP 1995): kernel extensions (imported) safely specialize OS services • Extensions dynamically linked into OS kernel • Safety ensured by Programming Language facilities

  10. Exokernels - Motivation • Existing Systems offer fixed high-level abstractions which is bad • Hurt app performance (generalization – eg: LRU) • Hide information (eg: page fault) • Limit functionality (infrequent changes – cool ideas don’t make it through)

  11. Motivation (cont.) • Separate protection from management, mgmt in user space • Apps should use domain specific knowledge to influence OS services • Small and simple kernel – adaptable and maintainable

  12. OS Component Layout Exokernel

  13. Lib OS and the Exokernel • Lib OS (untrusted) can implement traditional OS abstractions (compatibility) • Efficient (Lib OS in user space) • Apps link with Lib OS of their choice • Kernel allows LibOS to manage resources, protects LibOss

  14. Exokernel : Design Principles • Securely expose hardware • Min resource management as required by protection (allocation, revocation) • Expose allocation • No implicit allocation • Expose Names • Expose Revocation • Eg: two-level replacement

  15. Exokernel : Secure Bindings • Lib OSs are untrusted • Authorization at bind time • Authentication at access time (no need to understand semantics – eg: FS permissions, groups) • Techniques • Hardware (TLB) • Software (STLB – Kavita) • download code (direct procedure call, sandboxing, type-safe language)

  16. Secure Bindings • Multiplexing Memory • Record capabilities (ownership, RW) @ bind time • Check capability @ access time • Capability passing to share resources • Multiplexing the Network • Application-specific Safe Handler (ASH) • Download code into kernel (compiled to m/c code @ runtime) • No kernel crossing; Procedure call instead of scheduling (low RTT)

  17. Resource Revocation • Visible Revocation • “please return a memory page” • “return a page within 50 microseconds” • CPU revocation at the end of time-slice • Invisible better when revocations are frequent (due to f/b) • Abort • To revoke resources “by force” from misbehaving processes • repossession vector, repossession exception • Worst case repossession (guarantee)

  18. ExOS + Aegis • Platform – MIPS-based DECstation • Aegis – exokernel • ExOS – library OS • Processes, Virtual Mem, IPC, Network Protocols (ARP/RARP, IP, UDP) • Comparison with Ultrix (tuned monolithic kernel)

  19. Base Cost in microSec 12.5 MHz ~11MIPS 16.6 MHz ~15MIPS 25 MHz ~25MIPS Demultiplexing SysCalls expensive in Ultrix. May have TLB miss in Sys call!

  20. “barebone” unidirectional Protected Control Transfer (microSec) L3 Entering kernel – 71 cycles Exiting Kernel – 36 cycles TLB flush on context switch • Types • Asynchronous (donate only current time slice to callee) • Synchronous

  21. Key to Aegis’ Performance • Easy keeping track of ownership • Provides very little apart from low level multiplexing • Caching secure bindings (STLB) • Dynamic code generation

  22. ExOS IPC • Pipe – shared mem; yield • Pipe’ has code inlining • Shm – Yield to switch (ExOS), Signals (Ultrix) • RPC – single function, no look-up. Cost of emulation in Ultrix using pipes or signals is high

  23. ExOS Virtual Memory + Fast Sys call. - Half the time in look-up (vector). Repeated access to Aegis STLB and ExOS PageTable

  24. ASH and scalability • Ping-pong of counter in a 60-byte UDP packet 4096 times between 2 processes in user space on DECStation5000/125 • Without ASH - response on being scheduled. Round Robin scheduling -> linear increase in RTT.

  25. Exokernel: Summary • Minimal Kernel • Secure multiplexing of resources • Bind time Authorization • Portability • OS Abstractions in user space (Lib OS) • VM, IPC • Apps link with OS of their choice

  26. SPIN • Use of language features for Extensions • Extensibility • Dynamic linking and binding of extensions • Safety • Interfaces. Type safety. Extensions verified by compiler • Performance • Extensions not interpreted; Run in kernel space

  27. Language: Modula 3 • Interfaces • Type safety • Array bounds checking • Storage Management • Threads • Exceptions

  28. Motivation Can we have all 3 in a single OS? From Stefan Savage’s SOSP 95 presentation

  29. SPIN structure From Stefan Savage’s SOSP 95 presentation

  30. Protection model • Capabilities • Pointer as capability • Type safe (compile time check) • Externalized reference

  31. Protection model (cont.) • Protection “domain” • exported interfaces of safe object files • Safe object file = verified by compiler or asserted by the kernel • In-kernel name server • Optional authorization for importing i/f

  32. Events and Handlers • Events • message announcing • Change in state • Request for service • Procedure exported from an interface • Handlers register for events • Multiple handlers

  33. Dispatcher • Central dispatcher – event router • Primary handler • Handler invocation • Synchronous/Asynchronous • Bounded time • Ordered/Unordered

  34. Handler Installation From Brian Bershad’s OSDI 96 presentation

  35. Handler Installation (cont.) From Brian Bershad’s OSDI 96 presentation

  36. Event Handling From Stefan Savage’s SOSP 95 presentation

  37. Core Services: Memory Management • Services • Physical storage : allocate, deallocate, “reclaim” (returns capability) • Naming (virtual) : allocate, deallocate • Translation (mapping) : add/remove/check mapping • Exceptions • BadAddress • PageNotPresent • Extensions use these primitives to define an address space model

  38. Core Services: Thread Management • Strand interface • block/unblock • checkpoint/resume • Global and application-specific schedulers • fault-isolation • Thread model can be defined using these primitives

  39. Microbenchmarks IPC Sockets, SUN RPC Mesgs. In-kernel Call Thread Mgmt All numbers are in microseconds

  40. Performance: Virtual Memory In-Kernel calls are more efficient than traps or messages All numbers are in microseconds

  41. Performance: Networking Lower RTT because of in-kernel extension time in microseconds, Bandwidth in Mbps

  42. End-to-End Performance Networked Video Server CPU utilization (network interface supports DMA)

  43. Issues • Dispatcher scalability • Handler scheduling • Garbage collection

  44. Conclusion • Extensibility without loss of security or performance • Exokernels • Safely export machine resources • Decouple protection from management • SPIN • kernel extensions (imported) safely specialize OS services • Safety ensured by Programming Language facilities

More Related