Advanced Development of Certified OS Kernels

1. Advanced Development of Certified OS Kernels Zhong Shao Bryan Ford Yale University November 2010 http://flint.cs.yale.edu/ctos Focus Areas: Operating Systems, Programming Languages, Formal Methods

2. VIEW #1: bug-free host impossible. Treat it as a biological system. Certifying a computing host? Formal proofs for resilience, extensibility, security? • Need to reason about: • human behaviors • cosmic rays + natural disasters • hardware failure • software

3. HW & Env Model Certifying a computing host? Formal proofs for resilience, extensibility, security? • Need to reason about: • human behaviors • cosmic rays + natural disasters • hardware failure • software VIEW #2: focus on software since it is a rigorous mathematical entity!

4. 0101101010101010111110001100111011011111110101010101010101010101011111111101010101010111100011000101010101010101111110001100100111100111111110011111110001111000101010101111110111001100111010101011111110001111000111000111001101011010101010101111100011001110110111111101010101010101010101010111111111010101010101111000110001010101010101011111100011001001111001111111100111111100011110001010101011111101110011001110101010111111100011110001110001110011 Formal specs & proofs for resilience, extensibility, security? SOFTWARE HW & Env Model Certified software? • Find a mathematical proof showing that • if the HW/Env follows its model, the software will run according to its specification

5. HW & Env Model Certified OS kernel? 010110101010101011111000110011101101111111010101010101010101010101111111110101010101011110001100010101010101010111111000110010011110011111111001111111000111100010101010111111011100110011101010101111111000111100 Application & other system SW Formal specs & proofs for resilience, extensibility, security? 0101101010101010111110001100111011011111110101010101010101010101011111 Certified kernel SW TODO: design & develop new OS kernel that can “crash-proof” the entire SW need new programming language for writing certified kernels need new formal methods for automating proofs & specs

6. Our approach • Clean-slate OS kernel design & development • extensibility via certified plug-ins • resilience via history-based accountability & recovery • security via information flow control • New PLs for building certified kernels • vanilla C & assembly but w. specialized program logics • DSL-centric framework for certified linking & programming • new DSLs & history logics for certifying kernel plugins • New formal methods for automating proofs & specs • VeriML and type-safe proof scripts • automated program verifiers & tools

7. Clean-slate kernel design • No more “base kernel” per se • it is nothing but interacting plug-ins • The entire kernel is composed of modular, replaceable, and individually certifiable plug-ins • Different plug-in classes implement different kernel functions --- embodying different safety and correctness model • device drivers for specific types of HW • resource managers (schedulers, memory managers, file sys) • protected executors implementing different secure “sandboxes” • boot loaders and initialization modules

8. Extensibility via certified plug-ins • each kernel extension is not just “safe” but also “semantically correct” • protected executors replace the traditional “red line” • efficient nested virtualization and inter-process communication (IPC)

9. History-based accountability • Novel kernel primitives & executors for supporting resilience • keep a complete history log • replay, backtrack, recover as we wish • How to make this efficient? • enforce “determinism” to avoid logging nondeterministic events • system-call atomicity for consistent check-pointing (as in Fluke) • New techniques for history optimization & compression

10. Information flow control (IFC) • New kernel primitives for explicit control of IFC labels • follow previous work on HiStar & Loki • but want to have the security monitors (or plug-ins) certified • and also enforce IFC across heterogeneous “executors” • challenge: how language-based IFC (eg Jif) differs from OS-based ones? • New techniques addressing covert timing channels • timeshare the processes without restriction • but enforce “determinism” to prevent each process from reading the time • a “read time” request would lead to an IFC “taint” fault • the handler will migrate the process to a non-time-shared CPU

11. Outline of this talk • Clean-slate OS kernel design & development • extensibility via certified plug-ins • resilience via history-based accountability & recovery • security via information flow control • New PLs for building certified kernels • vanilla C & assembly but w. specialized program logics • DSL-centric framework for certified linking & programming • new DSLs & history logics for certifying kernel plugins • New formal methods for automating proofs & specs • VeriML and type-safe proof scripts • automated program verifiers & tools

12. HW & env model CPUs Dependability claim & spec Devices & Memory Human & the Physical World Proof No Proof checker machine code Yes Components of a certified framework • certified software (proof + machine code) • dependability claim & spec • HW & env model • mechanized meta-logic • proof checker

