Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009.
Advanced programming tools at Microsoft
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
M ODEL CHECKING -Vasvi Kakkad University of Sydney.
Algorithmic Software Verification VII. Computation tree logic and bisimulations.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Verification of Evolving Software Natasha Sharygina Joint work with Sagar Chaki and Nishant Sinha Carnegie Mellon University.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Thomas Ball, Rupak Majumdar, Todd Millstein, Sriram K. Rajamani Presented by Yifan Li November 22nd In PLDI 01: Programming Language.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Verification of parameterised systems
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
CSEP590 – Model Checking and Software Verification University of Washington Department of Computer Science and Engineering Summer 2003.
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
Synergy: A New Algorithm for Property Checking
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball and Sriram K. Rajamani Software Productivity Tools, Microsoft Research Presented.
Witness and Counterexample Li Tan Oct. 15, 2002.
Review of the automata-theoretic approach to model-checking.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Witness and Counterexample Li Tan Oct. 15, 2002.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Automatic Predicate Abstraction of C Programs Thomas BallMicrosoft Rupak MajumdarUC Berkeley Todd MillsteinU Washington Sriram K. RajamaniMicrosoft
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
50.530: Software Engineering
1 Introduction to SMV and Model Checking Mostly by: Ken McMillan Cadence Berkeley Labs Small parts by: Brandon Eames ISIS/Vanderbilt.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 3: Modular Verification with Magic, Predicate Abstraction.
Rule Checking SLAM Checking Temporal Properties of Software with Boolean Programs Thomas Ball, Sriram K. Rajamani Microsoft Research Presented by Okan.
10/19/2015COSC , Lecture 171 Real-Time Systems, COSC , Lecture 17 Stefan Andrei.
CS6133 Software Specification and Verification
Reactive systems – general
Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications 1.
Newton: A tool for generating abstract explanations of infeasibility1 The Problem P (C Program) BP (Boolean Program of P) CFG(P) CFG(BP)
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball, Sriram K. MSR Presented by Xin Li.
Verification & Validation By: Amir Masoud Gharehbaghi
The Yogi Project Software property checking via static analysis and testing Aditya V. Nori, Sriram K. Rajamani, Sai Deep Tetali, Aditya V. Thakur Microsoft.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
1 Automatically Validating Temporal Safety Properties of Interfaces - Overview of SLAM Parts of the slides are from
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Basic concepts of Model Checking
Formal methods: Lecture
Algorithm and Ambiguity
Over-Approximating Boolean Programs with Unbounded Thread Creation
Formal Methods in software development
Formal Methods in software development
Formal Methods in software development
50.530: Software Engineering
Linear Time Properties
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
Formal Methods in software development
Course: CS60030 Formal Systems
Presentation transcript:

Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking

2 Overview  The big picture  Example to be verified  Ingredients of a model checking system  The state explosion problem  Applications of model checking  SLAM

3 The big picture  Application domain: mostly concurrent, reactive systems  Verification of particular properties  Verify that a system satisfies a property: 1. Model the system in the model checker’s description language. Call this model M 2. Express the property to be verified in the specification language of the model checker. Call this formula ϕ 3. Run the model checker to show that M satisfies ϕ, i.e. M ⊨ ϕ  Automatic for finite-state models

4 Example 2 processes execute in parallel Each undergoes transitions n → r → c → n → … where  n denotes “not in critical section”  r denotes “requesting to enter critical section”  c denotes “in critical section” Requirements:  Safety: Only one process may execute critical section code at any point  Liveness: Whenever a process requests to enter its critical section, it will eventually be allowed to do so  Non-blocking: A process can always request to enter its critical section

5 Example (cont) We write a program P to fulfill these requirements. But is it really doing its job? We construct a model M for P where M captures the relevant behavior of P: n1n2n1n2 r1n2r1n2 r1r2r1r2 r1c2r1c2 c1r2c1r2 n1r2n1r2 n1c2n1c2 c1n2c1n2 s2s2 s5s5 s7s7 s4s4 s1s1 s0s0 s3s3 s6s6

