1. Specify and Verify Your Language using K Grigore Rosu University of Illinois at Urbana-Champaign Joint project between the FSL group at UIUC (USA) and the FMSE group at UAIC (Romania) http://k-framework.org

2. K Team UIUC, USA – Grigore Rosu (started K in 2003) – Cansu Erdogan – Patrick Meredith – Eric Mikida – Brandon Moore – Daejun Park – Andrei Stefanescu Former members – Kyle Blocher – Peter Dinges – Chucky Ellison – Dwight Guth – Mike Ilseman – David Lazar – Traian Serbanuta UAIC, Iasi, Romania – Dorel Lucanu – Traian Serbanuta – Andrei Arusoae – Denis Bogdanas – Stefan Ciobaca – Gheorghe Grigoras – Radu Mereuta Former Members – Irina Asavoae – Mihai Asavoae – Emilian Necula – Raluca Necula

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

4. 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 …

5. 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 By April 2011, both Frama-C (with its Jessie verification plugin) and Havoc "prove" it returns 4 int main(void) { int x = 0; return (x = 1) + (x = 2); }

6. A Formal Semantics Manifesto Programming 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?

7. Motivation and Goal We want a semantic framework which makes it easy, fun and useful to define programming languages and to reason about programs!

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

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

10. Complete K Definition of KernelC

11. Syntax declared using annotated BNF …

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

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

14. Underlying Semantics Best explained in terms of graph rewriting – Double pushout gives true concurrency in the presence of configuration sharing Also by translation to rewrite logic – Generic translation of graph rewriting (slow) – Eliminating sharing (fast but loses concurrency) Currently how K is implemented Most users are not aware of K’s complex semantics; don’t need it in order to use K [ICGT’12]

15. Implementation (Java) Front-end Two SDF-based parsers generated, one for programs (concrete syntax) and one for the semantics (concrete + abstract + K syntax) – One can also use custom parsers for programs Back-ends Maude+Z3 (most features); Latex; Java+Z3 (prototype); Coq, ACL2 (in progress) SDF Custom Maude+Z3 Latex Java+Z3 Coq, ACL2

16. K Demo Using Kweb, an online interface to K – http://kframework.org http://kframework.org

17. K Scales Besides smaller and paradigmatic teaching languages, several larger languages were defined Java : 1.4 by Chen &Farzan, and 7 by Bogdanas Verilog : by Meredith and Katelman Phyton : by Guth C : by Ellison etc.

18. K Configuration and Definition of C 75 Cells! Heap … plus ~1200 rules …

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

20. 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]

21. Comparisons of C Semantics

22. Model checker Formal Language Definition (Syntax and Semantics)

23. Model Checking C Programs Detects bugs in finite-state C programs; e.g., races Not discussed here

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

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

26. State-of-the-Art Thus, these semantics need to be proved sound, sometimes also relatively complete, wrt trusted, operational semantics of the language Verification tools developed using them So we have an inherent gap between trusted, operational semantics, and the semantics currently used for program verification

27. Our Proposal Use directly the trusted operational semantics! – Has been done before (ACL2), but proofs are low-level (induction on the transition system) and language-specific We propose a language-independent proof system – Takes operational semantics as axioms – Derives reachability properties – Is sound and relatively complete Formal Language Definition (Syntax and Semantics) Deductive program verifier Symbolic execution

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

29. Matching Logic for Static Properties Logic for specifying static properties about program configurations and reason with them – Generalizes separation logic Key insight: – Configuration terms with variables are allowed to be used as predicates, called patterns! – Semantically, their satisfaction means matching http://matching-logic.org

30. Examples of 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

31. More Formally: Configurations For concreteness, assume configurations having the following syntax: (matching logic works with any configurations) Examples of concrete (ground) configurations:

32. More Formally: Patterns Concrete configurations are already patterns, but very simple ones, ground patterns Example of more complex pattern Thus, patterns generalize both terms and [FOL]

33. More Formally: Reasoning We can now prove (using [FOL] reasoning) properties about configurations, such as

34. 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] SL: ML: Matching logic realizes separation at all levels of the configuration, not only in the heap – the heap was only 1 out of the 75 cells in C’s def. [OOPSLA’12]

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

36. Reachability Rules for Dynamic Properties “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

37. Expressivity of Reachability Rules Capture operational semantics rules: Capture Hoare Triples:

38. 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

39. 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]

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

41. MatchC Demo?

42. Example – Swapping Values What is the K semantics of the swap function? Let $ be its body $ if x = y rule $ => return; … … x|->(a=>b), y|->(b=>a) … rule $ => return; … … x|-> a … if x = y

43. Example – Reversing a list What is the K semantics of the reverse function? Let $ be its body $ rule $ => return p; … list(x,A) => list(p,rev(A)) …

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