Software Verification with Blast Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, George Necula, Grégoire Sutre, Wes Weimer 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

The SLAM Project: Debugging System Software via Static Analysis
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.
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.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
Lecture #21 Software Model Checking: predicate abstraction Thomas Ball Testing, Verification and Measurement Microsoft Research.
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.
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.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar Shaz Qadeer.
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.
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.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar [UC Berkeley] Shaz Qadeer [Microsoft Research]
Program analysis Mooly Sagiv html://
Lazy Predicate Abstraction in BLAST John Gallagher CS4117.
Synergy: A New Algorithm for Property Checking
SLAM Over the Summer Wes Weimer (Tom Ball, Sriram Rajamani, Manuvir Das)
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:
Program analysis Mooly Sagiv html://
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.
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.
Program Verification by Lazy Abstraction Ranjit Jhala UC San Diego Lecture 1 With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre, Adam Chlipala.
By D. Beyer et. al. Simon Fraser University (Spring 09) Presentation By: Pashootan Vaezipoor.
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
By: Pashootan Vaezipoor Path Invariant Simon Fraser University – Spring 09.
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.
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.
SMT and Its Application in Software Verification (Part II) Yu-Fang Chen IIS, Academia Sinica Based on the slides of Barrett, Sanjit, Kroening, Rummer,
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.
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
The Zoo of Software Security Techniques
Software Verification with BLAST
Predicate Abstraction
BLAST: A Software Verification Tool for C programs
Presentation transcript:

Software Verification with Blast Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, George Necula, Grégoire Sutre, Wes Weimer 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 Abstraction is very expensive Why abstract regions that are never visited ? Init 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 Reachability Tree 1 LOCK=0 2 3 LOCK=1 Æ new = old 4 5 LOCK=0 Æ : new = old ? 62 5 LOCK=1 Æ new=old 6 1 ? ret LOCK=0Æ new=old LOCK= LOCK=0 Æ got_lock=0 LOCK=1 Æ got_lock!=0 LOCK=0 Æ got_lock=0 ? ?

28 Invariants 1 LOCK=0 2 3 LOCK=1 Æ new = old 4 5 LOCK=0 Æ : new = old ? 62 5 LOCK=1 Æ new=old 6 1 ? ret LOCK=0Æ new=old Regions in the tree are invariants: Invariant Inv (n) for node n = Disjunction of all node-n regions in the tree Inv (5) is: LOCK=0 Æ : new = old Ç LOCK=1 Æ new=old Inv (6) is: LOCK=1 Æ new=old

29 Proof Generation ret LOCK=0 Æ : new = old Ç LOCK=1 Æ new=old [new==old] [new!=old] Use the invariants from the tree Verification Conditions for correctness 1.Pre ) Inv (1) 2.Inv (e) = false for error node e 3.Post (Inv (j), c jk ) ) Inv (k) These can be formalized as in PCC 1.Inv (1) contains Pre as disjunct 2.Error node not in tree

30 Proof Generation II ret LOCK=0 Æ : new = old Ç LOCK=1 Æ new=old [new==old] [new!=old] Prove : Post ( Inv (i), c ij ) ) Inv (j) Use the tree to break the proof: Post(AÇ B, c) ) D Ç E becomes: Post (A,c) ) D and Post (B,c) ) E Example: Post (Inv (5), new==old) ) Inv (6) LOCK=1 Æ new=old Post (LOCK=0 Æ : new=old, new==old) ) LOCK=1Æ new=old Post(LOCK=1 Æ new=old, new==old) ) LOCK=1 Æ new=old

31 Proof Generation II ret LOCK=0 Æ : new = old Ç LOCK=1 Æ new=old [new==old] [new!=old] Prove : Post ( Inv (i), c ij ) ) Inv (j) Use the tree to break the proof: Post(AÇ B, c) ) D Ç E becomes: Post (A,c) ) D and Post (B,c) ) E But these were computed in the forward search! Example: Post (Inv (5), new==old) ) Inv (6) LOCK=1 Æ new=old false ) LOCK=1Æ new=old LOCK=1 Æ new=old) LOCK=1 Æ new=old

32 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

33 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) Proof Gen (PCC)

34 MPR3 CallDriver MPR completion synch not pending returned SKIP2 IPC CallDriver Skip return child status DC Complete request return not Pend PPC prop completion CallDriver N/A no prop completion CallDriver start NP return Pending NP MPR1 MPR completion SKIP2 IPC CallDriver DC Complete request PPC prop completion CallDriver N?A no prop completion CallDriver start P Mark Pending IRP accessible N/A synch SKIP1 CallDriver SKIP1 Skip MPR2 MPR1 NP MPR3 CallDriver not pending returned MPR2 synch From the SLAM project

35 Experiments Windows Drivers (IRP Spec – 22 states) ProgramLinesPredicatesTimeProof floppy.c min min60K parport.c min103K mouclass.c min cdaudio.c min156K kbfiltr.c min sec7K

36 Experiments : Linux Locking ProgramLinesPredicatesTimeProof ide.c sec253 aironet.c min aha152x.c sec tlan.c min405

37 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

38 Problems/Future work Engineering Issues Program analysis Partitioning by partial evaluation Theory of counterexample driven refinement for all linear and branching time logics

39 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

40 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

41 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)

42 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

43 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

44 “ BLAST! This is why I hate flying! ” - Jedi Master Obi-Wan Kenobi in Episode II: Attack of the Clones, 2002