Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley.

Slides:



Advertisements
Similar presentations
Model Checking Lecture 4. Outline 1 Specifications: logic vs. automata, linear vs. branching, safety vs. liveness 2 Graph algorithms for model checking.
Advertisements

Demand-driven inference of loop invariants in a theorem prover
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.
Verification of Evolving Software Natasha Sharygina Joint work with Sagar Chaki and Nishant Sinha Carnegie Mellon University.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
By Dirk Beyer, Alessandro Cimatti, Alberto Griggio, Erkan Keremoglu and Roberto Sebastiani Simon Fraser University (Spring 09) Presentation By: Pashootan.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Introducing BLAST Software Verification John Gallagher CS4117.
Software Verification with BLAST Tom Henzinger Ranjit Jhala Rupak Majumdar.
A survey of techniques for precise program slicing Komondoor V. Raghavan Indian Institute of Science, Bangalore.
Automatic Predicate Abstraction of C-Programs T. Ball, R. Majumdar T. Millstein, S. Rajamani.
Verification of parameterised systems
Symmetry-Aware Predicate Abstraction for Shared-Variable Concurrent Programs Alastair Donaldson, Alexander Kaiser, Daniel Kroening, and Thomas Wahl Computer.
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.
Software Verification via Refinement Checking Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.
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.
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.
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.
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.
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.
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.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Software Reliability Methods Sorin Lerner. Software reliability methods: issues What are the issues?
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.
Efficient Software Model Checking of Data Structure Properties Paul T. Darga Chandrasekhar Boyapati The University of Michigan.
Path Slicing Presentation by Massimiliano Menarini Ranjit Jhala and Rupak Majumdar, “Path Slicing” PLDI 05 (June 2005, Chicago, Illinois)
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.
Symbolic Path Simulation in Path-Sensitive Dataflow Analysis Hari Hampapuram Jason Yue Yang Manuvir Das Center for Software Excellence (CSE) Microsoft.
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.
CSC2108 Lazy Abstraction on Software Model Checking Wai Sum Mong.
50.530: Software Engineering
Program Analysis with Dynamic Change of Precision Dirk Beyer Tom Henzinger Grégory Théoduloz Presented by: Pashootan Vaezipoor Directed Reading ASE 2008.
Rule Checking SLAM Checking Temporal Properties of Software with Boolean Programs Thomas Ball, Sriram K. Rajamani Microsoft Research Presented by Okan.
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.
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.
1 Predicate Abstraction and Refinement for Verifying Hardware Designs Himanshu Jain Joint work with Daniel Kroening, Natasha Sharygina, Edmund M. Clarke.
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
The Yogi Project Software property checking via static analysis and testing Aditya V. Nori, Sriram K. Rajamani, Sai Deep Tetali, Aditya V. Thakur Microsoft.
Symbolic Algorithms for Infinite-state Systems Rupak Majumdar (UC Berkeley) Joint work with Luca de Alfaro (UC Santa Cruz) Thomas A. Henzinger (UC Berkeley)
Concrete Model Checking with Abstract Matching and Refinement Corina Păsăreanu QSS, NASA Ames Research Center Radek Pelánek Masaryk University, Brno, Czech.
1 Automatically Validating Temporal Safety Properties of Interfaces - Overview of SLAM Parts of the slides are from
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
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.
The software model checker BLAST Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar Presented by Yunho Kim TexPoint fonts used in EMF. Read.
Having a BLAST with SLAM
50.530: Software Engineering
Abstractions from Proofs
Program Verification by Lazy Abstraction
Abstraction, Verification & Refinement
Software Verification with BLAST
Predicate Abstraction
BLAST: A Software Verification Tool for C programs
Presentation transcript:

Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley

2 Motivation Verification of systems code Locking disciplines Interface specifications Essential for correct operation High rate of bugs Temporal properties Require path-sensitive analysis Swamped by false positives Really hard to check

