Counter Example Guided Refinement CEGAR Mooly Sagiv.

Slides:



Advertisements
Similar presentations
A SAT characterization of boolean-program correctness K. Rustan M. Leino Microsoft Research, Redmond, WA 14 Nov 2002 IFIP WG 2.4 meeting, Schloβ Dagstuhl,
Advertisements

Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
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.
Proofs and Counterexamples Rupak Majumdar. In the good old days… Decision Procedure  yes no.
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.
SAT and Model Checking. Bounded Model Checking (BMC) A.I. Planning problems: can we reach a desired state in k steps? Verification of safety properties:
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.
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.
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.
Scalable Error Detection using Boolean Satisfiability 1 Yichen Xie and Alex Aiken Stanford University.
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://
Purity Analysis : Abstract Interpretation Formulation Ravichandhran Madhavan, G. Ramalingam, Kapil Vaswani Microsoft Research, India.
Lazy Predicate Abstraction in BLAST John Gallagher CS4117.
Synergy: A New Algorithm for Property Checking
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.
Abstract Interpretation Part I Mooly Sagiv Textbook: Chapter 4.
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.
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.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
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.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
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.
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.
Aditya V. Nori, Sriram K. Rajamani Microsoft Research India.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Predicate Abstraction of ANSI-C Programs Using SAT By Edmund Clarke, Daniel Kroening, Natalia Sharygina, Karen Yorav Presented by Yunho Kim Provable Software.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball, Sriram K. MSR Presented by Xin Li.
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.
Verification of Synchronization in SpecC Description with the Use of Difference Decision Diagrams Thanyapat Sakunkonchak Masahiro Fujita Department of.
Synergy: A New Algorithm for Property Checking Bhargav S. Gulavani (IIT Bombay)‏ Yamini Kannan (Microsoft Research India)‏ Thomas A. Henzinger (EPFL)‏
Ranjit Jhala Rupak Majumdar Interprocedural Analysis of Asynchronous Programs.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
Counter Example Guided Refinement CEGAR Mooly Sagiv.
Finding bugs with a constraint solver daniel jackson. mandana vaziri mit laboratory for computer science issta 2000.
#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,
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
Symbolic Implementation of the Best Transformer
Over-Approximating Boolean Programs with Unbounded Thread Creation
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:

Counter Example Guided Refinement CEGAR Mooly Sagiv

Recap Many abstract domains –Signs –Odd/Even –Constant propagation –Intervals –[Polyhedra] –Canonic abstraction –Domain constructors –… Static Algorithms –Iterative Chaotic Iterations –Widening/Narrowing –Interprocedural Analysis –Concurrency –Modularity –Non-Iterative methods

A Lattice of Abstractions Every element is an abstract domain A  A’ if there exists a Galois Connection from A to A’

But how to find the appropriate abstract domain Precision vs. Scalability Sometimes precision improves scalability Specialize the abstraction for the desired property

Counter Example Guided Refinement (CEGAR) Run the analysis with a simple abstract domain When the analysis verifies the property declare done If the analysis reports an error employs a theorem prover to identify if the error is feasible –If the error is feasible generate a concrete trace –If the error is spurious refine the abstract domain and repeat

A Simple Example z =5 if (y >0) x = z; else x = -y; assert x >0 y > 0 x = zx = -y assert x >0 z = 5 sign(x)[x  ] T F [x  P] [x  ]

A Simple Example z =5 if (y >0) x = z; else x = -y; assert x >0 y > 0 x = zx = -y assert x >0 z = 5 sign(x), sign(y)[x , y  ] TF [x , y  P] [x , y  N] [x , y  P][x  P, y  N] [x , y  ]

A Simple Example z =5 if (y >0) x = z; else x = -y; assert x >0 y > 0 x = zx = -y assert x >0 z = 5 sign(x), sign(y), sign(z)[x , y , z  ] [x , y , z  P ] TF [x , y  P, z  P ] [x , y  N, z  P ] [x  P, y  P, z  P ] [x  P, y  N, z  P ] [x  P, y , z  P ]

Simple Example (local abstractions) z =5 if (y >0) x = z; else x = -y; assert x >0 y > 0 x = zx = -y assert x >0 z = 5 sign(x), sign(y), sign(z)[x , y , z  ] [x , y , z  P ] TF [x , y  P, z  P] [x , y  N, z  ] [x  P, y , z  ]