6 Example (cont) Based on a definition of when a model satisfies a property, we can determine whether M satisfies P’s required properties Example: M satisfies the safety requirement if no state reachable from s 0 (including s 0 ) is labeled c 1 c 2. Thus our M satisfies P’s safety requirement We can formalize the idea Note: the conclusion that P satisfies these requirements depends on the (unverified) assumption that M is a faithful representation of all the relevant aspects of P

7 Ingredients of a model checking system Models, specifications, a satisfaction relation, a satisfaction checking algorithm. Tasks: 1.Define what models are 2.Define what specifications are 3.Define when a model satisfies a specification 4.Devise an efficient algorithm to decide satisfaction

8 1. Define what models are Many formalisms, e.g. Kripke models, LTSs, … A transition system M = (S, →, L) is a set of states S with a transition relation → (a binary relation on S), such that every s S has some s’ S with s → s’, and a labeling function L: S → Ρ(Atoms), where Atoms is a set of atomic descriptions. Our example: a transition system with  S = {s 0, s 1, s 2, s 3, s 4, s 5, s 6, s 7 }  → = {(s 0,s 1 ), (s 0,s 5 ), (s 1,s 2 ), (s 1,s 3 ), (s 4, s 5 ), …}  L(s 0 ) = {n 1,n 2 }, L(s 1 ) = {r 1,n 2 }, L(s 3 ) = {r 1,r 2 }, … where Atoms = {n 1, r 1, c 1, n 2, r 2, c 2 } Define a concrete syntax in which models can be described

9 2. Define what specifications are They describe properties of models Temporal logics (e.g. LTL, CTL) are often used to specify properties of concurrent, reactive systems. Syntax of LTL formulas: ϕ ::= true | false | p | ( ¬ ϕ ) | ( ϕ ˄ ϕ ) | ( ϕ v ϕ ) | ( ϕ → ϕ ) | (X ϕ ) | (G ϕ ) | (F ϕ ) | ( ϕ U ϕ ) | ( ϕ W ϕ ) | ( ϕ R ϕ ) Example specifications: G ¬ (c 1 ˄ c 2 ), G (r 1 → F c 1 ) and G (r 2 → F c 2 ) Define a concrete syntax for specifications

10 3. Define the satisfaction relation For a path π = s 1 → s 2 →... in a model M & LTL formula ϕ : π ⊨ true π ⊨ false π ⊨ p iff p L(s 1 ) π ⊨ ¬ ϕ iff π ⊨ ϕ π ⊨ ϕ 1 ˄ ϕ 2 iff π ⊨ ϕ 1 and π ⊨ ϕ 2 π ⊨ ϕ 1 v ϕ 2 iff π ⊨ ϕ 1 or π ⊨ ϕ 2 π ⊨ ϕ 1 → ϕ 2 iff π ⊨ ϕ 2 whenever π ⊨ ϕ 1 π ⊨ X ϕ iff π 2 ⊨ ϕ (π i = s i → s i+1 →...) π ⊨ G ϕ iff for all i ≥ 1, π i ⊨ ϕ π ⊨ F ϕ iff there is some i ≥ 1 such that π i ⊨ ϕ π ⊨ ϕ 1 U ϕ 2 iff there is some i ≥ 1 such that π i ⊨ ϕ 2 and for all 1 ≤ j < i, π j ⊨ ϕ 1 / / neXt Globally Future Until Weak-until Release