3 Model Checking Doesn’t scale to low level implementations Can only model check “abstractions” Requires human intervention … Abstract – Check – Refine Loop Microsoft SLAM Project [Clarke et. al. 00], [Saidi 00]

4 Abstract-Check-Refine Loop Abstract Explanation YES (Trace) BUG Feasible ??? Check Refine NO SAFE Seed Abstraction Program Abstraction Infeasible Why infeasible ? Is model unsafe ?

5 Model Checking 101 ERROR STATES Init SYSTEM’S STATE SPACE Keep searching successors until … Hit error states: report “ bug ” ! Add no new successors: report “ safe ” Could take a long time …

6 Model Checking & Abstraction Problem: Far too many states Iterations don ’ t terminate ! Solution: Abstract … ERROR STATES Init

7 ERROR STATES Init Model Checking & Abstraction Problem: Abstraction too coarse Solution: Refine abstraction Make boxes smaller

8 ERROR STATES Init Model Checking & Abstraction Problem: Abstraction too coarse Solution: Refine abstraction Make boxes smaller

9 Abstract Only Where Required ERROR STATES Init Abstraction is very expensive Why abstract regions that are never visited ? Reachable States On-the-fly abstraction: driven by the search

10 Refine Only Where Required Why be precise everywhere ? Don ’ t refine error-free regions ERROR STATES Init ERROR FREE

11 Refine Only Where Required Why be precise everywhere ? Don ’ t refine error-free regions Different precision for different regions Local Refinement : driven by the search ERROR STATES Init ERROR FREE

12 How to improve Abstract only where required Reachable state space is very sparse Construct the abstraction on-the-fly Use greater precision only where required Different precisions/abstractions for different regions Refine locally Reuse work from earlier phases Batch-oriented ) lose work from previous runs Integrate the three phases Exploit control flow structure

13 Example Q: Is Error Reachable ? Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } unlock()lock() unlock()

14 Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } Example:CFA 1 3 lock(); old = new 2 7 [>][>][>][>] 4 5 [>][>] [>][>] unlock() new++ 6 [new==old] [new!=old] ret unlock()

15 Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } Example:CFA ret got_lock=0 [>][>] [>][>] lock(); got_lock++ [got_lock == 0] [got_lock != 0] unlock() [>][>] [>][>]

16 Example:CFA Q: Is Error Reachable ? Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } ret unlock()lock() unlock()

17 Step 1: Search Set of predicates: LOCK=0, LOCK=1 1 LOCK=0 2 4 LOCK=1 6 LOCK=0 [>][>] lock(); old = new [>][>] unlock() new++ [new==old] unlock() ret 5 LOCK=0 3 LOCK=1 Err LOCK=0

18 Q: When can: Step 2: Analyze Counterexample 1 LOCK=0 2 3 LOCK=1 4 5 LOCK=0 6 Err LOCK= ret n Err ops States that can = wp( >,ops) States at node n = R n ) check: R n Æ wp( >,ops) = ? ?

19 Step 2: Analyze Counterexample 1 LOCK=0 2 3 LOCK=1 4 5 LOCK=0 6 Err LOCK=0 lock(); old = new [>][>] unlock(); new++ [new==old] unlock() LOCK=0 LOCK=0 Æ new = old LOCK=0 Æ new+1 = new LOCK=1 Æ new+1 = old ret R n Æ wp (>,ops) = ? ?

20 Step 2: Analyze Counterexample 1 LOCK=0 2 3 LOCK=1 4 5 LOCK=0 6 Err LOCK=0 lock(); old = new [>][>] unlock(); new++ [new==old] unlock() LOCK=0 LOCK=0 Æ new = old LOCK=0 Æ new+1 = new LOCK=1 Æ new+1 = old ret Track the predicate: new = old

21 Step 3: Resume search 1 LOCK=0 2 4 LOCK=1 Æ new = old lock(); old = new [>][>] unlock() new++ [new==old] ? 6 [new!=old] 2 LOCK=0 Æ : new = old µ LOCK =0 Set of predicates: LOCK=0, LOCK=1 New predicate: new = old, ret 5 LOCK=0 Æ : new = old 3 LOCK=1 Æ new = old

