Advanced Development of Certified OS Kernels Zhong Shao Bryan Ford Yale University November Focus Areas: Operating Systems, Programming Languages, Formal Methods

Certifying a computing host? Formal proofs for resilience, extensibility, security? Need to reason about: human behaviors cosmic rays + natural disasters hardware failure software 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 VIEW #2: focus on software since it is a rigorous mathematical entity! HW & Env Model

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

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

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

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

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)

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

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

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

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

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

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

L1L1 L2L2 L3L3 L4L4 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!

OCAP Our solution LnLn … L1L1 Mechanized meta-logic Formalized HW & env model … C1C1 CnCn C1C1 C1C1 CnCn … OS CnCn … C1C1 CnCn

A toy machine I1I1 f1:f1: I2I2 f2:f2: I3I3 f3:f3: … (code heap) C 0 r1r1 12… r2r2 r3r3 …rnrn (data heap) H (register file) R (state) S addu … lw … sw … … j f (instr. seq.) I (program) P::=(C,S,pc) ::=(H,R) ::={f  I} * pc

Program specifications I1I1 f1:f1: I2I2 f2:f2: I3I3 f3:f3: … (code heap) C 0 r1r1 12… r2r2 r3r3 …rnrn (data heap) H (register file) R (state) S addu … lw … sw … … j f (instr. seq.) I (program) P::=(C,S,pc) ::=(H,R) ::={f  I} * pc 11 22 33 (spec)  ::= {f   } * 

Mechanized meta-logic OCAP Rules LnLn … Domain-specific logics Formalized HW & env model L1L1 … C1C1 CnCn may use different  How to link modules?

{r 1 :  1, …, r n :  n } {P}_{Q} call f ( _ ) t a ( _ )h( _ )h a' ………… f: …………

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

OCAP Inference Rules The OCAP framework [TLDI'07,VSTTE’08] LnLn … L1L1 … C1C1 CnCn ( ) L1 ( ) Ln Sound OCAP Soundness Mechanized meta logic Formalized HW & env model XCAPSCAPTAL … AIM an Open framework for Certified Assembly Programming

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 for more details

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

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

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

Certified thread impl. in Coq [PLDI’08] Coq (Higher-Order Logic with Inductive Def.) x86 semantics (a subset) Sep. LogicUtilities (e.g. Queues) Around 82,000 lines of Coq code 3,300 6,300 4,000 OCAP AIM Logic & SoundnessSCAP Locks, Condition variables Timer handler, yield/sleep switch, block, unblock 1,700 1,300 26,000 12,000 See

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)

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

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

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

Application & other system SW Conclusions Formal specs & proofs for resilience, extensibility, security? HW & Env Model 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)

Advanced Development of Certified OS Kernels Prof. Zhong Shao (PI) & Prof. Bryan Ford (Co-PI), Yale University A crash-proof computing host needs to have a certified OS kernel to serve as its bedrock. 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 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 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 EXPECTED IMPACT OTHER UNIQUE ASPECTS PROPOSED ACHIEVEMENT STATUS QUO 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 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