Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar Shaz Qadeer.

Slides:



Advertisements
Similar presentations
Dataflow Analysis for Datarace-Free Programs (ESOP 11) Arnab De Joint work with Deepak DSouza and Rupesh Nasre Indian Institute of Science, Bangalore.
Advertisements

Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
A Program Transformation For Faster Goal-Directed Search Akash Lal, Shaz Qadeer Microsoft Research.
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.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
1/20 Generalized Symbolic Execution for Model Checking and Testing Charngki PSWLAB Generalized Symbolic Execution for Model Checking and Testing.
Background for “KISS: Keep It Simple and Sequential” cs264 Ras Bodik spring 2005.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
Introducing BLAST Software Verification John Gallagher CS4117.
1 Thorough Static Analysis of Device Drivers Byron Cook – Microsoft Research Joint work with: Tom Ball, Vladimir Levin, Jakob Lichtenberg,
Software Verification with BLAST Tom Henzinger Ranjit Jhala Rupak Majumdar.
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.
SCIENCES USC INFORMATION INSTITUTE Pedro C. Diniz University of Southern California / Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina.
Iterative Context Bounding for Systematic Testing of Multithreaded Programs Madan Musuvathi Shaz Qadeer Microsoft Research.
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.
Termination Proofs for Systems Code Andrey Rybalchenko, EPFL/MPI joint work with Byron Cook, MSR and Andreas Podelski, MPI PLDI’2006, Ottawa.
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture # 11.
Permissive Interfaces Tom Henzinger Ranjit Jhala Rupak Majumdar.
Software Verification with Blast Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, George Necula, Grégoire Sutre, Wes Weimer UC Berkeley.
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.
Program Verification by Lazy Abstraction Ranjit Jhala UC San Diego Lecture 1 With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
Counterexample-Guided Focus TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAA A A A AA A A Thomas Wies Institute of.
Abstractions. Outline Informal intuition Why do we need abstraction? What is an abstraction and what is not an abstraction A framework for abstractions.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar [UC Berkeley] Shaz Qadeer [Microsoft Research]
Lazy Predicate Abstraction in BLAST John Gallagher CS4117.
Synergy: A New Algorithm for Property Checking
Speeding Up Dataflow Analysis Using Flow- Insensitive Pointer Analysis Stephen Adams, Tom Ball, Manuvir Das Sorin Lerner, Mark Seigle Westley Weimer Microsoft.
Counter Example Guided Refinement CEGAR Mooly Sagiv.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
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.
Software Verification with BLAST Tom Henzinger Ranjit Jhala Rupak Majumdar.
Thread-Modular Verification Shaz Qadeer Joint work with Cormac Flanagan Stephen Freund Shaz Qadeer Joint work with Cormac Flanagan Stephen Freund.
Lazy Abstraction Lecture 2: Modular Analyses Ranjit Jhala UC San Diego With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
Computing Over­Approximations with Bounded Model Checking Daniel Kroening ETH Zürich.
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.
Lazy Abstraction Lecture 3 : Partial Analysis Ranjit Jhala UC San Diego With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
Thread-modular Abstraction Refinement Thomas A. Henzinger, et al. CAV 2003 Seonggun Kim KAIST CS750b.
CSC2108 Lazy Abstraction on Software Model Checking Wai Sum Mong.
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
By: Pashootan Vaezipoor Path Invariant Simon Fraser University – Spring 09.
Lifecycle Verification of the NASA Ames K9 Rover Executive Dimitra Giannakopoulou Mike Lowry Corina Păsăreanu Rich Washington.
Survey on Trace Analyzer (2) Hong, Shin /34Survey on Trace Analyzer (2) KAIST.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
Symbolic Execution with Abstract Subsumption Checking Saswat Anand College of Computing, Georgia Institute of Technology Corina Păsăreanu QSS, NASA Ames.
Localization and Register Sharing for Predicate Abstraction Himanshu Jain Franjo Ivančić Aarti Gupta Malay Ganai.
11 Counter-Example Based Predicate Discovery in Predicate Abstraction Satyaki Das and David L. Dill Computer Systems Lab Stanford University
Detecting Atomicity Violations via Access Interleaving Invariants
Ranjit Jhala Rupak Majumdar Interprocedural Analysis of Asynchronous Programs.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
Specifying Multithreaded Java semantics for Program Verification Abhik Roychoudhury National University of Singapore (Joint work with Tulika Mitra)
Counter Example Guided Refinement CEGAR Mooly Sagiv.
#1 Having a BLAST with SLAM. #2 Software Model Checking via Counter-Example Guided Abstraction Refinement Topic: Software Model Checking via Counter-Example.
© Anvesh Komuravelli Spacer Model Checking with Proofs and Counterexamples Anvesh Komuravelli Carnegie Mellon University Joint work with Arie Gurfinkel,
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 8 Introduction to Modelling Concurrency John Gurd, Graham Riley Centre for.
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.
Formal methods: Lecture
Over-Approximating Boolean Programs with Unbounded Thread Creation
Amir Kamil and Katherine Yelick
Abstractions from Proofs
COMP60621 Designing for Parallelism
Predicate Abstraction
BLAST: A Software Verification Tool for C programs
Presentation transcript:

Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar Shaz Qadeer

Introduction Model Checking Software –“Automatic” –Path sensitive properties –Partial correctness –Limited to sequential programs Thread-modular Reasoning –Efficiently decompose checks –Requires manual (or divine) intervention TAR: Thread-modular Abstraction Refinement –Eliminate the divine using abstraction-refinement –Safety checking for concurrent programs

