Model-based reasoning meets code verification Michael Butler 21 May 2014 WG 2.3 Meeting 55, Orlando.

Slides:



Advertisements
Similar presentations
Logical Abstract Interpretation Sumit Gulwani Microsoft Research, Redmond.
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
1 Data Link Protocols By Erik Reeber. 2 Goals Use SPIN to model-check successively more complex protocols Using the protocols in Tannenbaums 3 rd Edition.
Formal Methods and Testing Goal: software reliability Use software engineering methodologies to develop the code. Use formal methods during code development.
A Program Transformation For Faster Goal-Directed Search Akash Lal, Shaz Qadeer Microsoft Research.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
50.530: Software Engineering Sun Jun SUTD. Week 10: Invariant Generation.
Pontus Boström and Marina Waldén Åbo Akademi University/ TUCS Development of Fault Tolerant Grid Applications Using Distributed B.
Reduction, abstraction, and atomicity: How much can we prove about concurrent programs using them? Serdar Tasiran Koç University Istanbul, Turkey Tayfun.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
1 How to transform an analyzer into a verifier. 2 OUTLINE OF THE LECTURE a verification technique which combines abstract interpretation and Park’s fixpoint.
Hybrid System Verification Synchronous Workshop 2003 A New Verification Algorithm for Planar Differential Inclusions Gordon Pace University of Malta December.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
A survey of techniques for precise program slicing Komondoor V. Raghavan Indian Institute of Science, Bangalore.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar Shaz Qadeer.
Termination Proofs for Systems Code Andrey Rybalchenko, EPFL/MPI joint work with Byron Cook, MSR and Andreas Podelski, MPI PLDI’2006, Ottawa.
C. FlanaganSAS’04: Type Inference Against Races1 Type Inference Against Races Cormac Flanagan UC Santa Cruz Stephen N. Freund Williams College.
Penn ESE 535 Spring DeHon 1 ESE535: Electronic Design Automation Day 13: March 4, 2009 FSM Equivalence Checking.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar [UC Berkeley] Shaz Qadeer [Microsoft Research]
Chapter 2: Algorithm Discovery and Design
Penn ESE 535 Spring DeHon 1 ESE535: Electronic Design Automation Day 22: April 23, 2008 FSM Equivalence Checking.
Recursion.
Overview of program analysis Mooly Sagiv html://
Recursion Chapter 7. Chapter 7: Recursion2 Chapter Objectives To understand how to think recursively To learn how to trace a recursive method To learn.
Proving termination conditions Name Country, City, University Omer Subasi Turkey, Istanbul, Koc University Anton Dergunov
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Invitation to Computer Science, Java Version, Second Edition.
Recursion Chapter 7. Chapter Objectives  To understand how to think recursively  To learn how to trace a recursive method  To learn how to write recursive.
Chapter 3 (Part 3): Mathematical Reasoning, Induction & Recursion  Recursive Algorithms (3.5)  Program Correctness (3.6)
Program Analysis with Dynamic Change of Precision Dirk Beyer Tom Henzinger Grégory Théoduloz Presented by: Pashootan Vaezipoor Directed Reading ASE 2008.
10/14/ Algorithms1 Algorithms - Ch2 - Sorting.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
2/19/20031 Introduction to SMV. 2/19/20032 Useful Links CMU Model checking homepage SMV windows version
Introduction to Problem Solving. Steps in Programming A Very Simplified Picture –Problem Definition & Analysis – High Level Strategy for a solution –Arriving.
Reasoning about programs March CSE 403, Winter 2011, Brun.
EEL 5937 Managing mutability in agents EEL 5937 Multi Agent Systems Lecture 26, April 10, 2003 Lotzi Bölöni.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Scientific Debugging. Errors in Software Errors are unexpected behaviors or outputs in programs As long as software is developed by humans, it will contain.
Predicate Abstraction. Abstract state space exploration Method: (1) start in the abstract initial state (2) use to compute reachable states (invariants)
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
Understanding ADTs CSE 331 University of Washington.
SAT-Based Model Checking Without Unrolling Aaron R. Bradley.
Loop Invariants and Binary Search Chapter 4.4, 5.1.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Simplifying Linearizability Proofs Using Reduction and Abstraction Serdar Tasiran Koc University, Istanbul, Turkey Tayfun Elmas, Ali Sezgin, Omer Subasi.
David Evans CS201J: Engineering Software University of Virginia Computer Science Lecture 5: Implementing Data Abstractions.
Diagnostic Information for Control-Flow Analysis of Workflow Graphs (aka Free-Choice Workflow Nets) Cédric Favre(1,2), Hagen Völzer(1), Peter Müller(2)
© Anvesh Komuravelli Spacer Model Checking with Proofs and Counterexamples Anvesh Komuravelli Carnegie Mellon University Joint work with Arie Gurfinkel,
Abstraction and Abstract Interpretation. Abstraction (a simplified view) Abstraction is an effective tool in verification Given a transition system, we.
Fundamentals of Fault-Tolerant Distributed Computing In Asynchronous Environments Paper by Felix C. Gartner Graeme Coakley COEN 317 November 23, 2003.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
1 Sections 7.2 – 7.7 Nested Control Statements Fundamentals of Java: AP Computer Science Essentials, 4th Edition Lambert / Osborne.
Chapter 3 of Programming Languages by Ravi Sethi
Input Space Partition Testing CS 4501 / 6501 Software Testing
Reasoning about code CSE 331 University of Washington.
Graph-Based Operational Semantics
Proving Loops Testing debugging and verification
Hoare Logic LN chapter 5, 6 but without 6. 8, 6. 12, 6
Monday, April 16, 2018 Announcements… For Today…
Over-Approximating Boolean Programs with Unbounded Thread Creation
Axiomatic Verification II
Automated Extraction of Inductive Invariants to Aid Model Checking
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
CSCI1600: Embedded and Real Time Software
Axiomatic Verification II
Presentation transcript:

