One path reachability logic
This presentation is the property of its rightful owner.
Sponsored Links
1 / 29

(One-Path) Reachability Logic PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on
  • Presentation posted in: General

(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

Download Presentation

(One-Path) Reachability Logic

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

Parser

Interpreter

Formal Language Definition

(Syntax and Semantics)

Model checker

Compiler

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

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

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

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


One path reachability logic

Need a means to specify static and dynamic program properties

Deductive program verifier

Parser

Interpreter

Formal Language Definition

(Syntax and Semantics)

Model checker

Compiler

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


Configurations

Configurations

  • For concreteness, assume configurations having the following syntax:

    (matching logic works with any configurations)

  • Examples of concrete (ground) configurations:


Patterns

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

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]

    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]


One path reachability logic

Need a means to specify static and dynamic program properties

Deductive program verifier

Parser

Interpreter

Formal Language Definition

(Syntax and Semantics)

Model checker

Compiler

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:


Hoare triple syntactic s ugar

Hoare Triple = Syntactic Sugar


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


Results

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

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

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

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


  • Login