The story so far... Analyzing Sequential programs –BLAST/SLAM/… –Iterative Abstraction-Refinement YES SAFE explanation NO! (Trace) BUG feasible Seed Abstraction Program Why infeasible ? infeasible Refine Abstract Is model safe ? Check

… and what of Concurrent Programs ? Shared Memory (multithreaded) Message Passing Hard to analyze ! –Interleavings / State explosion One approach: Thread-modular analysis –a.k.a. “divide and conquer” –Analyse threads in isolation –Put analyses together

The Problem boxes = threads white denotes shared variables Safety checking: Is an ERROR state reachable ?

Thread-modular analysis (take1) safe

Thread-modular analysis (take1) safe Rarely happens ! Threads are only correct in a constrained environment

Second Attempt: Summaries Divine “summaries” of each thread’s behaviour Use/verify summaries (circular)

safe Use Summaries (“Assume”) safe

Verify Summaries (“Guarantee”) µ µ safe

Thread-modular analysis (take 2) µ safe µ

Our Contribution Problem with TM Reasoning: –Divining (small) summaries ! ? ? Algorithm TAR –Divine/use/verify summaries –Using iterative abstraction-refinement

An Example: Race Detection Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } Shared variables: data, flag, P, C Error states: P Æ C Initial states: : P Æ : C ( Æ : flag) P´P´ ´ C

An Example: Race Detection Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } P´P´ ´ C Correctness Invariant: –Producer ensures: P ) : flag –Consumer ensures: C ) flag

S Producer { : flag ! (flag’ Ç : flag’) Æ : P’ | : flag ! : flag’ Æ P’ } Summaries S Consumer { flag ! (flag’ Ç: flag’) Æ : C’ | flag ! flag’ Æ C’ } Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } Summary: Set of (present state, next state) pairs

Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } Checking Safety [use] Sequential program: Producer+ use BLAST/SLAM/ESC/… [verify] Every action of Producer+ is in S Producer Producer+{ 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } while(*){ s Consumer ();} safe µ

Abstraction & Reachability Abstraction gives finite state space Conservative – Abstraction safe ) System safe – Too coarse ) spurious counterexample Initial Error

Refinement Using “spurious” error traces

Refinement Using “spurious” error traces –Add information to rule out spurious trace –e.g. Track more variables or predicates Repeat reachability –Till safe or real trace is found

Abstraction & Reachability Using “spurious” error traces –Add information to rule out spurious trace –e.g. Track more variables or predicates Repeat reachability –Till safe or real trace is found safe

To Summarize Nodes labeled by abstract states Each parent-child pair ! (present, next) pair –Quantify out local state (e.g. program counter) –Take pairs where global state changes Reachability Tree ’

Producer+{ 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } while(*){ s Consumer ();} Tying up the threads ;; Refine using “spurious” error traces Not yet the reachable set! Summarize

Refined System ;; safe Fixpoint

Running TAR on Example Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } Shared variables: data, flag, P, C Error states: P Æ C Initial states: : P Æ : C Æ : flag P´P´ ´ C

; Summary: : P Æ : C ! : P’ Æ C’ : P Æ C ! : P’ Æ : C’ Running TAR 1 ; Init: : P Æ : C Error: P Æ C Abs: P, C Reach: : P Æ : C P Æ : C Reach: : P Æ : C : P Æ C Summary: : P Æ : C ! P’ Æ : C’ P Æ : C ! : P’ Æ : C’ Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } P Æ C P´P´ ´ C

Summary: C Æ flag ! : C’ Æ flag’ : C Æ flag ! : C’ Æ : flag’ ; Summary: Running TAR 2 ; Init: : P Æ : C Æ : flag Error: P Æ C Abs: P, C, flag Reach: : P Æ : C Æ : flag P Æ : C Æ : flag : P Æ : C Æ flag Reach: : P Æ : C Æ : flag Summary: : P Æ: flag ! P‘ Æ : flag’ ! : P’ Æ flag’ P Æ : flag ! : P Æ: flag Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } : P Æ C Æ flag : C Æ flag : C Æ : flag P´P´ ´ C Only change if : flag Only change if flag : P Fixpoint Track flag : flagflag

; Summary: flag ! ( flag’ Ç : flag’) Æ : C’ ! flag’ Æ C’ Running TAR 2 ; Reach: P Æ : C Æ : flag : P Reach: : P Æ C Æ flag : C Summary: : flag ! (flag’ Ç : flag’) Æ : P’ ! : flag Æ P’ Consumer { 1: while (*) { 2: while (!flag) {}; 3: read = data; 4: flag = false; } Producer { 1: while (*) { 2: while (flag) {}; 3: data = newdata(); 4: flag = true; } P´P´ ´ C safe Fixpoint SUMMARIES DIVINED !

Wrapping Up The moral: –TAR can check concurrent software –w/o (really) exploring all interleavings The devil … –Shared memory via pointers –Explicating local state Need to track some local state of “other” threads –Counterexample analysis Implemented TAR in BLAST –Race checking for drivers (each client is a thread) –Linux/Windows drivers 1-10 Kloc Looking for examples and properties …

BLAST Berkeley Lazy Abstraction Software * Tool

Race Detection w/ Pointers Producer { p = &buf; while (*) { while (p->flag) {}; p->data = newdata(); p->flag = true; p = p->next; } Consumer { q = &buf; while (*) { while (q->flag) {}; read = q->data; q->flag = false; q = q->next; }