OnePath Reachability Logic Grigore Rosu Andrei Stefanescu Brandon

  • Slides: 29
Download presentation
(One-Path) Reachability Logic Grigore Rosu, Andrei Stefanescu, Brandon Moore University of Illinois at Urbana-Champaign,

(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

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

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

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

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

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,

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

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

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

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

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 •

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,

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

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

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

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

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

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:

Expressivity of Reachability Rules • Capture operational semantics rules: • Capture Hoare Triples:

Hoare Triple = Syntactic Sugar 20

Hoare Triple = Syntactic Sugar 20

Reachability Logic Language-independent proof system that derives reachability rules from other reachability rules: Trusted

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 proof systems: language-specific Our proof system: language-independent

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

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

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

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 •

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