(One-Path) Reachability Logic
Grigore Rosu, Andrei Stefanescu, Brandon MooreUniversity of Illinois at Urbana-Champaign, USA
Stefan CiobacaUniversity Alexadru Ioan Cuza, Romania
Long-Standing DreamDeductive program verifierParser
Interpreter
Compiler
(semantic) Debugger
Symbolic execution
Model checker
Formal Language Definition (Syntax and Semantics)
Language Frameworks• PLT-Redex/Racket (Findler et al.)• OTT (Sewell et al.)• PLanComps (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)
… plus ~1200 user-defined rules… plus ~1500 automatically generated rules
C configuration
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!
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…
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 (ACL2), but proofs are low-level
(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
Deductive program verifierParser
Interpreter
Compiler
(semantic) Debugger
Symbolic execution
Model checker
Formal Language Definition (Syntax and Semantics)
Need a means to specify static and dynamic program properties
Matching Logic
• 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
[Rosu, Ellison, Schulte 2010]
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:
• 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]
Deductive program verifierParser
Interpreter
Compiler
(semantic) Debugger
Symbolic execution
Model checker
Formal Language Definition (Syntax and Semantics)
Need a means to specify static and dynamic program properties
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:
20
Hoare Triple = Syntactic Sugar
Reachability Logic
Language-independent proof system that derives reachability rules from other reachability rules:
Trusted reachability rules(starts with operational semantics)
Target reachability rule
Claimed reachability rules
Intuitively: symbolic execution with operational semantics + reasoning with cyclic behaviors
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 + Z3 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
Top Related