1. All-Path Reachability Logic Andrei Stefanescu 1, Stefan Ciobaca 2, Radu Mereuta 1,2, Brandon Moore 1, Traian Serbanuta 3, Grigore Rosu 1 1 University of Illinois, USA 2 University of Iasi, Romania 3 University of Bucharest, Romania

2. Main Goal Language-independent program verification framework Prove program properties from operational semantics Proof system Operational semantics ⊢ program properties 1

3. Overview State-of-the-art in Certifiable Verification All-Path Reachability Specifying State Properties Specifying Reachability Properties Reasoning about Reachability

4. Operational Semantics Easy to define and understand Can be regarded as formal “implementations” Require little mathematical knowledge Great introductory topics in PL courses Executable, so testable Can be tested against real benchmarks 3

5. Operational Semantics Frameworks PLT-Redex/Racket (Findler et al.) Raskal (Klint et al.) RLS-Maude (Meseguer et al.) PLanComps (Mosses et al.) K (Rosu et al.) OTT (Sewell et al.) 4

6. Operational Semantics Scale C (Ellison and Rosu, POPL’12) GCC torture test suite JavaScript (Bodin et al., POPL’14) ECMA test262 suite Python (Politz et al., OOPSLA’13) CPython test suite PHP (Filaretti and Maffeis, ECOOP’14) Zend test suite 5

7. Operational Semantics Sample rule (may require a configuration context) Define languages only with rules of the form l, r are configuration terms b is a Boolean side condition 6

8. Unfortunately … Operational semantics considered inappropriate for program verification; proofs are low-level and tedious: Formalization of and working with transition system Typically by induction on the structure of the program on the number of execution steps etc. Done in ACL2 before 7

9. Axiomatic Semantics (Hoare Logic) Emphasis on program verification Programming language captured as a formal proof system deriving Hoare triples 8

10. Axiomatic Semantics Not easy to define and understand, error-prone Not executable, hard to test Require program transformations, behavior loss 9 Write e = 1 and you’ve got a wrong semantics!

11. State-of-the-art in Certifiable Verification Languages C (Appel et al.) – CompCert operational semantics Java (Jacobs et al.) Approach Define an operational semantics: trusted language model Define an axiomatic semantics: for verification purposes Prove axiomatic semantics sound for operational semantics Now we have trusted verification … BUT Requires two semantics of the same language C operational semantics took more than 2 years! Must be done individually for each language 10

12. Overview State-of-the-art in Certifiable Verification All-Path Reachability Specifying State Properties Specifying Reachability Properties Reasoning about Reachability

13. Our Approach Underlying belief: one semantics for each language! Executable (testable), easy to define and understand Suitable for program verification, “as is” Approach: language-independent proof system Takes operational semantics unchanged Derives program properties Both operational semantics rules and program specifications stated as reachability rules Sound and relatively complete 12

14. Overview State-of-the-art in Certifiable Verification All-Path Reachability Specifying State Properties Specifying Reachability Properties Reasoning about Reachability

15. Matching Logic Logic for specifying static properties about program configurations and reasoning about them Key insight: Configuration terms with variables are allowed to be used as predicates, called patterns Semantically, their satisfaction means matching Matching logic is parametric in a (first-order) configuration model: typically the underlying model of the operational semantics 14 [Rosu, Ellison, Schulte 2010]

16. Patterns C configurations Example of a pattern 15 Extra 70 cells

17. Model of Configurations - Properties - Configuration abstraction (list) “Separation” achieved at term level Operations (reverse) 16

18. Separation Logic = Matching Logic Instance Separation logic: popular logic for heap properties Mechanical translation to matching logic Configuration: Separation encoded using different sub-terms Example SL ML No expressiveness loss from using matching logic Matching logic gives “structural separation” anywhere in the configuration, not only in the heap 17 [OOPSLA’12]

19. Overview State-of-the-art in Certifiable Verification All-Path Reachability Specifying State Properties Specifying Reachability Properties Reasoning about Reachability

20. One-Path Reachability Rules Pairs of matching logic patterns 19 One-Path Reachability: Any terminating concrete configuration satisfying reaches, on some execution path, some configuration satisfying, in the transition system induced by the operational semantics.

21. All -Path Reachability Rules Pairs of matching logic patterns 20 All-Path Reachability: Any concrete configuration satisfying reaches, on any terminating execution path, some configuration satisfying, in the transition system induced by the operational semantics. …

22. Reachability Rules - Operational + Axiomatic - Operational flavor Axiomatic flavor 21

23. Hoare Triple = Syntactic Sugar 22

24. Operational and Axiomatic Semantics Rules as Reachability Rules Reachability rules generalize Operational semantics rules Hoare triples Operational semantics rule is syntactic sugar for reachability rule Hoare triple encoded in a reachability rule with the empty code in the right-hand-side 23

25. Overview State-of-the-art in Certifiable Verification All-Path Reachability Specifying State Properties Specifying Reachability Properties Reasoning about Reachability

26. Reasoning about All-Path Reachability The main result of this section is a proof system deriving reachability rules from reachability rules: 25 Operational semanticsTarget reachability rule Claimed reachability rules (Coinductively) trusted reachability rules

27. Reachability Proof System - In Two Sentences - Symbolic execution based on operational semantics Coinductive proof rule for repetitive behavior Generalizes invariant rules from Hoare logic Sound and (relatively) complete 26

28. Reachability Proof System - 8 Rules - 27 Code with circular behavior

29. Reachability Proof System 28 Each configuration has some successor Each successor of a configuration satisfies

30. Circular behaviors Circularity, Transitivity and Axiom proof rules Hoare logic rule for while loops Language-independent Language-specific Claim (cannot use yet)! Enable! Use! 29

31. Reachability Proof System 30

32. Soundness 31 Theorem: If is derivable by the proof system, then is semantically valid.

33. Relative Completeness Relativity Validity oracle for static configuration properties Language-independent result, unlike Hoare logics 32 Theorem: If is semantically valid, then is derivable by the proof system, with the operational semantics of a language.

34. Implementation Part of the K framework (k-framework.org)k-framework.org Operational semantics and program properties represented as K rules Automatic prover (user specified properties) symbolic execution based on the K semantics Circularity for repetitive behaviors custom prover for matching logic implications Java (mostly) and Z3 (for theory reasoning) 33

35. Narrowing Concrete execution ground configuration rewriting Symbolic execution symbolic configuration narrowing unification modulo theories Narrowing generalizes control flow proof rules code sample construct operational semantics 34

36. Conclusion Sound and relatively complete proof system Circularity generalizes language specific proof rules for repetitive behaviors (loops, recursive functions, …) Implemented as part of the K framework Language independent program verification based solely on operational semantics is possible 35