Plan CEGAR in BLAST (inspired by SLAM) POPL’04 Limitations

Abstractions from Proofs Thomas A. Henzinger Ranjit Jhala [UC Berkeley] Rupak Majumdar [UC Los Angeles] Kenneth L. McMillan [Cadence Berkeley Labs]

Scalable Program Verification Little theorems about big programs –Partial Specifications Device drivers use kernel API correctly Applications use root privileges correctly –Behavioral, path-sensitive properties

Predicate Abstraction: A crash course Initial Error Program State Space Abstraction Abstraction: Predicates on program state –Signs: x > 0 –Aliasing:&x  &y States satisfying the same predicates are equivalent –Merged into single abstract state

(Predicate) Abstraction: A crash course Initial Error Program State Space Abstraction Q1: Which predicates are required to verify a property ?

The Predicate Abstraction Domain Fixed set of predicates Pred The relational domain is –Join is set union –State space explosion Special case of canonic abstraction

Scalability vs. Verification Many predicates tracked –e.g. values of variables State explosion –Analysis drowned in detail scalability verification Few predicates tracked –e.g. type of variables Imprecision hinders Verification –Spurious counterexamples

Example while(*){ 1: if (p 1 ) lock(); if (p 1 ) unlock(); … 2: if (p 2 ) lock(); if (p 2 ) unlock(); … n: if (p n ) lock(); if (p n ) unlock(); } Only track lock Bogus Counterexample –Must correlate branches scalability lock unlock Predicate p 1 makes trace abstractly infeasible p i required for verification TFTTFT

Example while(*){ 1: if (p 1 ) lock(); if (p 1 ) unlock(); … 2: if (p 2 ) lock(); if (p 2 ) unlock(); … n: if (p n ) lock(); if (p n ) unlock(); } Only track lock Bogus Counterexample –Must correlate branches scalability lock unlock Track lock, p i s State Explosion – > 2 n distinct states –intractable verification How can we get scalable verification ?

By Localizing Precision while (*) { 1: if (p 1 ) lock(); if (p 1 ) unlock(); … 2: if (p 2 ) lock(); if (p 2 ) unlock(); … n: if (p n ) lock(); if (p n ) unlock(); } p1p1 p2p2 pnpn Preds. Used locally Ex: 2 £ n states Preds. used globally Ex: 2 n states Q2: Where are the predicates required ?

[Clarke et al. ’00] [Ball, Rajamani ’01] Counterexample Guided Refinement YES SAFE explanation NO! (Trace) BUG feasible Seed Abstraction Program Why infeasible ? Refine Abstract Is model safe ? Check 1.What predicates remove trace ? Make it abstractly infeasible 2.Where are predicates needed ? [Kurshan et al. ’93] explanation Why infeasible ?

Counterexample Guided Refinement YES SAFE explanation NO! (Trace) BUG feasible Seed Abstraction Program Why infeasible ? Refine Abstract Is model safe ? Check

Counterexample Guided Refinement YES SAFE explanation NO! (Trace) BUG feasible Seed Abstraction Program Why infeasible ? Refine Abstract Is model safe ? Check safe

This Talk: Counterexample Analysis YES SAFE explanation NO! (Trace) BUG feasible Seed Abstraction Program Why infeasible ? Refine Abstract Is model safe ? Check 1.What predicates remove trace ? Make it abstractly infeasible 2.Where are predicates needed ?

Plan 1.Motivation 2.Refinement using Traces Simple Procedure calls 3.Results

Trace Formulas A single abstract trace represents infinite number of traces –Different loop iterations –Different concrete values Solution –Only considers concrete traces with the same number of executions –Use formulas to represent sets of states

