1 / 29

An Open Framework for Foundational Proof-Carrying Code

An Open Framework for Foundational Proof-Carrying Code. Xinyu Feng Yale University Joint work with Zhaozhong Ni (Yale, now at MSR), Zhong Shao (Yale) and Yu Guo (USTC). Libraries and runtime. +. Motivation. How to build fully certified software systems?. Source-level code.

callum
Download Presentation

An Open Framework for Foundational Proof-Carrying Code

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 Foundational Proof-Carrying Code Xinyu Feng Yale University Joint work with Zhaozhong Ni (Yale, now at MSR), Zhong Shao (Yale) and Yu Guo (USTC)

  2. Libraries and runtime + Motivation How to build fully certified software systems? Source-level code References with weak upd. Garbage collectors Dynamic mem. alloc. malloc() (strong update) Functions, exceptions, … Stacks, code pointers Concurrency Context switching & Scheduler Device drivers I/O

  3. [Yu&Shao, ICFP’04] Motivation • All concurrency verification assumes built-in concurrency • Assume-Guarantee (A-G) reasoning • Concurrent Separation logic (CSL) • … • Context switching, scheduler • Too low-level to be certified in these logics • Threads & schedulers have never been modularly certified!

  4. Motivation • Certify all code in a single type system/program logic? • Hard to combine all features • weak vs. strong update, functions/exceptions vs. goto’s, threads vs. thread contexts • May not be modular • Very complex, hard to use • Don’t know how to design such a logic • Certify modules using the most appropriate logic! • Modules do not use all the features at the same time • It is simpler to use specialized logic for each module

  5. An Open Framework Certify different modules using different verification systems!

  6. Not readily supported in Coq! Challenges • Extensibility and openness • not designed for certain specific interoperations But can we just use MLFs, e.g. Coq? • Expressiveness • type safety, concurrency properties, partial correctness, … • A general and uniform model of control flow • Allow functions certified in different systems to call each other • the key for modularity: separate verification & proof reuse • Principled interoperation with clear meta-property • properties of the whole system composed of modules

  7. Our contributions • OCAP: an open framework • Embedding of different systems • TAL, non-CPS Hoare-logic, A-G reasoning, … • Open & Extensible • Modularity with first-class code pointers [Ni&Shao POPL’06] • Soundness • Type safety, & preservation of invariants in foreign systems • Applications • TAL + memory allocation libs. • Threads + Scheduler • The first time to modularly certify both sides • …

  8. Outline • OCAP Framework • Certifying Threads & Schedulers

  9. … C1 Cn L1 Ln … Sound ( )L1 ( )Ln Modeling of the machine TCB Mechanized Meta-Logic (CiC) OCAP : Overview Sound OCAP Rules OCAP Soundness Modeling of the machine Mechanized Meta-Logic (CiC)

  10. 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)

  11. The OCAP Logic : Overview • Hoare-style program logic for assembly • CPS-style reasoning • Assign a precondition to each basic block • Similar to TAL [Morrisett et al. POPL’98]

  12. a1 a2 a3 The OCAP Logic : Overview (spec) ::={fa}* (data heap) H f1: I1 a 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)

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

  14. A generic specification:  (CdSpec) ::=… codeptr (Spec) ::= {f  }* a (Assert)a Spec  State  Prop ()  ,S. …  codeptr  () a  OCAP: Code Pointers No interoperation between multiple systems…

  15. OCAP: Foreign Languages (LangTy) L::= CiC Terms  Type (CodeSpec) ::= CiC Terms L Inductive TalType : Type := T_int : TalType T_pair: TalType -> TalType-> TalType … Inductive Tal2Type : Type := T2_int : TalType T2_pair: TalType -> TalType-> TalType … L::= TalType | Tal2Type | … 1 ::= T_int | T_pair 11| …  TalType 2 ::= T2_int | T2_pair 22| …  Tal2Type

  16.  a ( )L OCAP: Specifications (LangTy)L::= CiC Terms  Type (CodeSpec) ::= CiC Terms L (Interp)( )LL Assert (OCdSpec) ::= <L,( )L,> L.(L Assert)*L (Spec)::={(f1,1), … (fn,n)} (Assert)a Spec  State Prop Not well-founded:

  17.   a ( )L  OCAP: Specifications (LangTy)L::= CiC Terms  Type (CodeSpec) ::= CiC Terms L (Interp)( )LL Assert (OCdSpec) ::= <,L,( )L,> (Spec)::={(f1,1), … (fn,n)} (Assert)a Spec  State Prop (LangID)::= n  nat (LangDict)D ::= {1<L1,( )L1>,…, n<Ln,( )Ln>} LangID  (L.L  Assert)

  18. Selected OCAP Rules D1;1┝ C1:1’ D2;2┝ C2:2’ … (link) D1D2; 12┝ C1C2 : 1’2’ ,S.a  S .(codeptr(S.R(r),)a’)  S a’ = [[[ ]]]D (jr) D┝ {a}jr r codeptr(f,)  ,S. (f)= [[[  ]]]D,S. ( )L.(D()=<L,( )L>)(()L  S)  = <,L,>

  19. Outline • OCAP Framework • Certifying Threads & Schedulers

  20. Threads and Scheduler • Thread code C1,…,Cn • Certified following CCAP [Yu&Shao, ICFP’04] • Assume-Guarantee reasoning • Thread modularity • Do not know about thread queue • Scheduler CS • Certified in SCAP [Feng et al. PLDI’06] • as sequential code • Manages thread queue TQ • Do not touch H SCAP CCAP +

  21. r0 r31 H1 … pc1 pcn TQ r0 r31 H1 … pc1 pcn TQ Scheduler in SCAP ct Thread code: … jal yield ct: … yield: pick one word (pci) from TQ swap pci and r31 jr r31 ct

  22. r0 r31 H1 … pc1 pcn TQ r0 gs  (r{r1,…,r30}.[r]=[r]’)  Q, Q’. p’.  Q{[r31]} = Q’{[r31]’} r31 WFTQ(Q)*p’ H1 … pc1 pcn WFTQ(Q’)*p’ TQ Scheduler in SCAP ct yield: (ps, gs) pick one word (pci) from TQ swap pci and r31 jr r31 gs ps  Q.WFTQ(Q) * True ct

  23. Embedding SCAP D p ((p,g))Dscap  … Soundness: … g scap┝scapC:’scap jr $ra  (scap)Dscap D Dscap,┝ C:’ ’ (’scap)Dscap Dscap  {scap <Lscap, (_)scap> }

  24. p1 p2 S S’ p’1 p2 ? Threads: Assume-Guarantee A1, G1 A2, G2 Spec. for threads: (p, A, G) p: State  Prop A, G: State  State  Prop  A2 G1 Stability of p: pi S  Ai S S’  pi S’

  25. CCAP embedding ((p,A,G))ccap  ,S. … Dall  {ccap <Lccap, (_)ccap>, scap <Lscap, (_)scap> } ccap┝ccapCi:’ccap Dall;cy┝ Ci: ’c c  (ccap) ccap ’c  (’ccap) ccap y  {yield  <scap ,Lscap,(ps, gs)>}

  26. the “link” rule Certify the code Dall  {ccap <Lccap, (_)ccap>, scap <Lscap, (_)scap> } SCAP CCAP scap┝scapCs:’scap ccap┝ccapCi:’ccap Dall;y┝ Cs: ’y Dall;cy┝ Ci: ’c Dall; cy┝ Ci Cs: ’c  ’y

  27. Summary • It is simpler and natural to certify different modules using different logics • OCAP: framework for interoperation • Embedding • TAL: type system • SCAP: non-cps logic for assembly • CCAP: Assume-guarantee reasoning • Interoperation • TAL + newpair • Threads + Scheduler • TAL + GC (ongoing work by Lin, McCreight, et al.)

  28. Future work • Explore the applicability of OCAP • Interoperation of different languages • Currently just for assembly language • But logics are at different levels (TAL, CCAP, …) • May support C + inlined assembly

  29. Thank you!

More Related