1. Secure Compiler Seminar 11/7 Survey: Modular Development of Certified Program Verifiers with a Proof Assistant Toshihiro YOSHINO (D1, Yonezawa Lab.) tossy-2@yl.is.s.u-tokyo.ac.jp

2. Today’s Paper A. Chlipala (UC Berkeley). Modular Development of Certified Program Verifiers with a Proof Assistant. ICFP ’06.  Implementation can be downloaded from web site below: ⇒ http://proofos.sourceforge.net/http://proofos.sourceforge.net/

3. Overview of the Paper Case study to develop a certified program verifier with Coq  Verifies memory safety of x86 machine code  Its soundness is machine-checked  Modular development by reusable functors Possible to create a new verifier based on another type system with low cost

4. Constructing Certified Verifiers Design and implement with Coq  Use “extraction” feature of Coq to obtain a working verifier A verifier can be formalized as:  load: program -> state loads a program The type program represents binary file format  safe: state -> Prop is the safety property we wish to verify for programs  [[P]] is notation for poption P option(O’Caml) or Maybe(Haskell) for domain Prop

5. Constructing Certified Verifiers Abstraction refinement by multiple stages  Each stage (component) is a functor which transforms target states into source states Later components reason at higher levels of abstraction  Use Coq’s module system to implement this modular design

6. Formalization of x86 Instruction Set PCC-style formalization  Subset of x86 instruction set + ERROR instruction mov, jcc, … Safety ≡ ERROR is unreachable  In combination with assertion, many properties can be proven  Can be formalized coinductively Cope with infinite derivation

7. Types and Extraction in Coq Basically Coq manipulates on terms of dependently-typed lambda calculus  A proposition is represented as a type, its proof as a term of that type Well known as Curry-Howard isomorphism  Proving step corresponds to type inference Given a goal, refine it interactively into subgoals, and eliminate holes Rules used for these steps are called tactics

8. Types and Extraction in Coq Program extraction from Coq code  In short, extraction is to erase terms of sorts other than Set  Brief example: isEven Definition isEven : forall (n:nat), poption (even n). refine (fix isEven (n:nat) : poption (even n) := match n return … with | O => PSome _ _ | S (S n) => … | _ => PNone _ end); auto. Qed. let rec isEven (n:nat) = match n with | O -> true | S (S n) -> isEven n | _ -> false Definition isEven : forall (n:nat), poption (even n). refine (fix isEven (n:nat) : poption (even n) := match n return … with | O => PSome _ _ | S (S n) => … | _ => PNone _ end); auto. Qed.

9. poption: “option” for Domain “Prop” Two constructors: PNone and PSome  PSome is given a proof of P Literately, PSome means “P holds and I have a proof for that” and PNone “I am not sure”  Can be used as failure-monad PNone >>= _= PNone PSome p >>= f= f p  In extraction, PSome corresponds to true, and PNone to false

10. soption soption extends poption with a parameter  Proposition about a term of domain T (of sort Set)  soption, too, can be used as failure monad In the paper’s theoretical part, written as {{ x : T | P }}

11. Coq’s Module System Used to build re-usable verification components  Frequent pattern: Module Type MACHINE. Parameter mstate : Set. Parameter minitState : mstate -> Prop. … End MACHINE. Record state : Set := { stRegs32 : regs32; … }. Inductive instr : Set := Arith : … | …. Inductive exec : … := …. Module M86 <: MACHINE. Definition mstate := state. Definition minstr := instr. … End M86.

12. Module ModelCheck Provides fundamental methods of model checking  Methods to prove theorems about infinite state systems through exhaustive exploration Refine the model in each of the following stages AbstractConcrete

13. Module ModelCheck Introduced Elements absState: a set of abstract states  An abstract state is managed with “hypotheses”, states that are known to be safe Hypothesis is used, for example, to formalize return pointer from a function describes correspondence between machine states and abstract states  Context(Γ) is deleted in extracting a verifier init is a set (actually a list) of initial states  It must be a set because one real machine state may correspond to multiple abstract states  There must be some elements in init that has no hypothesis

