1. Extensibility, Safety and Performance in the SPIN Operating SystemBrian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, David Becker, Marc Fiuczynski, Craig Chambers, Susan Eggers Presented By Ninad Palsule

2. DBMS 1 User 2 Kernel Log page Data page buffer Storage Motivation • General purpose OS • Specialized OS • Application needs a resource control • Ex. DBMS • Hard: Support specialization in general purpose OS

3. Why it is hard? Ref: Fig from presentation prepared by Author from http://www-spin.cs.washington.edu/

4. SPIN • Design Goals • Extensibility • Incremental changes • Safety • Correctness • Good performance • Efficiency

5. SPIN • Approach • Language and compiler support • Runtime facility • Techniques • Co-location • Requires dynamic linking • Provides low cost communication • Enforced modularity • Modula – 3 • Compiler enforce interface between modules • Can’t access memory or execute privileged instruction unless access given through interface • Modularity enforced by the compiler enables modules • Logical protection domains • Dynamic linker resolve code in different logical protection domain • Dynamic call binding • System Events

6. Extensibility

7. Extension model • Property of Extension • Easy to apply • Transparent • Efficient • Dynamically linked to Kernel address space • Provide controlled communication between Extension and Base system • Extensions defined in terms of Event and Handler

8. Extension model • Event raised • Dispatcher call guards and handlers • Evaluating guards • If guard true then call handler • Safety issues • Type checking • Access Control • Denial of service • Runaway handlers • Too many handlers Ref: Fig from paper 2 in Reference

9. Example: System call Ref: From presentation prepared by Author of paper 2.

10. Programmer’s view Ref: From presentation prepared by Author of paper 2.

11. SPIN structure Ref: Fig from presentation prepared by Author from http://www-spin.cs.washington.edu/

12. Application: Video system components Ref: Fig from Author presentation from http://www-spin.cs.washington.edu/

13. Safety

14. Modula – 3 support for SPIN • Type Safety • Array index checks (static & dynamic) • Pointer-safe casting • “VIEW” used to safe cast • Size of input should match with typed structure • Alignment should match • Isolation of untrusted code • Terminating untrusted code • “EPHEMERAL” procedure tag for killable procedures • Isolating errors in untrusted code • Implicit exception for unhandled exception • Enforce modularity • Interface, Modules and procedures • Automatic storage management

15. Protection model • Control set of operations on resource • Conventional OS uses Address space as a protection model • SPIN • Capabilities • Protection domain

16. Capabilities • Implemented using pointers • Pointer is a reference to block of memory whose type is declared within interface. • Externalized Reference before sending to user space • Unforgeable reference to resources (system object and interfaces) • Extension reference resources for which they have valid access • Interfaces protected to allow different extensions to have different views on services

17. Protection domains • Set of accessible names available for execution context • Naming and protection interface at level of language • Name ‘c’ is a instance of type ‘Console.T’ • Domains can be intersecting or disjoint

18. Domain interface

19. Export/Import domain at run-time Fig from paper [2]

20. Core Services

21. Core Services • Manages Memory and Processor resources • Export interfaces for Extensions • Extensible Memory management • Three components: Physical storage, Naming(virtual address) and Translation • Extensible thread management • Strands – No state, share processor • Application provide its own thread package • Scheduler runs in Kernel • Checkpoint and Resume events • Block / Unblock Events

22. Performance

23. Methodology • Comparative study • SPIN V0.4 • DEC OSF/1 V2.1 (Monolithic OS) • Mach 3.0 (Micro-kernel) • Hardware • DEC Alpha 133 MHz AXP 3000/400 workstation, 64 MB RAM, 512 KB unified external cache • Tests • Micro benchmarks • End-to-end performance • Networking

24. Micro benchmark – Protected communication • NULL procedure call • Protected in-kernel : SPIN’s cross domain procedure call • Cross Address space call: SPIN’s extension Protected communication overhead in microseconds

25. Micro benchmark: Thread Management overhead

26. Network Latency and Bandwidth

27. End-to-end performance

28. Conclusion • It is possible to achieve all three in single OS (Extensibility, Safety and Performance) • Extend easily with dynamic linking • Use of language and compile with Event facility for safety • Communication cost is low • Issues • Dispatcher performance? • Does it solve all Safety issues? How do we test correctness? • Language restrictions, changes in Modula - 3

29. References • Extensibility, Safety and Performance in the SPIN Operating SystemBrian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, David Becker, Marc Fiuczynski, Craig Chambers, Susan Eggers • Dynamic Binding for an Extensible System, Przemyslaw Pardyak and Brian Bershad • Safe Dynamic Linking in an Extensible Operating System, Emin Sirer, Marc Fiucynski, Przemyslaw Pardyak, Brian Bershad • Language Support For Extensible Operating System, Wilson Hsieh, Marc Fiuczynski, Charles Garrett, Stefan Savage, David Becker, and Brian Bershad • SPIN Operating System web site: Documentation and source code http://www-spin.cs.washington.edu/