of 29/29
(One-Path) Reachability Logic Grigore Rosu, Andrei Stefanescu, Brandon Moore University of Illinois at Urbana-Champaign, USA Stefan Ciobaca University Alexadru Ioan Cuza, Romania

(One-Path) Reachability Logic

  • View
    49

  • Download
    0

Embed Size (px)

DESCRIPTION

(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 - PowerPoint PPT Presentation

Text of (One-Path) Reachability Logic

K Framework

(One-Path) Reachability LogicGrigore Rosu, Andrei Stefanescu, Brandon MooreUniversity of Illinois at Urbana-Champaign, USA

Stefan CiobacaUniversity Alexadru Ioan Cuza, Romania1Long-Standing DreamDeductive program verifierParserInterpreterCompiler(semantic) DebuggerSymbolic executionModel checkerFormal Language Definition (Syntax and Semantics)One long-standing dream of the programming language community is to have a framework that allows and encourages the language designers to formally define their languages once and for all, using an intuitive and attractive notation, and then obtain essentially for free implementations as well as analysis tools for the defined languages.2Language FrameworksPLT-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 semanticsDefined semantics serve as language reference models of languages, but are close to useless for verification Takes 1-2 years to define a languageC Semantics (in K)

plus ~1200 user-defined rules plus ~1500 automatically generated rulesC configurationTo give an idea what it takes to define a large language, here is, for example, the configuration of C.It has more than 70 cells!The heap, which is the subject of so many debates in program verification, is just one of them.

4Operational SemanticsVirtually 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-ArtRedefine 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 logicState-of-the-ArtThus, these semantics need to be proved sound, sometimes also relatively complete, wrt trusted, operational semantics of the languageVerification tools developed using themSo we have an inherent gap between trusted, operational semantics, and the semantics currently used for program verificationOur ProposalUse 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-specificWe give a language-independent proof systemTakes unchanged operational semantics as axiomsDerives reachability rulesBoth operational semantics rules and program properties stated as reachability rulesIs sound (partially correct) and relatively completeDeductive program verifierParserInterpreterCompiler(semantic) DebuggerSymbolic executionModel checkerFormal Language Definition (Syntax and Semantics)Need a means to specify static and dynamic program propertiesMatching LogicLogic for specifying static properties about program configurations and reason with themKey insight:Configuration terms with variables are allowed to be used as predicates, called patternsSemantically, their satisfaction means matchingMatching logic is parametric in a (first-order) configuration model: typically the underlying model of the operational semantics[Rosu, Ellison, Schulte 2010]ConfigurationsFor concreteness, assume configurations having the following syntax:

(matching logic works with any configurations)

Examples of concrete (ground) configurations:

PatternsConcrete configurations are already patterns, but very simple ones, ground patternsExample of more complex pattern

Thus, patterns generalize both terms and [FOL]

Matching Logic ReasoningWe can now prove (using [FOL] reasoning) properties about configurations, such as

Matching Logic vs. Separation LogicMatching 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 heapthe heap was only 1 out of the 75 cells in Cs def.

[OOPSLA12]Deductive program verifierParserInterpreterCompiler(semantic) DebuggerSymbolic executionModel checkerFormal Language Definition (Syntax and Semantics)Need a means to specify static and dynamic program propertiesReachability Rules - SyntaxRewrite rules over matching logic patterns:

Since patterns generalize terms, matching logic reachability rules capture term rewriting rulesMoreover, deals naturally with side conditions:

turn into

Conditional Reachability RulesThe involved patterns can share free variablesGeneralize conditional rewrite rules

Reachability Rules - SemanticsIn 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 RulesCapture operational semantics rules:

Capture Hoare Triples:

Hoare Triple = Syntactic Sugar20

This is a code fragment from a program reversing a singly-linked list verified by MatchC (which we will discuss later). The invariant, states that p points to the part of the list already reversed, and x points to the part of the list yet to be reversed. This Hoare-style invariant is just syntactic sugar for a reachability rule. The LHS combines the code of the loop (shown in red) and the invariant, while in the RHS the code has been executed, and the condition of the loop has been evaluated with the semantics and its negation added as a constraint (shown in blue).20Reachability LogicLanguage-independent proof system that derives reachability rules from other reachability rules:

Trusted reachability rules(starts with operational semantics)Target reachability rule

Claimed reachability rulesIntuitively: symbolic execution with operational semantics + reasoning with cyclic behaviorsThe main result of the paper is a language-independent proof system which derives reachability rules specifying program properties from trusted reachability rules. In the beginning the trusted rules are just the operational semantics rules. During the proof one can claim additional reachability rules, which cannot be used right away.They can be used only after taking at least one step with the trusted rules in A.// The rules in C are added to those on A only after taking at least one step with the trusted rules in A.217 Proof Rules for Reachability

Traditional Verification vs. Our ApproachTraditional proof systems: language-specific

Our proof system: language-independent

ResultsSoundness (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 Godels beta predicate)

ImplementationBeing implemented within the K frameworkSymbolic 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 automaticOnline interface available for fragment of C athttp://matching-logic.orgRelated Work and LimitationsHoare logic: already explainedDynamic 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 rulesPrevious one-path attempts: [ICALP12] , [OOPSLA12]

ConclusionProgram verification using the language operational semantics is possible and feasible Language-independent 7-rule reachability proof system, which is sound and completeCircularity generalizes the invariant rulesBeing implemented in the K programming language design framework