One path reachability logic
1 / 29

(One-Path) Reachability Logic - PowerPoint PPT Presentation

  • Uploaded on

(One-Path) Reachability Logic. Grigore Rosu , Andrei Stefanescu , Brandon Moore University of Illinois at Urbana-Champaign, USA Stefan Ciobaca University Alexadru Ioa n Cuza , Romania. Long-Standing Dream. Deductive program verifier. Parser. Interpreter. Formal Language Definition

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' (One-Path) Reachability Logic' - aden

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
One path reachability logic

(One-Path) Reachability Logic

Grigore Rosu, Andrei Stefanescu, Brandon Moore

University of Illinois at Urbana-Champaign, USA

Stefan Ciobaca

University AlexadruIoanCuza, Romania

Long standing dream
Long-Standing Dream

Deductive program verifier



Formal Language Definition

(Syntax and Semantics)

Model checker


Symbolic execution

(semantic) Debugger

Language frameworks
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
C Semantics (in K)

C configuration

… plus ~1200 user-defined rules

… plus ~1500 automatically generated rules

Operational semantics
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

Many different program logics for “state” properties: FOL, HOL, Separation logic…

  • Redefine the language using a different semantic approach (Hoare/separation/dynamic logic)

  • Very language specific, error-prone; e.g.:

State of the art1

  • 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
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

Need a means to specify static and dynamic program properties

Deductive program verifier



Formal Language Definition

(Syntax and Semantics)

Model checker


Symbolic execution

(semantic) Debugger

Matching logic
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


  • For concreteness, assume configurations having the following syntax:

    (matching logic works with any configurations)

  • Examples of concrete (ground) configurations:


  • 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
Matching Logic Reasoning

  • We can now prove (using [FOL] reasoning) properties about configurations, such as

Matching logic vs separation logic
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]



  • 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



Formal Language Definition

(Syntax and Semantics)

Model checker


Symbolic execution

(semantic) Debugger

Reachability rules syntax
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
Conditional Reachability Rules

  • The involved patterns can share free variables

  • Generalize conditional rewrite rules

Reachability rules semantics
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
Expressivity of Reachability Rules

  • Capture operational semantics rules:

  • Capture Hoare Triples:

Reachability logic
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
7 Proof Rules for Reachability

Traditional verification vs our approach
Traditional Verification vs. Our Approach

Traditional proof systems: language-specific

Our proof system: language-independent


  • 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)


  • 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

Related work and limitations
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]


  • 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