13. … threads … ctxt ctxt ctxt spawn, yield, exit, lock, monitors, … scheduler bootloader OS Case study: a Mini-OS 1300-line 16bit x86 code, Bootable! . . . . . . KBD timer interrupts How to certify this code?

14. Concurrency Interrupts Certifying the Mini-OS 1300 lines of code Many challenges: bootloader Code loading scheduler Low-level code: C/Assembly timer int. handler thread lib: spawn, exit, yield, … sync. lib: locks and monitors Device drivers / IO keyboard driver Certifying the whole system keyboard int. handler Many different features … Different abstraction levels

15. L2 L1 L4 L3 Domain-specific program logics • One logic for all code • Consider all possible interactions. • Very difficult! • Reality: domain-specific logics • Only limited combinations of features are used. • It’s simpler to use a specialized logic for each combination. • Interoperability between logics For each DSL, use as much automation as possible!

16. OS Cn Cn C1 C1 … … C1 C1 Cn Cn L1 … Ln Our solution … OCAP Formalized HW & env model Mechanized meta-logic

17. A toy machine (data heap) H f1: I1 addu … lw … sw … … j f pc 0 1 2 … f2: I2 r1 r2 r3 … rn f3: I3 (register file) R … (code heap) C (state) S ::=(H,R) (instr. seq.) I ::={fI}* (program) P ::=(C,S,pc)

18. 1 2 3 Program specifications (spec) ::={f}* (data heap) H  f1: I1 addu … lw … sw … … j f pc 0 1 2 … f2: I2 r1 r2 r3 … rn f3: I3 (register file) R … (code heap) C (state) S ::=(H,R) (instr. seq.) I ::={fI}* (program) P ::=(C,S,pc)

19. may use different  … C1 Cn Domain-specific logics How to link modules? L1 … Ln OCAP Rules Formalized HW & env model Mechanized meta-logic

20. ( _ )t (_)h How to link modules? f: … … … … call f {r1:1, …, rn:n} {P}_{Q} a a'

21. {r1:1, …, rn:n} {P}_{Q} ( _ )t (_)h a a' How to link modules (cont’d)? How to define interpretation? Encode the invariant enforced in our invariant-based proof methodology. ashould be expressive enough to encode Inv.

