An Open Framework for Certified System Software Xinyu

An Open Framework for Certified System Software Xinyu Feng Yale University

Why Certified Software? Mars Polar Lander Mars climate orbiter Ariane 5

Something More Relevant … Fig. from: www. howstuffworks. com “A typical modern car contains around 20 built-in microcontrollers. Luxury models can have as many as 80. Such microcontrollers, …, are in constant communication with one another. In extreme cases, a single programming error in one of the control elements can mean life or death. ” -- Fraunhofer Magazine, 2004 (2)

Photo from edmunds. com Toyota recalled its 160, 000 Prius cars in Oct 2005, because of bugs in the software controlling the hybrid gas-electric engine system…

How to Guarantee Software Quality? We need a “certified” computing platform! Uncertified legacy code becomes second-class citizen! Certified Buggy? Security Infrastructure Certified Buggy? Runtime Services & & Libraries Certified Buggy? Bootloader ++ OS OS ++ Device Driver Hardware We need firm control of the lowest-level software! [King et al. S&P'06]

Certified Software: Problem Definition • Hardware – processors, memory, storage, devices, … • Software specification S – bootloader, device drivers, OS, runtime, applications, binary formal … code C proof P • Need a mathematical proof showing that as long as the hardware works, the software always work according to its specification

A Mini-OS 1300 -line 16 bit x 86 code, … Bootable! threads http: //flint. cs. yale. edu/feng/cos … ctxt spawn, yield, exit, lock, monitors, … scheduler . . KBD . timer . interrupts bootloader But how to certify the code? OS

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

My Contributions • Specialized program logics – – SCAP: stack-based control abstractions [PLDI’ 06] SAGL: modular concurrency verification [ESOP’ 07 ] CMAP: dynamic thread creation [ICFP’ 05] concurrency with relaxed memory model [ongoing work] • An open framework for certified systems – OCAP: embedding and interoperation between different verification systems [TLDI’ 07] – interoperability based on semantic models [ongoing work]

Outline of This Talk • The OCAP Framework • SAGL: modular concurrency verification • SCAP: stack-based control abstractions • Embedding and linking in OCAP

Modules at Different Levels • Example: how to certify multithreaded software? • All concurrency verification assumes built-in concurrency • Context switching, scheduler – Too low-level to be certified in these logics • Threads & schedulers have never been certified in a single logic!

Building Fully Certified Systems • One logic for all code – Consider all possible interactions. – Very difficult! • Reality – Only limited combinations of features are used. – It’s simpler to use a specialized logic for each combination. – Interoperability between logics L 2 L 1 L 4 L 3

Our Solution C 1 … OS Cn C 1 L 1 … … OCAP Cn Ln Modeling of the machine Mechanized Meta-Logic (Ci. C) TCB

The Machine f 1: f 2: f 3: (data heap) H I 1 0 I 2 1 2 r 1 r 2 r 3 I 3 pc … … rn (register file) R … (code heap) C : : ={f I}* (state) S: : =(H, R) (program) P: : =(C, S, pc) addu … lw … sw … … j f (instr. seq. ) I

Program Specifications (spec) : : = {f }* 1 f 1: 2 f 2: 3 f 3: (data heap) H I 1 0 I 2 1 2 r 1 r 2 r 3 I 3 pc … … rn (register file) R … (code heap) C : : ={f I}* (state) S: : =(H, R) (program) P: : =(C, S, pc) addu … lw … sw … … j f (instr. seq. ) I

Invariant-Based Verification P 0 c 1 P 1 c 2 P 2 c 3 … cn Initial condition: Inv (P 0) Progress: if Inv (P), then P’. P c P’. Preservation: if Inv (P) and P c P’, then Inv (P’). Pn

“Domain specific” logics How to link modules? C 1 L 1 … … OCAP Rules Modeling of the machine Mechanized Meta-Logic (Ci. C) may use different Cn Ln

How to Link Modules … … call f {r 1: 1, …, rn: n} f: … … {P}_{Q} ( _ )t ( _ )h a a'

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

An Open Framework A set of Hoare-logic rules as the foundational layer use “a” as the assertion language supports first-class code pointers, mutable references, polymorphisms, recursive types, … XCAP[Ni&Shao'06] approach a (S) = … used and generalized in OCAP [TLDI'07] Indexed approach ai(S) = … [ongoing work with Cai, Shao & Tan] simpler model for weak-ref, partial correctness, concurrency…, than existing work on indexed model [Appel&Mc. Allester'01] [Amed'04] [Appel et al. '07]

The OCAP Framework [TLDI'07] TAL XCAP SCAP C 1 L 1 Sound ( )L 1 SAGL … … Cn Ln Sound OCAP Rules OCAP Soundness … Modeling of the machine Mechanized Meta-Logic (Ci. C) ( )Ln

Outline of This Talk • The OCAP Framework • SAGL: modular concurrency verification • SCAP: stack-based control abstractions • Embedding and linking in OCAP C 1 L 1 SAGL … … Cn Ln SCAP OCAP Modeling of the machine Mechanized Meta-Logic (Ci. C)

Certifying Concurrent Programs How to guarantee non-interference… in a modular way? Existing work is not modular/general…

Certifying Concurrent Programs • Assume-Guarantee (A-G) reasoning [Misra&Chandy’ 81, Jones’ 83] J thread modularity, general L spec of A&G requires global data invariants • Concurrent Separation Logic (CSL) [O’Hearn, Brookes 2004] J thread modularity + local reasoning L restrictive synchronization pattern L shared resources can be accessed only inside critical regions • SAGL: extend A-G with local reasoning [ESOP'07] J improved modularity without loss of generality

Assume-Guarantee Reasoning • Thread T and its environment – Environment: the collection of all other threads except T • A: assumption about environment’s transition • G: guarantee to the environment • a: precondition

A-G Reasoning Non-Interference of threads: i, j. Gi Aj (i j) To certify each thread: stability of precondition: S, S'. a S A S S' a S' transitions satisfy the guarantee: G S Nextc(S)

A-G Reasoning a 1 a 2 Requires global invariants! G 1 a 2 G 2 a 1 A 2 a 2 A 1 a 1 a 2

SAGL: Overview Partition of resources: shared & private Threads specs: (a 1, p 1), (a 2, p 2), … Partition is conceptual: (p 1 p 2) (a 1 a 2) p 2 p 1 a 2

SAGL: Memory Access Threads have exclusive access to their private resources. p 2 p 1 All threads can access shared part. Needs to guarantee non-interference. Follows assume/guarantee reasoning. Partitions can be dynamically adjusted. a 1 a 2

SAGL – Access Shared Resource p 2 p 1 a 2 G 2 a 1 p 2 A 1 a 1 p 1 a 2' A-G reasoning: a special case where p 1 and p 2 are emp.

SAGL – Access Private Resource p 2 p 1 a 2 p 1 p 2 ' a 1 a 2

SAGL - Redistribution p 2 p 1 a 1 a 2' G 2 a 1 A 1 lock a 1 p 1 a 1 p 2 A 1 a 2 G 2 a 1 unlock

Example: List x … get. Node(): -{(ainv , emp)} l. acq(); -{(emp, emp List(x))}; y … -{(emp, Node(y) List(x))} l. rel(); -{(List(x), Node(y))} ainv x … ainv = free(l) List(x) free(l) emp

SAGL [ESOP’ 07] A-G reasoning All threads can access shared part. Needs to guarantee non-interference. Follows assume/guarantee reasoning. p 2 p 1 a 2 Threads have exclusive access to their private resources. Partitions can be dynamically adjusted. CSL

Outline of this talk • The OCAP Framework • SAGL: modular concurrency verification • SCAP: stack-based control abstractions • Embedding and linking in OCAP C 1 L 1 SAGL … … Cn Ln SCAP OCAP Modeling of the machine Mechanized Meta-Logic (Ci. C)

Certifying C & Assembly Code? How to specify/verify control abstractions? Stack-based control abstractions call/return, tail call, exceptions (stack cutting/ stack unwinding), coroutines/threads context switching How to formulate the stack invariants?

Problems – call/return void f(){ void h(){ h(); return; } Stacks are hidden!

Problems – call/return stack R void f(){ void h(){ h(); return; ct ra ? ? } fp } f: pc . . . sw $ra, -4($fp) jal h ct: lw $ra, -4($fp) h: ; ; $ra contains ct jr $ra . . . jr $ra Does f use the right return addr. ?

Problems – setjmp/longjmp jmp_buf env = …; int rev(int x){ void cmp 0(int x, jmp_buf env){ f 0 pc if (setjmp(env) == 0){ pc cmp 0(x, env); env cannot return 0; }else{ cmp 1(x, env); } outlive the void stackcmp 1(int frame x, jmp_buf of rev ! if (x == 0) pc env return 1; longjmp(env, 1); f 0 } else … } … sp … return; } env){

Stack-Based Control Abstractions A simple system (SCAP) for modular verification of (1) compiled C code & (2) manually-written assembly code Function call/return Tail calls PLDI'06 Exceptions: Stack-unwinding Exceptions: Stack-cutting PLDI’ 06 weak-continuation YALEU/DCS/TR-1336 setjmp/longjmp Coroutines (w. function call) Threads context switching TLDI’ 07

Specifications • Challenges – f uses the “right” return addr. ? f: {(p {$ra g 0)} n …} 0, = – Hoare triple {p} f {q}? . . . • In different basic blocks! • SCAP specifications: (p, g) – p: State Prop – g: State Prop g 0 S S’ S’. $ra = S. $ra … sw $ra, -4($fp) jal h g 0 ct: {(p 1, g 1)} g 1 lw $ra, -4($fp) . . . jr $ra {$ra = n …}

Program Spec. and Code Pointers p 0 p 1 • Program Specification : : = {f 1 (p 1, g 1), …, fn (pn, gn)} • “safe” to return (jr $ra): g 0 g 1 p 3 p 4 jr $ra … – $ra dom( ) ($ra)=(p, g) – p holds at the time of return jal f jr $ra g 4 p 2 jal h jr $ra g 3 g 2

SCAP : Stack Invariant Always safe to return? S 0 S 1. $ra (S 1. $ra))=(p 1, g 1) p 1 S 1 g 1 p 2 S 1 S 2 g 0 S 0 S 1 g 1 S 1 S 2 g 2 S 3 g 0 p 1 jr $ra g 0 S 1 S 2. $ra (S 2. $ra)=(p 2, g 2) p 2 S 2 p 0 g 2 p 3 S 3 g 3 S 3. $ra (S 3. $ra)=(p 3, g 3) p 3 S 3 … Logical control stack

SCAP : Stack Invariant WFST(n, g 0, S 0, ) S 0 S 1. g 0 S 1 p 1, g 1. (S 1. $ra)=(p 1, g 1) p 1 S 1 WFST(n-1, g 1, S 1, ) WFST(0, g 0, S 0, ) S 1. g 0 S 1 p 0 g 0 p 1 jr $ra g 1 p 2 S 1 S 2 g 2 p 3 S 3 g 3 Invariant: p S n. WFST(n, g, S, ) Logical control stack

SCAP : Invariant Preservation • Inv(S): p S n. WFST(n, g, S, ) c S p S n. WFST(n, g, S, ) S’ p’, g’ p’ S’ n. WFST(n, g’, S’, )

SCAP: call p S WFST(n, g, S, ) p p 0 S g p 1 jr $ra g 1 n … p 0 S 0 WFST(n+1, g 0, S 0, ) p 0 S 0 g 0 S 1 n+1 jal f S 2 p S p 0 S 0 p S g 0 S 1 p 1 S 1 p S g 0 S 1 g 1 S 2 g S S 2 p 1 jr $ra g 1 n … g 0 S 1 S 2 g 0 S 1 S 0. $ra = S 1. $ra

SCAP: ret p S WFST(n, g S, ) n p 1 S g 1 n-1 p 1 S 1 WFST(n-1, g 1 S 1, ) p g S 1 jr $ra … g 1 n-1 … p S g S S 1 p 1

Generalization: Stack Unwinding/Cutting Multi-ret p 1 p g g 1 jr ra + Tail-call p 1 p g 1 g jr ra p 1 p g jr ra g 1

Example: setjmp/longjmp jmp_buf env = …; void cmp 0(int x, jmp_buf env){ int rev(int x){ if (setjmp(env) == 0){ cmp 0(x, env); return 0; cmp 1(x, env); } void cmp 1(int x, jmp_buf env){ if (x == 0) }else{ longjmp(env, 1); return 1; else } return; } }

Applications of SCAP • malloc/free [Feng et al. PLDI'06, Xiang et al. QSIC'06] • thread scheduler [Feng et al. TLDI'07] • garbage collectors [Mc. Creight&Shao PLDI'07]

Outline of This Talk • The OCAP Framework • SAGL: modular concurrency verification • SCAP: stack-based control abstractions • Embedding and linking in OCAP C 1 L 1 SAGL … … Cn Ln SCAP OCAP Modeling of the machine Mechanized Meta-Logic (Ci. C)

Threads and Scheduler • Thread code C 1, …, Cn – Certified in SAGL • as concurrent code – Do not know about thread queue • Scheduler CS – Certified in SCAP • as sequential code – Manages thread queue TQ – Do not touch H SAGL + SC AP

How to Specify Scheduler/yield i y l a j yield : . |S S 1| . yiel d |S S 2| . jr $ra SAGL SCAP g

Embedding of SCAP Embedding: ((p, g))scap = , S. p S n. WFST(n, g, S, ) Soundness : If ┝scap C: , then ┝ocap C : | | Supports proof reuse.

Embedding of SAGL Embedding: (((a, p), A, G))sagl = l , S. Q={pc 1, …, pcn}. (pci) =((ai, pi), Ai, Gi) In. Mem(Q) (p 1 … pn) (a 1 … an) NI((A 1, G 1), …, (An, Gn)) stable(ai, Ai)

Soundness of SAGL Embedding If ┝sagl C: , then y┝ocap C: | |.

Certifying The System SAGL SC AP ┝scap Cs: y ┝sagl Ci: i ┝ocap Cs: y y┝ocap Ci: i the “link” rule ┝ocap Ci Cs : i y

More Applications of OCAP TAL [Morrisett'98] [TLDI'07] malloc lib. [Lin et al. TASE'07] GCs

Conclusion • Goal: modular verification of system software – modules use different computation features – modules are at different abstraction levels • Solution: to certify different modules using different logics – – – SCAP: stack-based control abstractions SAGL: modular concurrency verification CMAP: assume-guarantee with dynamic threads … OCAP: interoperation between different verification systems

Conclusion • Applications – malloc/free [Feng et al. PLDI'06, Xiang et al. QSIC'06] – garbage collectors [Mc. Creight&Shao PLDI'07] SCAP – thread scheduler [Feng et al. TLDI'07] – threads + scheduler [Feng et al. TLDI'07] – TAL + mem. alloc [Feng et al. TLDI'07] – TAL + GC [Lin et al. TASE'07] OCAP

Ongoing and Future Work • Certifying OS – Mini-OS: ongoing work – More realistic OS in the future, e. g. OS for embedded systems • Concurrency with relaxed memory models – relaxed memory models and STM • General Hoare-logic (next generation of OCAP) – based on a uniform semantic model of features – support concurrency, partial correctness, frame rules … • Push verification to high level code – C-like code with inlined assembly – Automated spec. inference and theorem proving

Thank you! Acknowledgments Zhong Shao, Hongxu Cai, Rodrigo Ferreira, Yu Guo, Andrew Mc. Creight, Zhaozhong Ni, Gang Tan, Alex Vaynberg, Sen Xiang

Backup Slides

Certifying the Mini-OS • Modeling of x 86 machine – Real mode – PIC, keyboard, hard drive – 8 - and 16 -bit integers • Verifying the code – Multi-threaded code • SAGL with extension of interrupts – Scheduler, thread lib. , interrupt handler • SCAP with extension of interrupts – Interactions with devices (PIC, PIT, keyboard, HDR) • Finite state machine in the specifications

Statistics • FIFO scheduler/context switching code – 30 line of MIPS code – 1400 line of proof scripts • malloc/free: – 42/50 line of MIPS code – 1400/1560 line of proof scripts

Statistics [Mc. Creight et al. PLDI’ 07]

Statistics – TAL & GC [Lin et al. TASE'07]

SCAP: tail call p S WFST(n, g S, ) p S p 0 S 0 jf jr $ra … p 0 g 0 g n p 0 S 0 WFST(n, g 0 S 0, ) S 1 p S p 0 S 0 jr $ra n … p S g 0 S 1 g S S 1

CMAP • A-G reasoning – properly nested structures: P 1 || P 2 • low-level code – fork/join based structures – dynamic thread environment • CMAP – unbounded dynamic creation/termination – similar to the support of dynamic mem. alloc. – change A and G to approximate the dynamic thread env. …

Scheduler in SCAP r 0 r 31 ct H 1 jal yield pc ct: … pcn … pc 1 Thread code: TQ … r 0 yield: H 1 … ct jr r 31 pc 1 swap pci and r 31 TQ pcn r 31 pick one word (pci) from TQ

r 31 pick one word (pci) from TQ swap pci and r 31 ct pc 1 yield: (ps, gs) H 1 ps Q. WFTQ(Q) True r 0 gs ( r {r 1, …, r 30}. [r]=[r]’) Q, Q’. r 31 WFTQ(Q’) p’ Q {[r 31]} = Q’ {[r 31]’} H 1 … TQ pcn WFTQ(Q) p’ ct p’. … TQ jr r 31 pc 1 gs r 0 pcn Scheduler in SCAP

Example: A-G reasoning 100 101 … … [100] : = m; [101] : = n; … … G 1: [101] = [101]' G 2: [100] = [100]' A 1: [100] = [100]' A 2: [101] = [101]'

Example: SAGL reasoning 100 -{(emp , 100 _) } 101 -{(emp , 101 _)} … … [100] : = m; [101] : = n; … … G 1: emp G 2: emp A 1: emp A 2: emp

OCAP: Code pointers Support of first-class code pointers: codeptr(f, a) (f) = a Not well-founded! (Spec) : : = {f a}* codeptr a

OCAP: Code Pointers A generic specification: (Cd. Spec) : : = … codeptr a (Spec) : : = {f }* (Assert) a Spec State Prop ( ) , S. … codeptr No interoperation between multiple systems… a ( )

OCAP: Foreign Languages (Lang. Ty) L : : = Ci. C Terms Type (Code. Spec) : : = Ci. C Terms L Inductive Tal. Type : = Inductive Tal 2 Type : = T_int : Tal. Type T 2_int : Tal. Type T_pair: Tal. Type -> Tal. Type T 2_pair: Tal. Type -> Tal. Type … … L : : = Tal. Type | Tal 2 Type | … 1 : : = T_int | T_pair 1 1 | … Tal. Type 2 : : = T 2_int | T 2_pair 2 2 | … Tal 2 Type

OCAP: Specifications (Lang. Ty) L : : = Ci. C Terms Type (Code. Spec) : : = Ci. C Terms L (Interp) ( )L L Assert (OCd. Spec) : : = <L, ( )L, > L. (L Assert)*L (Spec) : : = {(f 1, 1), … (fn, n)} (Assert) a Spec State Prop Not well-founded: a ( )L

OCAP: Specifications (Lang. Ty) L : : = Ci. C Terms Type (Code. Spec) : : = Ci. C Terms L a (Interp) ( )L L Assert ( )L (OCd. Spec) : : = < , L, ( )L, > (Spec) : : = {(f 1, 1), … (fn, n)} (Assert) a Spec State Prop (Lang. ID) : : = n nat (Lang. Dict) D : : = { 1 <L 1, ( )L 1>, …, n <Ln, ( )Ln>} Lang. ID ( L. L Assert)