14. Module ModelCheck Introduced Elements step describes execution step  Execute an instruction from the specified state soption is used because the execution may get stuck  Progress and Preservation must hold Progress Preservation

15. MACHINE: Input to the module Module ModelCheck The Concept Illustrated State space of a real machine absState step Initial states

16. Module Reduction Translates x86 machine language into simpler RISC-style instruction set (SAL)  x86 machine language is too complex and not suitable for verification purposes One instruction may perform several basic operations The same basic operations show up in the working of many instructions Reduction module also provides model checking layer for SAL programs

17. Module Reduction SAL: Simplified Assembly Language Named after the language used in Proof- Carrying Code [Necula 1997] RISC-style instruction set  Arithmetics are extended to allow expressions with parentheses and infix operators Additional temporary registers TMP i

18. Module FixedCode Ensures that code region is not overwritten by the code itself  To simplify the verification framework Definition is in the form of ModelCheck  Additional check is performed only on storing to the memory

19. Module TypeSystem Support for a standard approach for type systems  A set of types is introduced and typing rules for values are described  Subtype relation is also introduced The definition in the figure suffices because Coq takes care of that part  And each register is associated with a type

20. Module TypeSystem viewShift represents shift of types’ view  Occurs at places a program crosses an abstraction boundary For example, in function calls when the stack frame changes Introducing existential is also a kind of view shift

21. Module WeakUpdate Introduces a type system of weak update  Each memory cell has a type associated and this type does not change during a run A cell can be overwritten only with a value of its type Dynamic memory management is out of the scope  In real setting, memory is frequently reclaimed and reused Garbage collector or malloc/free

22. The Rest of Modules Module StackTypes  Keeps track of types of stack slots Module SimpleFlags  Keeps track of flag values In x86 (too), no atomic instruction for conditional test and jump at one time  Crucial for assuring pointer is valid (not null) or checking array boundary

23. Case Study: A Verifier for Algebraic Datatypes Implemented the library and a sample verifier with Coq  http://proofos.sourceforge.net/ http://proofos.sourceforge.net/  Approx. 20K(+α) LoC Main implementation consists of only 600 LoC 7,000 LoC for implementing library components 10,000 for generic utility 1,000 for bitvectors and fixed-precision arithmetics 1,000 for a subset of x86 machine code  Auxiliary library from O’Caml implementation (not counted here) x86 binary parsing, etc.

24. Related Work Foundational PCC [Appel 2001]  Reduce TCB and also improve flexibility of PCC by constructing a system on some logical framework  However, efficiency is sacrificed by generality Theoretical issues seem to have priority to pragmatics Epigram [McBride, McKinna 2004], ATS [Chen, Xi 2005], RSP [Westbrook et al. 2005] and GADTs [Sheard 2004]  Incorporate dependent types into program languages  But the foundations of Coq’s implementation and metatheories are simpler than them

25. Summary (of the Paper) Designed a structure for modular certified verifiers  Components are reusable functors  Pipeline-style design Implemented library components with Coq  As a case study, memory safety verifier for x86 machine code is constructed

26. Relevance to My Research I have been studying a framework to build verifiers for low-level languages  First formalize the common language ADL  Verification is done on the translated program (in ADL) Trying to prove correctness of translation  Currently ongoing with Coq

27. Relevance to My Research Both very similar approach  ADL and SAL are both designed in a minimalist criteria  Verification logic is built on top of the common language’s semantics To achieve high portability and flexibility  From this viewpoint, my project is covered by his… (x_x) Correctness of translation is also proven by Coq in proofos Positively thinking, my direction was not so wrong

28. Relevance to My Research Comparison of two projects… proofos [Chlipala 06] L 3 Cover [Yoshino 06] Common Language SALADL Implementation CoqJava Parametrization ML-style module OO-style (inheritance)