AllPath Reachability Logic Andrei Stefanescu 1 Stefan Ciobaca

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

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

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

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

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

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

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

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 ACL 2 before 7

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

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

State-of-the-art in Certifiable Verification Languages C (Appel et al. ) – Comp. Cert 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

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

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

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

Matching Logic [Rosu, Ellison, Schulte 2010] 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

Patterns C configurations Extra 70 cells Example of a pattern 15

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

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 [OOPSLA’ 12] No expressiveness loss from using matching logic Matching logic gives “structural separation” anywhere in the configuration, not only in the heap 17

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

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

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

Reachability Rules - Operational + Axiomatic Operational flavor Axiomatic flavor 21

Hoare Triple = Syntactic Sugar 22

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

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

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

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

Reachability Proof System - 8 Rules - Code with circular behavior 27 Symbolic execution (multiple steps)

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

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

Reachability Proof System 30

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

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

Implementation Part of the K framework (k-framework. org) Operational semantics represented as K rules and program properties 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 Z 3 (for theory reasoning) 33

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

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