Automating Relatively Complete Verification of Higher-Order Functional Programs

1. Automating Relatively Complete Verification of Higher-Order Functional Programs Hiroshi Unno (University of Tsukuba) Tachio Terauchi (Nagoya University) Naoki Kobayashi (University of Tokyo) POPL 2013

2. Path-Sensitive Verifier for Functional Programs(cf. SLAM, BLAST, … for Imperative Programs) • Refinement type inference by Horn clause solving [Unno and Kobayashi 2008, 2009] • Liquid Types [Rondon, Kawaguchi and Jhala 2008, …] • Depcegar [Terauchi 2010] • MoCHi [Sato, Unno and Kobayashi 2011, 2013] • HMC [Jhala, Majumdar and Rybalchenko 2011] Demo Program & Spec. All these verifiers are based on refinement type system(cf. Hoare logic for first-orderimperative programs) Result let rec mc x = if x > 100 then x – 10 else mc (mc (x + 11)) in let n = randi() in if n · 101 then assert (mc n = 91) Certificate or Counterexample Verifier POPL 2013

3. Refinement Types FOL formulas for refinement Non-negative integers Functions that take an integer andreturn an integer not less than • Soundness of refinement type system : • is safe (i.e., ) • if is well-typed (i.e., ) POPL 2013

4. Example: Typing Safe Program under Well-typed! POPL 2013

5. Automated Verification viaRefinement Type Inference • Input a program • Infer a type environment such that (cf. invariant inference for Hoare logic) POPL 2013

6. Limitation of Refinement Type System Incompleteness: There is a safe but untypable program whereas Hoare logic is relatively complete POPL 2013

7. Example: Safe but UntypableProgram Refinement predicate for the 1st arg. of Cannot depend on Refinement predicate for Untypable because: POPL 2013

8. Our Contributions • Relatively completeextension ofordinary refinement type system • Type inference method for POPL 2013

9. Our Contributions • Relativelycompleteextension ofordinary refinement type system • Type inference method for for any safe programgiven an oracle to decide the validity of formulas of Peanoarithmetic POPL 2013

10. Our Design Goal of • Easy to automate type checking & inference • By exploiting techniques from first-orderautomated theorem proving (e.g., interpolation, SMT) • Rejected alternative designs: • Refinement predicates on functions (cf. Coq) • Unrestricted use of quantification (cf. Dependent ML) POPL 2013

11. Our Approach: RestrictedUse of Quantification • Add oneuniversal quantifier over integerjust beforeeach function parameter[Goerdt 1985, German, Clarke, and Halpern 1983, 1989] A quantifier instantiation for POPL 2013

12. Example: Typing under Well-typed! POPL 2013

13. Theorem: Relative Completeness of • A program is safe • There exists a substitution for “?”s such that POPL 2013

14. Our Contributions • Relatively completeextension ofordinary refinement type system • Type inference method for POPL 2013

15. Type Inference for • Find a substitution as well asa type environment such that POPL 2013

16. Our Approach • Counterexample guided inference of and (cf. CEGAR in software model checking forimperative programs) • For inference of a type environment : • Use existing refinement type inference methods for [Terauchi 2010, Kobayashi, Sato, Unno 2011] • For inference of a substitution for “?”s: • Use a new method based on non-linear constraint solving POPL 2013

17. Our Approach • Counterexample guided inference of and (cf. CEGAR in software model checking forimperative programs) • For inference of a type environment : • Use existing refinement type inference methods for [Terauchi 2010, Kobayashi, Sato, Unno 2011] • For inference of a substitution for “?”s: • Use a new method based on non-linear constraint solving POPL 2013

18. Counterexample GuidedRefinement Type Inference safe Input Program Step 1: Fixed-PointType Inference [1,2] Candidate Type Envs. New Candidate Type Envs. s.t. Counter-example s.t. unknown Step 3: Refinement [1,2] Step 2: SafetyCheck of [2] yes no [1] Terauchi POPL 2010 [2] Kobayashi, Sato, Unno PLDI 2011 unsafe POPL 2013

19. Our Approach • Counterexample guided inference of and (cf. CEGAR in software model checking forimperative programs) • For inference of a type environment : • Use existing refinement type inference methods for [Terauchi 2010, Kobayashi, Sato, Unno 2011] • For inference of a substitution for “?”s: • Use a new method based on non-linear constraint solving POPL 2013

20. Counterexample GuidedSubstitution Inference safe Instantiated Program Input Program Step 1: Fixed-PointType Inference [1,2] New Candidate Substitution s.t. Candidate Substitution New Candidate Type Envs. s.t. Candidate Type Envs. Counter-example s.t. Step 3: Refinement [1,2] Step 2: SafetyCheck of [2] yes no [1] Terauchi POPL 2010 [2] Kobayashi, Sato, Unno PLDI 2011 unsafe POPL 2013

21. Finding New Candidate Substitution • Input: a safe non-recursive fragment such that • Output: such that By reduction to non-linear constraint solving using linear expression templates for POPL 2013

22. Example:Reduction to Non-Linear Constraint Solving POPL 2013

23. Example: Non-linearConstraint Solving(1/2) Elim. Elim. iff POPL 2013

24. Example: Non-linearConstraint Solving(2/2) Farkas’ lemma: iff to • Bit-vector modeling & SMT [Gulwani, Srivastava, Venkatesan 2008] POPL 2013

25. Implementation • Extended MoCHi[Sato, Unno and Kobayashi 2011, 2013]with the type inference method for Program & Spec. Result let rec mc x = if x > 100 then x – 10 else mc (mc (x + 11)) in let n = randi() in if n · 101 then assert (mc n = 91) Certificate or Counterexample MoCHi POPL 2013

26. Conclusion • Relatively complete refinement type system • Restricted use of quantification • Add one universal quantifier over integerjust before each function parameter • Type inference method for • Counterexample guided inference of and • inference byapplication of existing refinement type inference methods [Terauchi 2010, Kobayashi, Sato, Unno 2011] • Inference by reduction to non-linear constraint solving POPL 2013