1. Matching Logic Grigore Rosu University of Illinois at Urbana-Champaign, USA http://matching-logic.org 1

2. Motivation Goal: verify programs using directly the trusted executable semantics of the language – Avoid defining Hoare logic or axiomatic semantics Many existing executable semantics frameworks – PLT-REDEX (Findler etal), MSOS tool (Mosses etal), OTT (Sewell etal), Spoofax (Visser etal), K (Rosu etal) – Semantics = rewrite rules over configuration patterns Need: specify properties/patterns/structure of interest over program configurations 2

3. Matching Logic - Overview Logic for reasoning about structure – Structure defined as algebraic data-types – Formulae specify desired structure templates or patterns – Formula satisfaction is pattern matching Historical remarks – First variant proposed in 2010 (Rosu, Ellison, Schulte) – Continuously improved, implemented and applied since then, as part of larger projects on program reasoning – Latest and most comprehensive reference: RTA’15 Most general variant; soundness and completeness 3

4. Talk Overview Context: Executable language semantics – The K framework Matching logic Application: Program specification and verification using matching logic 4

5. Runtime Verification, Inc., USA – Dwight Guth – Manasvi Saxena K Team UIUC, USA – Grigore Rosu (started K in 2003) – Thomas Bogue – Brandon Moore – Daejun Park – Cosmin Radoi – Yuwen Shijiao – Andrei Stefanescu Former members – Kyle Blocher, Peter Dinges, Chucky Ellison, Cansu Erdogan, Dwight Guth, Mike Ilseman, David Lazar, Patrick Meredith, Erick Mikida, Traian Serbanuta Romania – Dorel Lucanu – Traian Florin Serbanuta – Andrei Arusoae – Stefan Ciobaca – Radu Mereuta Former Members – Irina Asavoae, Mihai Asavoae, Denis Bogdanas, Gheorghe Grigoras, Emilian Necula, Raluca Necula http://kframework.org 5

6. Vision and Objective Deductive program verifier Parser Interpreter Compiler (semantic) Debugger Symbolic execution Model checker Formal Language Definition (Syntax and Semantics) Test-case generation 6

7. Current State-of-the-Art in PL Design, Implementation and Analysis Consider some programming language, L Formal semantics of L? – Typically skipped: considered expensive and useless Implementations for L – Based on some adhoc understanding of what L is Model checkers for L – Based on some adhoc encodings/models of L Program verifiers for L – Based on some other adhoc encodings/models of L … 7

8. Example of C Program What should the following program evaluate to? According to the C “standard”, it is undefined GCC4, MSVC: it returns 4 GCC3, ICC, Clang: it returns 3 State-of-the-art formal program verifiers "prove" that this program returns 4 int main(void) { int x = 0; return (x = 1) + (x = 2); } 8

9. A Formal Semantics Manifesto Languages must have formal semantics ! – And analysis/verification tools should build on them Otherwise they are adhoc and likely wrong Informal manuals are not sufficient – Manuals typically have a formal syntax of the language (in an appendix) – Why not a formal semantics appendix as well? 9

10. K Approach Deductive program verifier Parser Interpreter Compiler (semantic) Debugger Symbolic execution Model checker Formal Language Definition (Syntax and Semantics) Test-case generation 10

11. Formal Language Definition (Syntax and Semantics) If one needs a PhD to define a language, then we have already failed. 11

12. Complete K Definition of KernelC 12

13. Complete K Definition of KernelC Syntax declared using annotated BNF … 13

14. Complete K Definition of KernelC Configuration given as a nested cell structure. Leaves can be sets, multisets, lists, maps, or syntax 14

15. Complete K Definition of KernelC Semantic rules given contextually X = V => V … … X |-> (_ => V) … 15

16. K Scales Several large languages were recently defined in K: Java 1.4: by Bogdanas etal [POPL’15] – 800+ program test suite that covers the semantics JavaScript ES5: by Park etal [PLDI’15] – Passes existing conformance test suite (2872 pgms) – Found (confirmed) bugs in Chrome, IE, Firefox, Safari C11: Ellison etal [POPL’12, PLDI’15] – All 77 different types of undefined behavior – Commercialized by startup (Runtime Verification, Inc.) … 16

17. K Configuration and Definition of C 120 Cells! Heap … plus ~2000 rules … 17

18. K Semantics are testable! Parser Interpreter (semantic) Debugger Formal Language Definition (Syntax and Semantics) 18

19. Testing the K definition of C Tested on thousands of C programs (several benchmarks, including the gcc torture test, code from the obfuscated C competition, etc.) – Passed 99.2% so far! – GCC 4.1.2 passes 99%, ICC 99.4%, Clang 98.3% (no opt.) The most complete formal C semantics [POPL’12, PLDI’15] 19

20. K Demo Using Kweb, an online interface to K – http://kframework.org http://kframework.org – Show KOOLKOOL – Show Damas-Milner type inferencer 20

21. Formal Language Definition (Syntax and Semantics) Deductive program verifier Symbolic execution 21

