Open Framework for Certified System Software

1. An Open Framework for Certified System Software Xinyu Feng Yale University

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

3. 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) Something More Relevant …

4. 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…

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

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

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

8. 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

9. My Contributions • Specialized program logics • SCAP: stack-based control abstractions • SAGL: modular concurrency verification • CMAP: dynamic thread creation • 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] [PLDI’06] [ESOP’07] [ICFP’05]

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

11. Modules at Different Levels • Example: how to certify multi-threaded 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!

12. L2 L1 L4 L3 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

13. OS Cn C1 C1 Cn … … C1 C1 Cn Cn L1 … Ln TCB Our Solution … OCAP Modeling of the machine Mechanized Meta-Logic (CiC)

14. The 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)

15. 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)

16. c1 c2 c3 cn … P0 P1 P2 Pn Invariant-Based Verification Initial condition:Inv(P0) Progress: if Inv(P), then P’. P c P’. Preservation: if Inv(P) and P cP’, then Inv(P’).

17. may use different  … C1 Cn “Domain specific” logics How to link modules? L1 … Ln OCAP Rules Modeling of the machine Mechanized Meta-Logic (CiC)

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

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

20. 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&McAllester'01] [Amed'04] [Appel et al.'07] 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, …

21. TAL XCAP SCAP SAGL … … C1 Cn L1 Ln … Sound ( )L1 ( )Ln The OCAP Framework [TLDI'07] Sound OCAP Rules OCAP Soundness Modeling of the machine Mechanized Meta-Logic (CiC)

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

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

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

25. 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

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

27. a1a2 a1a2 a1a2 A-G Reasoning Requires global invariants! G1 G2 a1 a2 A1 A2 a2 a1

28. p2 p1 a1a2 SAGL: Overview Partition of resources: shared & private Threads specs: (a1, p1), (a2, p2), … Partition is conceptual: (p1 p2)  (a1  a2)

29. p2 p1 a1a2 SAGL: Memory Access Threads have exclusive access to their private resources. All threads can access shared part. Needs to guarantee non-interference. Follows assume/guarantee reasoning. Partitions can be dynamically adjusted.

30. p2 p2 p1 p1 a1a2 a1a2' SAGL – Access Shared Resource G2 a1 A1 a1 A-G reasoning: a special case wherep1andp2areemp.

31. p2 p2' p1 p1 a1a2 a1a2 SAGL – Access Private Resource

32. p2 p2 p1 p1 p1 p2 a1a2 a1a2' a1a2 SAGL - Redistribution a1 a1 G2 A1 G2 A1 a1 a1 lock unlock

33. x … y x … Example: List getNode(): l.acq(); … l.rel(); -{(ainv , emp)} -{(emp,emp List(x))}; -{(emp,Node(y) List(x))} ainv=free(l)  List(x) free(l)  emp ainv -{(List(x),Node(y))}

34. p2 p1 All threads can access shared part. a1a2 Needs to guarantee non-interference. Follows assume/guarantee reasoning. SAGL [ESOP’07] A-G reasoning Threads have exclusive access to their private resources. Partitions can be dynamically adjusted. CSL

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

36. 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?

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

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

39. env cannot outlive the stack frame of rev ! f0 f0 … … Problems – setjmp/longjmp jmp_buf env = …; void cmp0(int x,jmp_buf env){ cmp1(x, env); } int rev(int x){ if (setjmp(env) == 0){ cmp0(x, env); return 0; }else{ return 1; } } pc pc void cmp1(int x,jmp_buf env){ if (x == 0) longjmp(env, 1); else return; } pc env sp …

40. Stack-Based Control Abstractions A simple system (SCAP) for modular verification of (1) compiled C code & (2) manually-written assembly code Function call/return PLDI'06 Tail calls 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

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

42. Program Spec. and Code Pointers • Program Specification ::= {f1(p1,g1), …,fn(pn,gn)} • “safe” to return (jr $ra): • $radom()  ($ra)=(p,g) • pholds at the time of return p0 p1 jal f p2 jal h g2 g0 g1 p3 jr$ra g3 p4 jr $ra … g4 jr $ra

43. SCAP : Stack Invariant Always safe to return? p0 S0 g0 p1 jr $ra g0 S0S1  S1.$ra   (S1.$ra))=(p1, g1) p1S1 S1 g1 p2 S2 g0 S0S1  g1 S1S2  S2.$ra   (S2.$ra)=(p2, g2) p2S2 g2 p3 S3 g0 S0S1  g1 S1S2  g2 S2S3  S3.$ra    (S3.$ra)=(p3, g3) p3 S3 g3 … Logical control stack

44. SCAP : Stack Invariant WFST(n, g0, S0, )  S1. g0 S0 S1   p1,g1. (S1.$ra)=(p1, g1)  p1 S1  WFST(n-1, g1, S1, ) WFST(0, g0, S0, )   S1. g0 S0 S1 Invariant: p S  n.WFST(n, g, S, ) p0 S0 g0 p1 jr $ra S1 g1 p2 S2 g2 p3 S3 g3 Logical control stack

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

46. n+1 jal f SCAP: call p S  WFST(n, g, S, ) p0 S0 WFST(n+1, g0, S0, ) p p0 p0 S S0 g0 g0 p1 p1 g jr $ra jr $ra g1 g1 S1 S1 n n S2 S2 … … p S  p0 S0 g0 S0 S1 S0.$ra = S1.$ra p S  g0 S0 S1 p1 S1 p S  g0 S0 S1  g1 S1 S2  g S S2

47. SCAP: ret p S  WFST(n, g S, ) p1 S1 WFST(n-1, g1 S1, ) p n p1 p1 S g S1 g1 g1 jr $ra n-1 n-1 … … p S  g S S1

48. Multi-ret p1 p1 p p g1 g1 jr ra jr ra g g + Tail-call p1 p g1 g jr ra Generalization: Stack Unwinding/Cutting

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