22 Step 3: Resume search 1 LOCK=0 2 3 LOCK=1 Æ new = old 4 5 LOCK=0 Æ : new = old ? 62 LOCK=0 Æ : new = old [>][>] 5 LOCK=1 Æ new=old 6 [new==old] [new!=old] 1 ? unlock() ret Set of predicates: LOCK=0, LOCK=1 New predicate: new = old ret LOCK=0Æ new=old

23 Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } Example:CFA ret got_lock=0 [>][>] [>][>] lock(); got_lock++ [got_lock == 0] [got_lock != 0] unlock() [>][>] [>][>]

24 Step 4: Search Right Branch 1 LOCK=0 [>][>] 2 7 [>][>] Err ret Set of predicates: LOCK=0, LOCK=1 New predicate: (from trace) got_lock = 0

25 Leaves Covered (Reuse work) 1 LOCK= LOCK=0 Æ … COVERED ! Leaves covered: Avoid repeating search when paths merge ret

26 Different Abstractions got_lock = 0new = old Different predicates for different parts of state space Local refinement: Preserves work on left tree ret

27 Predicate Discovery Information lost in substitution Keep substitutions explicit Ask a proof of unsatisfiability Pick predicates appearing in proof 2 LOCK=0 3 LOCK=1 4 5 LOCK=0 6 Err LOCK=0 lock(); old = new [>][>] unlock(); new++ [new==old] unlock() LOCK=0 Æ new+1 = new

28 New Predicates from proof of unsatisfiability old’ = new, new’ = old’, new’ = new + 1 Predicate Discovery Weakest Precondition: wp( , x=e) ´  [e/x] Explicit WP: wp( , x=e) ´ 9 x’. x’ = e Æ  [x’/x] LOCK = 0 Æ 9 old’ new’ LOCK’. old’ = new Æ LOCK’=0 Æ new’ = old’ Æ new’ = new’ LOCK=0 3 LOCK=1 4 5 LOCK=0 6 Err LOCK=0 lock(); old = new [>][>] unlock(); new++ [new==old] unlock() LOCK=0 Æ new+1 = new