11 3. Define the satisfaction relation (cont.) π ⊨ ϕ 1 W ϕ 2 iff either π ⊨ ϕ 1 U ϕ 2 or for all i ≥ 1, π i ⊨ ϕ 1 π ⊨ ϕ 1 R ϕ 2 iff either there is some i ≥ 1 such that π i ⊨ ϕ 1 and for all 1 ≤ j ≤ i we have π j ⊨ ϕ 2, or for all k ≥ 1, π k ⊨ ϕ 2 Suppose M = (S, →, L) is a model, s S and ϕ is an LTL formula. M,s ⊨ ϕ iff for every path π of M starting at s we have π ⊨ ϕ Thus we are able to prove for our example that:  M,s 0 ⊨ G ¬ (c 1 ˄ c 2 ) (the safety property holds).  M,s 0 ⊨ G (r 1 → F c 1 ) (the liveness property does not hold – a counterexample path is s 0 → s 1 → s 3 → s 7 → s 1 → s 3 → s 7 →...).  The non-blocking property is not expressible in LTL. /

12 4. Provide a checking algorithm Devise an efficient algorithm to decide M ⊨ ϕ Typically without user interaction Approaches: semantic, automata, tableau, … Provide a counterexample when M ⊨ ϕ. The counterexample provides a clue to what is wrong:  The system might be incorrect  The model might be too abstract (in need of refinement)  The specification might not be the intended one /

13 The state explosion problem The number of states grow exponentially with the number of system components For our example: 3 processes execute in parallel, 4 processes, etc. Techniques to make state explosion less severe:  Abstraction  Induction  Partial order reduction  …

14 Applications Verification of specific properties of:  Hardware circuits  Communication protocols  Control software  Embedded systems  Device drivers (e.g. SLAM project of Microsoft)  … Real-world problems: “10 20 states and beyond” Useful: 2007 Turing Award (Clarke, Emerson and Sifakis) We now turn to SLAM

15 SLAM introduction Faulty drivers often responsible for OS crashes Verifying proper driver API usage E.g. a lock is never released without being first acquired Prevent

16 SLAM introduction (cont) Input: a C program P (the device driver code) and temporal safety properties expressed as a SLIC specification ϕ Output (if terminates): P ⊨ ϕ or P ⊨ ϕ /

17 SLIC property specification A SLIC spec ϕ is a state machine Example: state { enum {Unlocked = 0, Locked = 1} state = Unlocked; } KeAcquireSpinLock.return { if (state==Locked) abort; else state = Locked; } KeReleaseSpinLock.return { if (state==Unlocked) abort; else state = Unlocked; } UnlockedLocked Error Rel Acq Rel

18 Translating SLIC spec to C state { enum {Unlocked = 0, Locked = 1} state = Unlocked; } KeAcquireSpinLock.return { if (state==Locked) abort; else state = Locked; } KeReleaseSpinLock.return { if (state==Unlocked) abort; else state = Unlocked; } enum {Unlocked = 0, Locked = 1} state = Unlocked; void slic_abort() { SLIC_ERROR: ; } void KeAcquireSpinLock_return { if (state==Locked) slic_abort(); else state = Locked; } void KeReleaseSpinLock_return { if (state==Unlocked) slic_abort(); else state = Unlocked; }