Representing States as Formulas [F] states satisfying F {s | s ² F } F FO fmla over prog. vars [F 1 ] Å [F 2 ]F1 Æ F2F1 Æ F2 [F 1 ] [ [F 2 ]F 1 Ç F 2 [F][F] : F [F 1 ] µ [F 2 ]F 1 implies F 2 i.e. F 1 Æ: F 2 unsatisfiable

Counterexample Analysis Refine Trace Feasible Explanation of Infeasibility Q2: Where are preds required ? Q1: What predicates remove trace ? Q0: Is trace feasible ? SSA Trace Feasibility Formula Trace Feasible Thm Pvr Y Proof of Unsat. N Extract Predicate Map: Prog Ctr ! Predicates

Q2: Where are preds required ? Q1: What predicates remove trace ? Q0: Is trace feasible ? Counterexample Analysis Refine Trace Feasible Explanation of Infeasibility SSA Trace Feasible Proof of Unsat. Extract Predicate Map: Prog Ctr ! Predicates Thm Pvr Y N Trace Feasibility Formula

Traces pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) y = x +1 pc 1 : x = ctr; pc 2 : ctr = ctr + 1; pc 3 : y = ctr; pc 4 : if (x = i-1){ pc 5 : if (y != i){ ERROR: } }

Trace Feasibility Formulas pc 1 : x = ctr pc 2 : ctr = ctr+1 pc 3 : y = ctr pc 4 : assume(x=i-1) pc 5 : assume(y  i) TraceSSA Trace x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 pc 1 : x 1 = ctr 0 pc 2 : ctr 1 = ctr 0 +1 pc 3 : y 1 = ctr 1 pc 4 : assume(x 1 =i 0 -1) pc 5 : assume(y 1  i 0 ) Trace Feasibility Formula Theorem: Trace is Feasible, TFF is Satisfiable Compact Verification Conditions [Flanagan,Saxe ’00]

Q2: Where are preds required ? Q1: What predicates remove trace ? Counterexample Analysis Refine Trace Feasible Explanation of Infeasibility SSA Trace Feasible Proof of Unsat. Extract Predicate Map: Prog Ctr ! Predicates Thm Pvr Y N Trace Feasibility Formula Q0: Is trace feasible ?

Trace Feasibility Formula Q0: Is trace feasible ? Counterexample Analysis Refine Trace Feasible Explanation of Infeasibility SSA Trace Feasible Proof of Unsat. Extract Predicate Map: Prog Ctr ! Predicates Thm Pvr Y N Q2: Where are preds required ? Q1: What predicates remove trace ?

Proof of Unsatisfiability Trace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 x 1 = ctr 0 x 1 = i 0 -1 ctr 0 = i 0 -1 ctr 1 = ctr 0 +1 ctr 1 = i 0 y 1 = ctr 1 y 1 = i 0 y 1  i 0 ; Proof of Unsatisfiability PROBLEM Proof uses entire history of execution Information flows up and down No localized or state information !

The Present State… pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) Trace … is all the information the executing program has here 1. … after executing trace prefix 2. … knows present values of variables 3. … makes trace suffix infeasible State… At pc 4, which predicate on present state shows infeasibility of suffix ?

What Predicate is needed ? Trace pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) Trace Formula (TF) x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 1. … after executing trace prefix 2. … has present values of variables 3. … makes trace suffix infeasible State… … implied by TF prefix Predicate …

What Predicate is needed ? Trace pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) Trace Formula (TF) x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 1. … after executing trace prefix 2. … has present values of variables 3. … makes trace suffix infeasible State… … implied by TF prefix … on common variables Predicate … x1x1 x1x1

What Predicate is needed ? Trace pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) Trace Formula (TF) x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 1. … after executing trace prefix 2. … has present values of variables 3. … makes trace suffix infeasible State… … implied by TF prefix … on common variables … & TF suffix is unsatisfiable Predicate …

What Predicate is needed ? Trace pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) Trace Formula (TF) x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 1. … after executing trace prefix 2. … knows present values of variables 3. … makes trace suffix infeasible State… … implied by TF prefix … on common variables … & TF suffix is unsatisfiable Predicate …

Craig’s Interpolation Theorem [Craig ’57] Given formulas  -,  + s.t.  - Æ  + is unsatisfiable There exists an Interpolant  for  -,  +, s.t. 1.  - implies  2.  has symbols common to  -,  + 3.  Æ  + is unsatisfiable

Examples of Craig’s Interpolation  - = b  (  b  c)  + =  c  - = x 1 =ctr 0  ctr 1 =ctr 0 +1  y 1 =ctr 1  + = x 1 =i 0 -1  y 1  i 0 –y 1 = x 1 + 1