29 Lazy abstraction For any system, require: Region representation Boolean operations: [, Å, : “Covering” check: µ post # : Region ! Approx. succ. Region Forward Search pre: Region ! Exact pred. Region Backward counterexample analysis focus : why a trace is infeasible

30 BLAST LAZY ABSTRACTION Berkeley Lazy Abstraction Software verification Tool 10K Lines of Ocaml Analyze Linux/Windows Device Drivers CIL (C ! CFA) REGION STRUCTURE BDD Engine (Boolean ops) Simplify (Post # ) Vampyre (focus)

31 Experiments [Not in POPL paper] Linux Device Drivers (Locking protocol) Windows Drivers (IRP Spec – 22 states) ProgramLinesPredicatesTime ide.c ½ min aironet.c min aha152x.c sec ProgramLinesPredicatesTime floppy.c min kbfiltr.c sec

32 Why Abstract Lazily ? Reach set is very sparse Abstract on-the-fly Only the reachable region Requires very fast post # Exploit Control-Flow Structure Free partitioning of state space Partition preds: different abstractions Refine locally: don ’ t repeat old work

33 Problems/Future work Monolithic vs. Multi-model abstractions How to partition predicates ? Predicate-flow analyses ? Recursion Summaries tricky with on-the-fly search Smarter abstractions Heap data structures ?

34 Predicate Abstraction P 1 : x = y P 3 : x  z+1 P 2 : z = t + y P 4 : * u = x Karnaugh Map :P1,:P2:P1,:P2 P 1, P 2 P 1, : P 2 : P 1, P 2 :P3:P4:P3:P4 :P3P4:P3P4 P3P4P3P4 P3:P4P3:P4 Set of states Abstract Set: P 1 P 2 P 4 Ç : P 1 P 2 P 3 P 4 Region Representation: formulas over predicates

35 Predicate Abstraction Box: abstract variable valuation BoxCover(S): Set of boxes covering S Theorem prover used to compute BoxCover P 1 : x = y P 3 : x  z+1 P 2 : z = t + y P 4 : * u = x Karnaugh Map :P1,:P2:P1,:P2 P 1, P 2 P 1, : P 2 : P 1, P 2 :P3:P4:P3:P4 :P3P4:P3P4 P3P4P3P4 P3:P4P3:P4

36 Post #, Pre pre(S,op) = { s | 9 s ’ 2 S. s ! op s ’ } ( Weakest Precondition ) post(S,op) = { s | 9 s ’ 2 S. s ’ ! op s} ( Strongest Postcondition ) Abstract Operators: post # post(S,op) µ post # (S,op) Concrete Operators: pre Classical Weakest Precondition :P1,:P2:P1,:P2 P 1, P 2 P 1, : P 2 : P 1, P 2 :P3:P4:P3:P4 :P3P4:P3P4 P3P4P3P4 P3:P4P3:P4 S post post(S) post # (S)

37 Predicate Abstraction in SLAM Abstraction: Boolean Programs (C2BP) Boolean variable for each predicate C program  Boolean program Model checker: Bebop Refine: Newton Extracts new predicates from error trace Start afresh with new abstraction Can we do better ? Reuse work from earlier phases Abstract only where required Use additional predicates only where required Abstract Check Refine

38 Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } Example Unrelated Code: Critical Sections etc.

39 Example: Specification lock (){ if (LOCK == 0){ LOCK = 1; } else { ERROR } unlock (){ if (LOCK == 1){ LOCK = 0; } else { ERROR } Q: Is Error Reachable ? Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; }

40 Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } Example:CFA ret got_lock=0 [>][>] [>][>] lock(); got_lock++ [get_lock == 0] [get_lock != 0] unlock() [>][>] [>][>]

41 Example:CFA ret Q: Is Error Reachable ? lock (){ if (LOCK == 0){ LOCK = 1; } else { ERROR } unlock (){ if (LOCK == 1){ LOCK = 0; } else { ERROR } Example ( ) { 1: if (*) { 7: do { got_lock = 0; 8: if (*) { 9: lock(); got_lock ++; } 10: if (got_lock) { 11: unlock(); } 12: } while (*) ; } 2: do { lock(); old = new; 3: if (*) { 4: unlock(); new ++; } 5: } while ( new != old); 6: unlock (); return; } unlock()lock() unlock()

42 Model Checking Doesn’t scale to low level implementations Abstract – Check – Refine Loop Microsoft SLAM Project [Clarke et. al. 00], [Saidi 00] Abstraction is expensive ! Abstract only if/where required Different abstractions for different parts of system Reuse work from previous iterations Lazy abstraction: Short circuits the loop Avoids repeating work Abstractions computed locally, if/where required

43 Can We Do Better ? Abstract only where required Reachable state space is very sparse Use greater precision only where required Different precisions/abstractions for different regions Reuse work from earlier phases Batch-oriented ) lose work from previous runs Don ’ t repeat search in error-free regions

44 Our proposal Integrate the three phases Construct the abstraction on-the-fly Driven by the reachability search Refine the abstraction on demand Refine locally

45 Outline Motivation The verification loop An example The Lazy abstraction algorithm BLAST Conclusions

46 Outline Motivation The verification loop An example The Lazy abstraction algorithm BLAST Conclusions

47 Outline Motivation The verification loop An example The lazy abstraction algorithm For sequential code Blast Conclusions

48 Outline Motivation The verification loop An example The lazy abstraction algorithm For sequential code Blast Conclusions

49 1: Forward Search post # µ

50 2: Counterexample Analysis pre, Å

51 Untouched 3: Refine Refinement Focus

52 A complication Refinement Uncovered!

53 Model Checking & Abstraction Problem: Abstraction too coarse Solution: Refine abstraction Make boxes smaller