22. TAL XCAP SCAP AIM … … C1 Cn L1 Ln … Sound ( )L1 ( )Ln The OCAP framework [TLDI'07,VSTTE’08] an Open framework for Certified Assembly Programming Sound OCAP Inference Rules OCAP Soundness Formalized HW & env model Mechanized meta logic

23. DSLs for writing certified plug-ins SCAP: stack-based control abstractions [PLDI’06] SAGL: modular concurrency verification [ESOP’07] CMAP: dynamic thread creation [ICFP’05] XCAP: embedded code pointers [POPL’06] GCAP: dynamic loading & self-modifying code [PLDI’07a] Certified garbage collectors & linking w. mutators [PLDI’07b,TASE’07] Certified context switch libraries [TPHOLs07] AIM: preemptive thread impl. w. HW interrupts [PLDI’08,VSTTE’08] Certified code running on relaxed memory models [ESOP’10] HLRG: certified code w. optimistic concurrency [CONCUR’10] See http://flint.cs.yale.edu for more details

24. New OCAP & DSLs • More realistic HW & environment modeling • Extend OCAP to certify advanced security & correctness properties • semantic model parameterized over the HW & env semantics • identify invariants for different plug-in classes & executors • certified linking of heterogeneous components • New DSLs to certify kernel plug-ins • virtual memory management • thread & process management & IPC • file system

25. New OCAP & DSLs (cont’d) • New DSLs for deterministic concurrency • New DSLs for informational flow control (IFC) • language-based IFC vs OS-based IFC • variable- vs file or process granularity • relationship w. rely-guarantee & concurrent separation logic • New DSLs for persistence, recovery, and SW transaction • based on our new history logic HLRG [CONCUR’10] • combining temporal reasoning with local rely-guarantee • pre/post conditions and invariants specify history traces

26. Outline of this talk • Clean-slate OS kernel design & development • extensibility via certified plug-ins • resilience via history-based accountability & recovery • security via information flow control • New PLs for building certified kernels • vanilla C & assembly but w. specialized program logics • DSL-centric framework for certified linking & programming • new DSLs & history logics for certifying kernel plugins • New formal methods for automating proofs & specs • VeriML and type-safe proof scripts • automated program verifiers & tools

27. Sep. Logic Utilities (e.g. Queues) Certified thread impl. in Coq [PLDI’08] 12,000 26,000 Locks, Condition variables Timer handler, yield/sleep switch, block, unblock AIM Logic & Soundness SCAP 1,300 26,000 OCAP 1,700 4,000 6,300 x86 semantics (a subset) 3,300 Coq (Higher-Order Logic with Inductive Def.) Around 82,000 lines of Coq code See http://flint.cs.yale.edu/publications/aim.html

28. Related projects • seL4 [Klein et al SOSP’09] in Isabelle/HOL • 8700 lines of C and 600 lines of assembly • 7500 lines of C certified in 24 person years • the rest is not certified (assembly, initialization & virtual memory) • no concurrency, interrupts, mem alloc in the kernel • Verve [Yang & Hawblitzel PLDI’10] in Boogie/Z3 • 1400 lines of assembly (nucleus) + C# kernel from Singularity • the nucleus certified in 9 person months • C# kernel compiled to TAL via a type-preserving compiler • no proof objects; linking not certified; no meta theory for TAL Challenge: need both automation (from first-order provers) & expressiveness (from Coq / HOL)

29. VeriML [ICFP’10] • Proofs are more effectively done by writing new tactics: we define them as “functions that operate on logical terms (specs & proofs) and produce other logical terms” • VeriML --- a new general purpose PL for manipulating logical terms • ML core calculus (keep expressivity) • extended w. dependent types for logical terms • but can still “operate on” logical terms • use a logic similar to HOL w. inductive defs & explicit proof objects • VeriML type system guarantees validity of logical terms & safe handling of binding See http://flint.cs.yale.edu/publications/veriml.html

30. VeriML vs Coq Three ways to write tactics: • ML • untyped tactics, high barrier; requires knowledge of implementation internals • LTac • untyped tactics, somewhat limited programming model • Proof-by-reflection • strong static guarantees but very limited programming model VeriML enables all points between no static guarantees to strong ones, yet with full ML programming model

31. Automated program verifiers & tools • Build certified program verifiers for each DSL • some are decidable • Develop new VeriML tactics • certifying compiler, linker, assembler • static analysis • decision procedures (e.g., Omega, SMT solvers) • Connecting with first-order theorem provers • let them generate hints or witnesses • add an additional validation phase to build the proof objects • Better proof witness: type-safe VeriML proof scripts

32. Formal specs & proofs for resilience, extensibility, security? HW & Env Model Conclusions 010110101010101011111000110011101101111111010101010101010101010101111111110101010101011110001100010101010101010111111000110010011110011111111001111111000111100010101010111111011100110011101010101111111000111100 Application & other system SW • Key innovations: • new OS kernel that can “crash-proof” the entire SW • new PLs for writing certified kernel plug-ins (new OCAP + DSLs) • new formal methods for automating proofs & specs (VeriML)

33. Advanced Development of Certified OS KernelsProf. Zhong Shao (PI) & Prof. Bryan Ford (Co-PI), Yale University PROPOSED ACHIEVEMENT • Machine-checkable formal guarantees about OS kernel safety and security • Reliable crash recovery & accountability mechanisms • A solid base for building adaptive immunity mechanisms • A new programming paradigm for building certified bug-free software STATUS QUO EXPECTED IMPACT Components in traditional OS kernels can interfere with each other in arbitrary way. • A single kernel bug can wreck the entire system’s integrity & protection • Poor support for recovery & security • MAIN OBJECTIVE: • To develop a novel certified OS kernel that offer (1) safe & application-specific extensibility, (2) provable security properties with information flow control, and (3) accountability & recovery from hardware or application failures. • KEY INNOVATIONS: • Secure & flexible kernel via certified plug-ins • History-based accountability & recovery mechanism • Provably correct security monitor for IFC • A new DSL-centric open framework for certified decomposition & programming & linking • New DSLs/history-logic for certifying kernel modules • Novel VeriML language & tools that can combine automation with modular proofs OTHER UNIQUE ASPECTS Synergistic co-development effort combining novel advances in OS, prog lang & env, and formal methods • New VeriML/OCAP programming evironment for building certified system software NEW INSIGHTS Only a limited set of features at certain abstraction layer are used in specific kernel modules • Structure the kernel using certified abstraction layers will minimize unwanted interferences & maximize modularity and extensibility A crash-proof computing host needs to have a certified OS kernel to serve as its bedrock.