Model-based reasoning meets code verification Michael Butler 21 May 2014 WG 2.3 Meeting 55, Orlando

Talk is about Distinguish algorithm from its implementation Use of patterns / ghost elements for – Verification of algorithm wrt its spec independently from its implementation – Verification of implementation wrt algorithm – Mechanised verification by linking existing verification systems Dafny & Event-B/Rodin

Model of a transition system SETS STATE CONSTANTS init, tr, inv, reach tr ∈ STATE ↔ STATE// transition relation inv ⊆ STATE // states satisfying invariant init ⊆ inv// initial states (satisfy inv) reach = tr * [init]// set of reachable states

Algorithm Specification IF reach ⊆ inv THEN result := SAFE ELSE result := UNSAFE END

Representing the transition system in Dafny class STATE {}; method initStates returns ( res: seq ) ensures res == initial states of system; method get_successors( s:STATE ) returns ( succ: seq ) ensures succ == “all successors of s” method check_inv(s: STATE) returns ( ok:bool ) ensures ok == “s satisfies invariant”

Implementation of algorithm method CheckReach() returns ( pass: bool ) {var safe : seq := initStates() ; var err: seq := [] ; var i := 0 ; while ( i < |safe| && err == [] ) { var j := 0; s1 := safe[i]; succ := get_successors(s1); while ( j < |succ| && err == [] ) { var s2 := succ[j]; if ( s2 !in safe && s2 !in err ) { if ( check_inv(s2) ) {safe := safe + [s2]; } else { err := err + [s2]; }} ; j := j + 1; } ; i := i + 1; } ; if ( err == [] ) { pass := true; }else{ pass := false; } }

FindOk NoFind Search StartFind Pass(i) FindOk some i StartFind Fail(i) NoFind all i Search algorithm pattern FindOk: ∃x∈S P(x) or NoFind: ∀x∈S ¬P(x) 7 xor

Could merge to form a (less abstract) sequential algorithm StartFind ; for i in S do Fail(i) [] Pass(i) ; exit od ; if exit then FindOk else NoFind fi 8

FindOk StartFind Pass(p,i) FindOk some i:S[p] Alternatively refine to parallel model Partition S so that search is farmed out to multiple processors p ∈ P This is a simple refinement step in Event-B some p:P 9

What’s in a refinement pattern? Determining the refined events is relatively easy once we decide on the appropriate abstract program structure to use But determining the right gluing invariants can be difficult Patterns: from a certain specification structure – determine refined events – gluing invariants – convergence variants 10

“All Condition” Pattern CondAll ≙ when ∀ i ∈ S Cond(i) then action end 11 Search Fail: Cond(i) ≙ ¬Property(i)

Refinement of CondAll Step ≙ any i where Cond(i) ∧ s ∉ oStep then oStep := oStep ∪ {i} end CondAll ≙ when oStep = S then action end 12 CondAll Step(i) CondAll all i:S invariant ∀ i ∈ oStep Cond(i) i ∈ oStep iff Step(i) event has occurred

“Some Condition” Pattern CondSome ≙ when ∃ i. i ∈ S ∧ Cond(i) then action end CondSome ≙ any i where i ∈ S Cond(i) then action(i) end 13

Refinement of CondSome Step ≙ any i where Cond(i) ∧ s ∉ oStep then oStep := oStep ∪ {i} end CondSome ≙ any i where i ∈ oStep then action(i) end 14 CondSome Step(i) CondSome some i:S invariant ∀ i ∈ oStep Cond(i)

FindOk NoFind Search StartFind Pass(i) FindOk some i StartFind Fail(i) NoFind all i Refinement invariants for search Invariant:o Pass ⊆ S∩P Invariant:o Fail ⊆ S \ P 15 xor

FindOk NoFind Search StartFind Pass(i) FindOk some i StartFind Fail(i) NoFind all i Convergence variant for search Variant: S \ ( oPass ∪ oFail ) Invariant:finite(S) 16 xor

