OnePath Reachability Logic Grigore Rosu Andrei Stefanescu Brandon
(One-Path) Reachability Logic Grigore Rosu, Andrei Stefanescu, Brandon Moore University of Illinois at Urbana-Champaign, USA Stefan Ciobaca University Alexadru Ioan Cuza, Romania
Long-Standing Dream Deductive program verifier Parser Interpreter Formal Language Definition (Syntax and Semantics) Compiler (semantic) Debugger Model checker Symbolic execution
Language Frameworks PLT-Redex/Racket (Findler et al. ) OTT (Sewell et al. ) PLan. Comps (Mosses et al. ) Raskal (Klint et al. ) RLS-Maude (Meseguer et al. ) K (Rosu et al. ) … All based on operational semantics Defined semantics serve as language reference models of languages, but are close to useless for verification • Takes 1 -2 years to define a language • • •
C Semantics (in K) C configuration … plus ~1200 user-defined rules … plus ~1500 automatically generated rules
Operational Semantics • Virtually all operational semantics can be defined with rewrite rules of the form • We would like to reason about programs using precisely such operational semantics!
Many different State-of-the-Art program logics for properties: FOL, • Redefine the language using“state” a different semantic HOL, Separation logic… approach (Hoare/separation/dynamic logic) • Very language specific, error-prone; e. g. :
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
Our Proposal • Use directly the trusted operational semantics! – Has been done before (ACL 2), but proofs are lowlevel (induction on the structure of program or on steps in transition system) and language-specific • We give a language-independent proof system – Takes unchanged operational semantics as axioms – Derives reachability rules – Both operational semantics rules and program properties stated as reachability rules – Is sound (partially correct) and relatively complete
Need a means to specify static and dynamic program properties Deductive program verifier Parser Interpreter Formal Language Definition (Syntax and Semantics) Compiler (semantic) Debugger Model checker Symbolic execution
Matching Logic [Rosu, Ellison, Schulte 2010] • Logic for specifying static properties about program configurations and reason with 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
Configurations • For concreteness, assume configurations having the following syntax: (matching logic works with any configurations) • Examples of concrete (ground) configurations:
Patterns • Concrete configurations are already patterns, but very simple ones, ground patterns • Example of more complex pattern • Thus, patterns generalize both terms and [FOL]
Matching Logic Reasoning • We can now prove (using [FOL] reasoning) properties about configurations, such as
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: [OOPSLA’ 12] • 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.
Need a means to specify static and dynamic program properties Deductive program verifier Parser Interpreter Formal Language Definition (Syntax and Semantics) Compiler (semantic) Debugger Model checker Symbolic execution
Reachability Rules - Syntax • “Rewrite” rules over matching logic patterns: • Since patterns generalize terms, matching logic reachability rules capture term rewriting rules • Moreover, deals naturally with side conditions: turn into
Conditional Reachability Rules • The involved patterns can share free variables • Generalize conditional rewrite rules
Reachability Rules - Semantics • In the transition system generated by the operational semantics on the configuration model, any terminating configuration that matches reaches a configuration that matches (patterns can share free variables) • That is, partial correctness
Expressivity of Reachability Rules • Capture operational semantics rules: • Capture Hoare Triples:
Hoare Triple = Syntactic Sugar 20
Reachability Logic Language-independent proof system that derives reachability rules from other reachability rules: Trusted reachability rules (starts with operational semantics) Target reachability rule Intuitively: symbolic execution with operational semantics reasoning with cyclic behaviors Claimed+ reachability rules
7 Proof Rules for Reachability
Traditional Verification vs. Our Approach Traditional proof systems: language-specific Our proof system: language-independent
Results • Soundness (partial correctness): Under weak well-definedness conditions on (see paper) • Mechanized in Coq, for verification certificates • Relative completeness: Under weak assumptions on the configuration model (e. g. , it can express Godel’s beta predicate)
Implementation • Being implemented within the K framework • Symbolic execution using the operational semantic rules; custom solver for the matching part + Z 3 solver for the model reasoning part (for the Consequence rule) • Circularity steps given by user (via pre/post/inv annotations), everything else automatic • Online interface available for fragment of C at http: //matching-logic. org
Related Work and Limitations • Hoare logic: already explained • Dynamic logic: need to redefine language semantics (invariant rules, etc. ), but more expressive: • CTL*: expressive, but not clear how to integrate with operational semantics; maybe CTL* over ML patterns? • Currently we only support one-path reachability for conditional rules. We have a similar proof system for all-path reachability, but only with unconditional rules • Previous one-path attempts: [ICALP’ 12] , [OOPSLA’ 12]
Conclusion • Program verification using the language operational semantics is possible and feasible • Language-independent 7 -rule reachability proof system, which is sound and complete – Circularity generalizes the invariant rules • Being implemented in the K programming language design framework
- Slides: 29