1 / 79

An Open Framework for Certified System Software

An Open Framework for Certified System Software. Xinyu Feng Yale University. Why Certified Software?. Mars Polar Lander. Mars climate orbiter. Ariane 5. Fig. from: www.howstuffworks.com.

vea
Télécharger la présentation

An Open Framework for Certified System Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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; }

More Related