(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