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

Advanced programming tools at Microsoft
The SLAM Project: Debugging System Software via Static Analysis
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.
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.
Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking.
Proofs and Counterexamples Rupak Majumdar. In the good old days… Decision Procedure  yes no.
Thomas Ball, Rupak Majumdar, Todd Millstein, Sriram K. Rajamani Presented by Yifan Li November 22nd In PLDI 01: Programming Language.
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.
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.
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.
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
Secrets of Software Model Checking Thomas Ball Sriram K. Rajamani Software Productivity Tools Microsoft Research
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?
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.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Automatic Predicate Abstraction of C Programs Thomas BallMicrosoft Rupak MajumdarUC Berkeley Todd MillsteinU Washington Sriram K. RajamaniMicrosoft
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
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.
Newton: A tool for generating abstract explanations of infeasibility1 The Problem P (C Program) BP (Boolean Program of P) CFG(P) CFG(BP)
Thomas Ball Sriram K. Rajamani
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.
Localization and Register Sharing for Predicate Abstraction Himanshu Jain Franjo Ivančić Aarti Gupta Malay Ganai.
SLAM internals Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India.
The Yogi Project Software property checking via static analysis and testing Aditya V. Nori, Sriram K. Rajamani, Sai Deep Tetali, Aditya V. Thakur Microsoft.
Synergy: A New Algorithm for Property Checking Bhargav S. Gulavani (IIT Bombay)‏ Yamini Kannan (Microsoft Research India)‏ Thomas A. Henzinger (EPFL)‏
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.
#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
Course: CS60030 Formal Systems
BLAST: A Software Verification Tool for C programs
Presentation transcript:

Counter Example Guided Refinement CEGAR Mooly Sagiv

Challenges Correctness requirements Decidability and complexity of program verification Abstract models of systems Algorithms

SLAM Microsoft blames most Windows crashes on third party device drivers The Windows device driver API is quite complicated Drivers are low level C code SLAM: Tool to automatically check device drivers for certain errors SLAM is shipped with Device Driver Development Kit Full detail available at

“Things like even software verification, this has been the Holy Grail of computer science for many decades but now in some very key areas, for example, driver verification we’re building tools that can do actual proof about the software and how it works in order to guarantee the reliability” Testing Development Source Code Precise API Usage Rules (SLIC) Software Model Checking Read for understanding New API rules Drive testing tools Defects 100% path coverage Rules Static Driver Verifier

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)[] [z  P ] TF [y  P, z  P] [yN][yN] [x  P]

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

BLAST Berkeley Lazy Abstraction Software Tool

Abstractions from Proofs: POPL’04 Ranjit Jhala UCSD Rupak Majumdar MPI Ken McMillan MSR Thomas Henzinger IST

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 meaning of each predicate p i  Pred is a closed first order formula f i The relational domain is –Join is set union –State space explosion Special case of canonic abstraction

A Simple Example int x, y; x = 1; y = 2 ; while (*) do { x = x + y ; } assert x > 0; Predicates: p1 = x > 0 p2 = y  0 bool p1, p2; p1 = true ; p2 = true ; while (*) do { p1 = (p1&&p2 ? 1 : *) } assert p1 ;

do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock(); SLAM Example Does this code obey the locking rule?

do { KeAcquireSpinLock(); if(*){ KeReleaseSpinLock(); } } while (*); KeReleaseSpinLock(); SLAM Example Model checking boolean program (bebop) U L L L L U L U U U E

do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock(); SLAM Example Is error path feasible in C program? (newton) U L L L L U L U U U E

do { KeAcquireSpinLock(); nPacketsOld = nPackets; b = true; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; b = b ? false : *; } } while (nPackets != nPacketsOld); !b KeReleaseSpinLock(); SLAM Example Add new predicate to boolean program (c2bp) b : (nPacketsOld == nPackets) U L L L L U L U U U E

do { KeAcquireSpinLock(); b = true; if(*){ KeReleaseSpinLock(); b = b ? false : *; } } while ( !b ); KeReleaseSpinLock(); b b b b SLAM Example Model checking refined boolean program (bebop) b : (nPacketsOld == nPackets) U L L L L U L U U U E b b !b

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 formula over prog. vars [F 1 ]  [F 2 ]F1  F2F1  F2 [F 1 ]  [F 2 ]F 1  F 2 [F][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 ++ --   

Craig’s Interpolation Theorem (take 2) Given formulas  -,  + s.t.  - implies  + There exists an Interpolant  for  -,  +, s.t. 1.  - implies  implies  + 2.  has symbols common to  -,  + --    ++

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 only 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

x 1 = ctr 0  ctr 1 = ctr  y 1 = ctr 1  x 1 = i  y 1  i 0 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 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

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

Limitations of CEGAR Interpolants Non-disjunctive analysis

Summary CEGAR can be effective heuristics for finding abstraction More methods later