1 / 25

G22.3250-001

G22.3250-001. Extensibility: SPIN and exokernels. Robert Grimm New York University. Preliminaries. Please remember one reading summary per paper! Reviews are an essential component of this class Project, milestone 1 Due 2/8/05 before class PDF, emailed to me

guy-william
Download Presentation

G22.3250-001

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. G22.3250-001 Extensibility:SPIN and exokernels Robert Grimm New York University

  2. Preliminaries • Please remember one reading summary per paper! • Reviews are an essential component of this class • Project, milestone 1 • Due 2/8/05 before class • PDF, emailed to me • Project proposal and related work in one (~3 pages) • What is the problem? Why does it matter? • What is your overall solution? What are non-goals? • What resource do you need? • What have others done in that domain and related domains?

  3. The Three Questions • What is the problem? • What is new or different? • What are the contributions and limitations?

  4. OS Abstraction Barrier • Fixed high-level abstractions • Hurt application performance • Hide information • Limit functionality • Examples • Buffer cache management • Persistent storage

  5. Goals • Extensibility • Applications introduce specialized services • Safety • Kernel, applications, services are protected • Performance • Extensibility and safety have low cost

  6. Why Is This Hard?

  7. Two Approaches

  8. SPIN Approach • Put extension code in the kernel • Cheap communication • Use language protection features • Static safety • Dynamically impose on any service • Fine-grained extensibility

  9. The Big Picture

  10. Modula-3 • Type-safe programming language • Interfaces • Garbage collection • Other features • Objects, generic interfaces, threads, exceptions • Most of kernel written in Modula-3 • Drivers “borrowed” from DEC OSF/1 • Extensions must be written in Modula-3 • User-space applications written in any language

  11. Safety • Capabilities • Simply a pointer • Can we pass capabilities to user-land? • Protection domains • Language-level • Limit visibility of names • Enforced at dynamic link time

  12. Extensibility • Extension model • Events • Indicate the occurrence of some condition • Event handlers • May execute synchronously, asynchronously, or in bounded time • Guards • Restrict invocation of event handlers based on arguments • Mechanism • Event dispatcher • Common case: an (indirect) procedure call • Module implementing the interface

  13. Core Services • Memory management • Physical addresses • Virtual addresses • Translations • Thread management • Signals to scheduler • Block, unblock • Signals to thread manager • Checkpoint, resume

  14. Performance • It works

  15. Exokernels Approach • Make the application do it!

  16. Exokernels Approach (again) • Separate protection and management • Expose allocation • Expose names • Expose revocation • Expose information

  17. The Big Picture

  18. At The Core Aegis: MIPS-based DECstations Xok: x86-based PCs • Processor time slices • Processor environments • Hardware exceptions (Aegis, Xok) • Timer interrupts (Aegis, Xok) • Protected entries (Aegis, Xok) • Addressing • Aegis: Guaranteed mappings, applications notified of TLB misses • Xok: Hardware page tables, applications specify mappings • Hierarchical capabilities (Xok only) • Book keeping

  19. How to Protect Shared Abstractions? • Software regions • Provide access to memory only through system calls • Are typically more fine-grained than pages • Hierarchically-named capabilities • Easily restrict access • Wakeup predicates • Ensure that processes get their time in the limelight • Robust critical sections • Provides isolation with low overhead and without requiring cooperation

  20. Separate Protection and Management: The Disk • Problem • How to store meta-data? • Ownership of disk blocks • Failed approaches • Simple capabilities • Where to put the capabilities? In the block? A separate area? • Self-descriptive meta-data • How expressive is the description language? • How much space is used for descriptions? • Template-based descriptions • Again, how expressive is the description language?

  21. The Disk (cont.) • Untrusted deterministic functions • Programmatic templates that specify pointed-to blocks • Shared data • System-wide buffer cache registry • Entries can be locked • Ordered disk writes • Ensure consistency after crash • Never reuse on-disk resource before nullifying pointers • Never create pointers before pointed-to data has been initialized • Never reset old pointer before new one has been set

  22. Performance • It works • It scales

  23. Issues • SPIN • Trusted compiler • Resource control

  24. Issues (cont.) • Exokernels • Extension model • Downloaded code • Wakeup predicates • Dynamic packet filters • Application-specific handlers • Untrusted deterministic functions • Complexity of disk management

  25. What Do You Think?

More Related