Craig’s Interpolation Theorem [Craig ’57] Given formulas  -,  + s.t.  - Æ  + is unsatisfiable There exists an Interpolant  for  -,  +, s.t. 1.  - implies  2.  has symbols common to  -,  + 3.  Æ  + is unsatisfiable  computable from Proof of Unsat. of  - Æ  + [Krajicek ’97] [Pudlak ’97] (boolean) SAT-based Model Checking [McMillan ’03]

Interpolant = Predicate ! 1. Predicate implied by trace prefix 2. Predicate on common variables common = current value 3. Predicate & suffix yields a contradiction Require: -- ++ Interpolate  1.  - implies  2.  has symbols common to  -,  + 3.  Æ  + is unsatisfiable Interpolant: pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0

Interpolant = Predicate ! 1. Predicate implied by trace prefix 2. Predicate on common variables 3. Predicate & suffix yields a contradiction Require: -- ++ Interpolate  1.  - implies  2.  has symbols common to  -,  + 3.  Æ  + is unsatisfiable Interpolant: pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 y 1 = x 1 + 1

Interpolant = Predicate ! 1. Predicate implied by trace prefix 2. Predicate on common variables 3. Predicate & suffix yields a contradiction Require: -- ++ Interpolate  1.  - implies  2.  has symbols common to  -,  + 3.  Æ  + is unsatisfiable Interpolant: pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 Predicate at pc 4 : y= x+1 y 1 = x pc 4

Building Predicate Maps pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 Cut + Interpolate at each point Pred. Map: pc i  Interpolant from cut i -- ++ Interpolate x 1 = ctr 0 Predicate Map pc 2 : x= ctr pc 2

Building Predicate Maps pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 Cut + Interpolate at each point Pred. Map: pc i  Interpolant from cut i -- ++ Interpolate Predicate Map pc 2 : x = ctr pc 3 : x= ctr-1 x 1 = ctr 1 -1 pc 3

Building Predicate Maps pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 Cut + Interpolate at each point Pred. Map: pc i  Interpolant from cut i -- ++ Interpolate Predicate Map pc 2 : x = ctr pc 3 : x = ctr-1 pc 4 : y = x+1 pc 5 : y= i y 1 = i 0 pc 5

Building Predicate Maps pc 1 : x = ctr pc 2 : ctr = ctr + 1 pc 3 : y = ctr pc 4 : assume(x = i-1) pc 5 : assume(y  i) TraceTrace Formula x 1 = ctr 0 Æ ctr 1 = ctr Æ y 1 = ctr 1 Æ x 1 = i Æ y 1  i 0 Predicate Map pc 2 : x = ctr pc 3 : x = ctr-1 pc 4 : y = x+1 pc 5 : y = i Theorem: Predicate map makes trace abstractly infeasible

Plan 1.Motivation 2.Refinement using Traces Simple Procedure calls 3. Results

Traces with Procedure Calls Trace Formula i pc 1 : x 1 = 3 pc 2 : assume (x 1 >0) pc 3 : x 3 = f 1 (x 1 ) pc 4 : y 2 = y 1 pc 5 : y 3 = f 2 (y 2 ) pc 6 : z 2 = z 1 +1 pc 7 : z 3 = 2*z 2 pc 8 : return z 3 pc 9 : return y 3 pc 10 : x 4 = x 3 +1 pc 11 : x 5 = f 3 (x 4 ) pc 12 : assume(w 1 <5) pc 13 : return w 1 pc 14 : assume x 4 >5 pc 15 : assume (x 1 =x 3 +2) pc 1 : x 1 = 3 pc 2 : assume (x 1 >0) pc 3 : x 3 = f 1 (x 1 ) pc 4 : y 2 = y 1 pc 5 : y 3 = f 2 (y 2 ) pc 6 : z 2 = z 1 +1 pc 7 : z 3 = 2*z 2 pc 8 : return z 3 pc 9 : return y 3 pc 10 : x 4 = x 3 +1 pc 11 : x 5 = f 3 (x 4 ) pc 12 : assume(w 1 <5) pc 13 : return w 1 pc 14 : assume x 4 >5 pc 15 : assume(x 1 =x 3 +2) Trace i Find predicate needed at point i

Interprocedural Analysis Trace Formula i Trace i Procedure Summaries [Reps,Horwitz,Sagiv ’95] Polymorphic Predicate Abstraction [Ball,Millstein,Rajamani ’02] Require at each point i : Well-scoped predicates YES: Variables visible at i NO: Caller’s local variables Find predicate needed at point i YES NO