Event-B spec of reachability Pass ≙ WHEN reach ⊆ inv THEN result := SAFE END Fail ≙ ANY e WHERE e ∈ reach e ∉ inv THEN result := UNSAFE error_state := e END reach is a ghost constant and it needs to be removed in the implementation Refine the model to one that computes the reachable states step- by-step

Fail Pass Reach Start Error(s) Fail Some s Start Ok(s) Pass All s Guards for reachability events Fail: ∃s∈reach ¬Inv(s) or Pass: ∀s∈reach Inv(s) 18 xor

Fail Pass Reach Start Error(s) Fail Some s Start Safe(s) Pass All s Invariants for reachability refinement Invariant:oSafe ⊆ reach ∩ inv Invariant:o Error ⊆ reach \ inv 19 xor

Spec of Safe event EventSafe // add a new successor state that satisfies invariant to oSafe ANY s WHERE s ∈ reach s ∈ inv s ∉ oSafe THEN oSafe := oSafe ∪ {s} END

Convergence of Safe and Error events Variant: S \ ( oSafe ∪ oFail ) Invariant:finite(S)

Refining the Fail event Abstract Fail ≙ ANY e WHERE e ∈ reach e ∉ inv THEN result := FAIL error_state := e END Refined Fail ≙ ANY e WHERE e ∈ oError THEN result := FAIL error_state := e END Invariant: oError ⊆ reach ∖ inv Prove guard strengthening refined guard = e ∈ oError ⇒ “invariant” e ∈ reach ∖ inv = abstract guard

Refining the Pass event Abstract Pass ≙ WHEN reach ⊆ inv THEN result := OK END Refined Pass ≙ WHEN oSafe = reach THEN result := OK END Invariant: oSafe ⊆ reach ∩ inv Prove guard strengthening oSafe = reach ⇒ “invariant” reach ⊆ reach ∩ inv ⇒ “set theory” reach ⊆ inv

The specter of reach remains Fail events do not refer to reach so no further refinement required Pass events still do refer to reach, so further refinement required Refine the guard of the Safe(s) event: s ∈ reach ⇐ “reach is a fixed point” ∃ s1 s1 ∈ reach ∧ s1 ↦ s ∈ tr ⇐ “oSafe ⊆ reach” ∃ s1 s1 ∈ oSafe ∧ s1 ↦ s ∈ tr

Add new parameter to Safe event Event Safe ANY s, s1 WHERE s1 ∈ oSafe s1 ↦ s ∈ tr s ∈ inv s ∉ oSafe THEN oSafe := oSafe ∪ {s} END

Extra parameter gives nested iteration 26 Pass Safe(s) Pass all s Pass Safe(s1,s) Pass all s1 all s

Further refinement: tracking the explored states A state is explored if it is in safe and all its successors are reached Invariant: tr[ explored ] ⊆ ( oSafe ∪ oError ) Introduce new event: Event Mark_explored ANY s WHERE s ∈ rac s ∉ explored tr[{s}] ⊆ ( oSafe ∪ oError ) THEN explored := explored ∪ {s} END

Refining the Pass event Pass ≙ WHEN oSafe = reach THEN result := OK END Refined Pass ≙ WHEN explored = oSafe oError = {} THEN result := OK END Invariant: tr[ explored ] ⊆ ( oSafe ∪ oError ) Prove guard strengthening explored = oSafe ∧ oError = {} ⇒ “invariant” tr[ oSafe ] ⊆ oSafe ⇒ “reach is least fixed point” reach ⊆ oSafe

What to verify in Dafny? Verify that the Dafny code is a correct refinement of the final Event-B model Event-B variables become ghost variables in Dafny Gluing invariants in Dafny: invariant oSafe == seqElems(safe); invariant oError == seqElems(err); invariant explored == seqElems(safe[0..i]); Embed the events into the Dafny code

Embed events in the Dafny method CheckReach() returns ( pass: bool ) {… Init while ( i < |safe| && err == [] ) { var j := 0; s1 := safe[i]; succ := get_successors(s1); while ( j < |succ| && err == [] ) { var s2 := succ[j]; if ( s2 !in safe && s2 !in err ) { if ( check_inv(s2) ) {safe := safe + [s2]; Safe(s1,s2); }; else { err := err + [s2]; Error(s2); }} ; j := j + 1; } ; Mark_Explored ; i := i + 1; } ; if ( err == [] ) { pass := true; Pass ; } else{ pass := false; Fail ; } }

Ghost busters Guarded event: when G then A end == (assume G) ; A Eliminating guards with assertions (assert G) ; (assume G) ; A ⊑ A Once guards are removed, ghost variables no longer influence the program so can be eliminated

Concluding Correctness of algorithm is proved independently of Dafny (with help from patterns) At Dafny level we prove that the code is a correct implementation of the algorithm – Avoided any duplication in proof except for Dafny variants NB: proposed “embeddding” method for proving Dafny refines the algorithm only works if code is deterministic