Abstraction, Verification & Refinement

Slides:



Advertisements
Similar presentations
Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.
Advertisements

Abstraction of Source Code (from Bandera lectures and talks)
Greta YorshEran YahavMartin Vechev IBM Research. { ……………… …… …………………. ……………………. ………………………… } P1() Challenge: Correct and Efficient Synchronization { ……………………………
Greta YorshEran YahavMartin Vechev IBM Research. { ……………… …… …………………. ……………………. ………………………… } T1() Challenge: Correct and Efficient Synchronization { ……………………………
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:
An Introduction to the Model Verifier verds Wenhui Zhang September 15 th, 2010.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Hybrid System Verification Synchronous Workshop 2003 A New Verification Algorithm for Planar Differential Inclusions Gordon Pace University of Malta December.
The LC-3 – Chapter 6 COMP 2620 Dr. James Money COMP
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Software Verification with BLAST Tom Henzinger Ranjit Jhala Rupak Majumdar.
BLAST-A Model Checker for C Developed by Thomas A. Henzinger (EPFL) Rupak Majumdar (UC Los Angeles) Ranjit Jhala (UC San Diego) Dirk Beyer (Simon Fraser.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Weizmann Institute Deciding equality formulas by small domain instantiations O. Shtrichman The Weizmann Institute Joint work with A.Pnueli, Y.Rodeh, M.Siegel.
Software Verification with Blast Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, George Necula, Grégoire Sutre, Wes Weimer UC Berkeley.
1 Model Checking, Abstraction- Refinement, and Their Implementation Based on slides by: Orna Grumberg Presented by: Yael Meller June 2008.
Scalable Program Verification by Lazy Abstraction Ranjit Jhala U.C. Berkeley.
Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley.
28/6/05 ICFI05 1 A generic approach for the automatic verification of featured, parameterised systems Alice Miller and Muffy Calder University of Glasgow.
Program Verification by Lazy Abstraction Ranjit Jhala UC San Diego Lecture 1 With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
Program analysis Mooly Sagiv html://
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.
Speeding Up Dataflow Analysis Using Flow- Insensitive Pointer Analysis Stephen Adams, Tom Ball, Manuvir Das Sorin Lerner, Mark Seigle Westley Weimer Microsoft.
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
Program analysis Mooly Sagiv html://
Predicate Abstraction for Software and Hardware Verification Himanshu Jain Model checking seminar April 22, 2005.
Temporal-Safety Proofs for Systems Code Thomas A. Henzinger Ranjit Jhala Rupak Majumdar George Necula Westley Weimer Grégoire Sutre UC Berkeley.
Lazy Abstraction with Interpolants Yakir Vizel (based on the work and slides of K. L. McMillan at CAV06)
Software Verification with BLAST Tom Henzinger Ranjit Jhala Rupak Majumdar.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Lazy Abstraction Lecture 3 : Partial Analysis Ranjit Jhala UC San Diego With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
Program Verification by Lazy Abstraction Ranjit Jhala UC San Diego Lecture 1 With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre, Adam Chlipala.
Thread-modular Abstraction Refinement Thomas A. Henzinger, et al. CAV 2003 Seonggun Kim KAIST CS750b.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Verifying Concurrent Message- Passing C Programs with Recursive Calls Sagar Chaki, Edmund Clarke, Nicholas Kidd, Thomas Reps, and Tayssir Touili.
By: Pashootan Vaezipoor Path Invariant Simon Fraser University – Spring 09.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 3: Modular Verification with Magic, Predicate Abstraction.
Introduction to Algorithms By Mr. Venkatadri. M. Two Phases of Programming A typical programming task can be divided into two phases: Problem solving.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
1 Bisimulations as a Technique for State Space Reductions.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
Model construction and verification for dynamic programming languages Radu Iosif
Convergence of Model Checking & Program Analysis Philippe Giabbanelli CMPT 894 – Spring 2008.
Symbolic Execution with Abstract Subsumption Checking Saswat Anand College of Computing, Georgia Institute of Technology Corina Păsăreanu QSS, NASA Ames.
Formal Verification of Synchronization Issues of SpecC Description with Automatic Abstraction Thanyapat Sakunkonchak Masahiro Fujita Department of Electronics.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
#1 Having a BLAST with SLAM. #2 Software Model Checking via Counter-Example Guided Abstraction Refinement Topic: Software Model Checking via Counter-Example.
Abstraction and Abstract Interpretation. Abstraction (a simplified view) Abstraction is an effective tool in verification Given a transition system, we.
Counterexample-Guided Abstraction Refinement By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith Presented by Yunho Kim Provable Software.
The software model checker BLAST Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar Presented by Yunho Kim TexPoint fonts used in EMF. Read.
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Having a BLAST with SLAM
Model Checking Java Programs (Java PathFinder)
Abstraction of Source Code
Abstraction Data type based abstractions
Software Model Checking
Automatic Verification
Property Directed Reachability with Word-Level Abstraction
Over-Approximating Boolean Programs with Unbounded Thread Creation
Discrete Controller Synthesis
50.530: Software Engineering
Abstractions from Proofs
Program Verification by Lazy Abstraction
The Zoo of Software Security Techniques
Software Verification with BLAST
Predicate Abstraction
Course: CS60030 Formal Systems
Presentation transcript:

Abstraction, Verification & Refinement Samik Basu Dept. of Computer Science, ISU

What is Model Checking Model Checking (Design level) Generate a model describing the behavior (M) Essentially a graph Identify the desired properties () Automatically verify (M ² ) Graph-traversal

Model Checking Source Code Why? Difficult: Programs are more complex Variables, conditionals, recursion

Acknowledgement Abstraction-based techniques Blast (Berkeley), Slam (MS), CEGAR (CMU), FocusCheck (SBU, ISU)

Safety Property Bad things never happen Typical “Bad” things: valuations of variables

Question? Is there a path in the program that leads to satisfaction of Bad? Counter-Example

Example Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4: } while(new != old); 5: unlock (); return; lock unlock

What is a Program-Graph? State Transition pc lock old new q  3   5  0x133a 3: unlock(); new++; 4:} … pc lock old new q  4   5  6  0x133a Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4: } while(new != old); 5: unlock (); return;}