Problems with Cutting Trace Formula i Trace i -- ++ Caller variables common to  - and  + Unsuitable interpolant: not well-scoped

Interprocedural Cuts Trace Formula i Call begins Trace i

Interprocedural Cuts -- ++ Trace Formula i Call begins Trace i Predicate at pc i = Interpolant from cut i

Common Variables Formals Current locals Trace Formula Predicate at pc i = Interpolant from i-cut i Trace i -- ++ Common Variables Formals Well-scoped

Plan 1.Motivation 2.Refinement using Traces Simple Procedure calls 3. Results

Implementation Algorithms implemented in BLAST –Verifier for C programs, Lazy Abstraction [POPL ’02] FOCI : Interpolating decision procedure Examples: –Windows Device Drivers (DDK) –IRP Specification: 22 state FSM –Current: Security properties of Linux programs

Results ProgramLOC* Previous Time New Time Predicates Total Average kbfiltr 12k1m12s3m48s726.5 floppy 17k7m10s25m20s diskperf 14k5m36s13m32s14010 cdaudio 18k20m18s23m51s parport 61kDNF74m58s parclass 138kDNF77m40s Windows DDK IRP 22 state * Pre-processed

Localizing works… ProgramLOC* Previous Time New Time Predicates Total Average kbfiltr 12k1m12s3m48s726.5 floppy 17k7m10s25m20s diskperf 14k5m36s13m32s14010 cdaudio 18k20m18s23m51s parport 61kDNF74m58s parclass 138kDNF77m40s Windows DDK IRP 22 state * Pre-processed

Conclusion Scalability and Precision by localizing Craig Interpolation –Interprocedural cuts give well-scoped predicates Some Current and Future Work: –Multithreaded Programs Project local info of thread to predicates over globals –Hierarchical trace analysis

BLAST Berkeley Lazy Abstraction Software * Tool

SLAM A Microsoft tool for checking safety of device drivers Inspired BLAST

Limitations of CEGAR Limited to powerset/relational abstract domains Interpolant computations Interactions with widening Starting on the right foot Unnecessary refinement steps Long and infinite number of refinement steps Long traces

Unnecessary Refinements x = 0 while (x < 10 6 ) do x = x + 1 assert x < 100

Unsuccessful Refinement Set x = malloc(); y = x ; while (…) t = malloc(); t->next = x x = t; … while (x !=y) do assert x != null; x = x->next

Long Traces Example ( ) { 1:c = 0; 2:for(i=1;i<1000;i++) 3: c = c + f(i); 4:if (a>0) { 5: if (x==0) { ERR: ; } Example ( ) { 1:c = 0; 2:for(i=1;i<1000;i++) 3: c = c + f(i); 4:if (a>0) { 5: if (x==0) { ERR: ; } Assume f always terminates ERR is reachable –a and x are unconstrained Any feasible path to error must unroll the loop 1000 times AND find feasible paths through f Any other path must be dismissed as a false positive

Long Traces Example ( ) { 1:c = 0; 2:for(i=1;i<1000;i++) 3: c = c + f(i); 4:if (a>0) { 5: if (x==0) { ERR: ; } Example ( ) { 1:c = 0; 2:for(i=1;i<1000;i++) 3: c = c + f(i); 4:if (a>0) { 5: if (x==0) { ERR: ; } Intuitively, the for loop is irrelevant ERR reachable as long as there exists some path from 2 to 4 that does not modify a or x Can we use static analysis to precisely report a statement is reachable without finding a feasible path?

Long Traces Example ( ) { 1:c = 0; 2:for(i=1;i<1000;i++) 3: c = c + f(i); 4:if (a>0) { 5: if (x==0) { ERR: ; } Example ( ) { 1:c = 0; 2:for(i=1;i<1000;i++) 3: c = c + f(i); 4:if (a>0) { 5: if (x==0) { ERR: ; } c = 0 1 i = 1 2 i ¸ ’ 3 c = c + f(i);i++ 4 2’ i<1000 a>0 x== a>0 x==0 5

Path Slice (PLDI’05) The path slice of a program path  is a subsequence of the edges of  such that if the sequence of operations along the subsequence is: 1.infeasible, then  is infeasible, and 2.feasible, then the last location of  is reachable (but not necessarily along  )