22. State-of-the-Art Redefine the language using a different semantic approach (Hoare/separation/dynamic logic) Language specific, non-executable, error-prone Many different program logics for “state” properties: FOL, HOL, Separation logic… 22

23. State-of-the-Art Thus, these semantics need to be proved sound (and relatively complete) wrt trusted, operational semantics (reference model) – Huge effort, few dare to do it; so typically not done But verification tools are developed using them So we have an inherent gap between trusted, operational semantics, and the semantics currently used for program verification 23

24. Our Approach Use directly the trusted operational semantics! – Has been done before (e.g, ACL2), but proofs are low-level (induction on the transition system) and language-specific Language-independent proof system – Takes operational semantics as axioms – Derives reachability properties – Sound and relatively complete for all languages! Formal Language Definition (Syntax and Semantics) Deductive program verifier Symbolic execution 24

25. Formal Language Definition (Syntax and Semantics) Deductive program verifier Symbolic execution Need a means to specify static and dynamic program properties 25

26. Matching Logic for Static Properties Specify properties over program configurations and reason about them using matching logic Ultimate “program logic” for the language in question, specifically crafted for it We only discuss first-order variant here Can be obtained from FOL by collapsing its operation and predicate symbols – Collapsing its terms and predicates, into patterns – Interpreting symbols in powerset domains 26

27. Recall - First Order Logic 27

28. From FOL to Matching Logic 28

29. From FOL to Matching Logic Collapse symbols 29

30. From FOL to Matching Logic Collapse symbols 30

31. From FOL to Matching Logic Collapse terms and predicates 31

32. From FOL to Matching Logic Collapse terms and predicates 32

33. From FOL to Matching Logic Interpret symbols into powerdomains 33

34. From FOL to Matching Logic Interpret symbols into powerdomains 34

35. Matching Logic vs. FOL Simpler (no need to distinguish operations from predicates) Same expressiveness, but patterns more succinct than FOL formulae When fixing model(s), quite a convenient notation (captures separation logic) 35

36. Bottom Line No distinction between function and predicate symbols; they build patterns In models, patterns evaluate to sets of elements, namely those that match them Examples –, written, matched by singletons of sort s – matched by successor of x – elements are either zero or successors – matched by all linked lists in the heap starting with pointer x and holding mathematical sequence S 36

37. Useful Sugar Derived constructs Definedness, equality, membership Either the empty set (when  empty) or otherwise the total set (when  non-empty) Sort subscripts and superscripts can be inferred from the context, so we do not write them 37

38. More Sugar Functions (recovering “operation” symbols) Similarly we can define partial functions, total relations, etc. Algebraic specification and FOL subsumed notationally. For example: We write it using the functional notation: 38

39. Matching Logic vs. Separation Logic Matching logic achieves separation through matching at the structural (term) level, not through special logical connectives (*). Separation logic = Matching logic [heap] – OOPSLA’12, RTA’15 Matching logic realizes separation at all levels of the configuration, not only in the heap – the heap was only 1 out of the 120 cells in C’s def. 39

40. Separation logic = Matching logic [heap] Consider map model, with some useful axioms Then we can define map patterns “a la SL” 40

41. Examples of Complex Patterns x points to sequence A with |A|>1, and the reversed sequence rev(A) has been output untrusted() can only be called from trusted()  |A| >1 41

42. MatchC Example http://matching-logic.org 42

43. Sound and complete proof system (see paper) Sample derivation Local reasoning can be globalized – Above derivation can be lifted to whole configuration 43

44. Reduction to Predicate Logic (see paper) Like FOL, ML can be reduced to predicate logic Explosion in size, new quantifiers; impractical 44

45. Formal Language Definition (Syntax and Semantics) Deductive program verifier Symbolic execution Need a means to specify static and dynamic program properties 45

46. Reachability Logic for Dynamic Properties [LICS’13], [RTA’14] “Rewrite” rules over matching logic patterns: (generalize to conditional rules) Since patterns generalize terms, matching logic reachability rules capture term rewriting rules Moreover, deals naturally with side conditions: turn into 46

47. Expressiveness of Reachability Rules Capture operational semantics rules: Capture Hoare Triples: 47

48. Reachability Logic Language-independent proof system for deriving sequents of the form where A (axioms) and C (circularities) are sets of reachability rules Intuitively: symbolic execution with operational semantics + reasoning with cyclic behaviors 48

49. Proof System for Reachability Proves any reachability property of any lang., including anything that Hoare logic can (proofs of comparable size) [FM’12] Sound (partially correct) and relatively complete [ICALP’12], [OOPSLA’12], [LICS’13], [RTA’14] 49

50. Traditional Verification vs. Our Approach Traditional proof systems: language-specific Our proof system: language-independent 50

51. Matching Logic Verification Demo Using MatchC – http://matching-logic.org http://matching-logic.org 51

52. Conclusion: It can be done! Thanks to matching logic Deductive program verifier Parser Interpreter Compiler (semantic) Debugger Symbolic execution Model checker Formal Language Definition (Syntax and Semantics) Test-case generation 52