What is infinite about programs? Program state Control Location: finite Variable value: infinite Question: Prove that for all possible values of variables, the program behaves correctly

Abstraction Over-approximation M’ ²  ) M ²  where  = Bad Remove details and partition states Graph over partitions: finite and manageable M’ M’ contains all behavior of M and more M’ ²  ) M ²  where  = Bad

Data Abstraction x:int y:int Even Odd …, -2, 0, 2, 4, … …, -3, -1, 1, 3, … Pos Neg Zero …, -3, -2, -1 y:int 1, 2, 3, …

Abstract Program Code Abstract Data domain int x = 0; if (x == 0) x = x + 1; (n<0) : NEG (n==0): ZERO (n>0) : POS Signs NEG POS ZERO Signs x = ZERO; if (x == ZERO) x = x + POS; we transform the code so that to operate on the abs domain and it looks like this; here the concrete type int was replaced by abs type signs, concrete constants 0 and 1 were replaced with abs ct 0 and pos; and primitive ops on ints were replaced with calls to some methods that implement the abs.ops.that manipulate abstract values. Ex : equality operator was replaced with a call to method signs.eq and + was replace by signs.add . So, how do we apply this abstraction technique to the DEOS example ? We have to decide which variables to abstract, what abstrations to use and then we have to effectively transform the system to encode the abstractions. Abstract the data domain = Abstract the Program behavior

Abstraction leads to Over-approximation h I M’

Abstraction leads to Over-approximation M’ > M, M’ ²  implies M ²  No False Positives Problem: Spurious Counter-Examples M h I M’

Predicate Abstraction Look at characteristic of data NOT its exact valuation Predicate Abstraction Relationship between variables and constants

Spurious Counter-Example h I M’

Spurious Counter-Example h I M’

Break it up and Start over M h I M’

Summary Abstract Model Check Refine if needed Loop-back Blast, Slam (CFG), FocusCheck (PDS)

Build-and-Search Reachability Tree Predicates: LOCK 1 1 Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 1 Reachability Tree

Build-and-Search Reachability Tree Predicates: LOCK 1 2 1 2 Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); lock() old = new q=q->next 1 : LOCK 2 LOCK 1 2 Reachability Tree

Build-and-Search Reachability Tree Predicates: LOCK 1 2 3 1 2 3 Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK [q!=NULL] 3 LOCK 1 2 3 Reachability Tree

Build-and-Search Reachability Tree Predicates: LOCK 1 2 3 4 4 1 2 3 Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK 3 q->data = new unlock() new++ LOCK 4 : LOCK 4 1 2 3 Reachability Tree

Build-and-Search Reachability Tree Predicates: LOCK 1 2 3 4 5 5 4 1 2 Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK 3 LOCK 4 : LOCK 5 [new==old] 5 : LOCK 4 1 2 3 Reachability Tree

Build-and-Search Reachability Tree Predicates: LOCK 1 2 3 4 5 5 4 1 2 Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK 3 LOCK 4 : LOCK 5 5 : LOCK 4 unlock() 1 2 3 : LOCK Reachability Tree

Analyze Counterexample Predicates: LOCK Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK lock() old = new q=q->next 2 LOCK [q!=NULL] 3 LOCK q->data = new unlock() new++ 4 : LOCK 5 [new==old] 5 : LOCK 4 unlock() 1 2 3 : LOCK Reachability Tree

Analyze Counterexample Predicates: LOCK Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK old = new 2 LOCK 3 LOCK new++ 4 : LOCK 5 [new==old] 5 : LOCK 4 Inconsistent 1 2 3 : LOCK new == old Reachability Tree

Repeat Build-and-Search Predicates: LOCK, new==old Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 1 Reachability Tree

Repeat Build-and-Search Predicates: LOCK, new==old Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK lock() old = new q=q->next 2 LOCK , new==old 1 2 Reachability Tree

Repeat Build-and-Search Predicates: LOCK, new==old Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK , new==old LOCK , new==old 3 q->data = new unlock() new++ 4 : LOCK , : new = old 4 1 2 3 Reachability Tree

Repeat Build-and-Search Predicates: LOCK, new==old Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK , new==old LOCK , new==old 3 4 : LOCK , : new = old [new==old] 4 1 2 3 Reachability Tree

Repeat Build-and-Search Predicates: LOCK, new==old Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK , new==old LOCK , new==old 3 4 : LOCK , : new = old [new!=old] 1 4 4 1 : LOCK, : new == old 2 3 Reachability Tree

Repeat Build-and-Search Predicates: LOCK, new==old Example ( ) { 1: do{ lock(); old = new; q = q->next; 2: if (q != NULL){ 3: q->data = new; unlock(); new ++; } 4:}while(new != old); 5: unlock (); 1 : LOCK 2 LOCK , new==old SAFE LOCK , new==old 3 4 4 : LOCK , : new = old LOCK , new=old 5 1 5 4 4 4 1 : LOCK, : new == old 2 3 : LOCK , new==old Reachability Tree