19 The device driver code P do { KeAcquireSpinLock(); nPacketsOld = nPackets; if (request) { request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock();

20 The instrumented program P’ Compose P with C version of ϕ to obtain an instrumented P’. If SLIC_ERROR is reachable in P’, then P ⊨ ϕ else P ⊨ ϕ. Example P’: / enum {Unlocked = 0, Locked = 1} state = Unlocked; void slic_abort() { SLIC_ERROR: ; } void KeAcquireSpinLock_return { if (state==Locked) slic_abort(); else state = Locked; } void KeReleaseSpinLock_return { if (state==Unlocked) slic_abort(); else state = Unlocked; } do { KeAcquireSpinLock(); A: KeAcquireSpinLock_return(); nPacketsOld = nPackets; if (request) { request = request->Next; KeReleaseSpinLock(); B: KeReleaseSpinLock_return(); nPackets++; } } while (nPacketsOld != nPackets); KeReleaseSpinLock(); C: KeReleaseSpinLock_return();

21 The SLAM verification process Iterative process to determine whether SLIC_ERROR is reachable in P’: prog. P’ prog. P SLIC rule boolean program path predicates slic c2bp bebop newton

22 SLAM iteration Let E 0 be the predicates present in the conditionals of ϕ. For iteration i: 1.Apply c2bp to construct the boolean program BP(P’,E i ) 2.Apply bebop to check if there is a path p i in BP(P’,E i ) that reaches SLIC_ERROR. If bebop determines that SLIC_ERROR is not reachable, then ϕ is valid in P and the algorithm terminates 3.If there such a path p i, then newton checks whether p i is feasible in P’. Two possible outcomes: 1. “yes”: ϕ has been invalidated in P and the algorithm terminates with counterexample p i 2. “no”: newton finds a set of predicates F i that explain the infeasibility of p i in P’ 4.Let E i+1 := E i ∪ F i and i := i + 1 and proceed to the next iteration

23 Some observations The original satisfaction problem has been translated into a boolean program reachability problem. For every statement s in P’ and every predicate e E i, c2bp determines the effect of s on e to build the boolean program.

24 Iteration 0 E 0 = {state = Locked, state = Unlocked} BP(P’,E 0 ): decl {state=Unlocked}, {state=Locked}; {state=Unlocked} := T; {state=Locked} := F; void slic_abort() { SLIC_ERROR: skip; } void KeAcquireSpinLock_return { if ({state=Locked}) slic_abort(); else { {state=Locked} := T; {state=Unlocked} := F; } } void KeReleaseSpinLock_return { if ({state=Unlocked}) slic_abort(); else { {state = Unlocked} := T; {state = Locked} := F; } } do { skip; A: KeAcquireSpinLock_return(); skip; if (*) { skip; B: KeReleaseSpinLock_return(); skip; } } while (*); skip; C: KeReleaseSpinLock_return();

25 Iteration 0 (cont) bebop provides path p 0 = A → A → SLIC_ERROR newton determines that p 0 is infeasible in P’ and returns F 0 = {nPacketsOld = nPackets} as explanation – it must be both true and false on p 0 : do { KeAcquireSpinLock(); A: KeAcquireSpinLock_return(); nPacketsOld = nPackets; if (request) { request = request->Next; KeReleaseSpinLock(); B: KeReleaseSpinLock_return(); nPackets++; } } while (nPacketsOld != nPackets); KeReleaseSpinLock(); C: KeReleaseSpinLock_return();

26 Iteration 1 E 1 = {state = Locked, state = Unlocked, nPacketsOld = nPackets} BP(P’,E 1 ): decl {state=Unlocked}, {state=Locked}; {state=Unlocked} := T; {state=Locked} := F; void slic_abort() { SLIC_ERROR: skip; } void KeAcquireSpinLock_return { if ({state=Locked}) slic_abort(); else { {state=Locked} := T; {state=Unlocked} := F; } } void KeReleaseSpinLock_return { if ({state=Unlocked}) slic_abort(); else { {state = Unlocked} := T; {state = Locked} := F; } } do { skip; A: KeAcquireSpinLock_return(); b := T; if (*) { skip; B: KeReleaseSpinLock_return(); b := F; } } while (!b); skip; C: KeReleaseSpinLock_return();

27 Iteration 1 (cont) bebop establishes that SLIC_ERROR is unreachable in BP(P’,E 1 ) SLAM concludes that P ⊨ ϕ

28 Sources Logic in Computer Science – Modelling and Reasoning about Systems, 2 nd edition, Michael Huth & Mark Ryan, Cambridge University Press, Automatically Validating Temporal Safety Properties of Interfaces, T. Ball & S. K. Rajmani, SPIN 2001 Tutorial on "Software Model Checking with SLAM" at PLDI 2003