Abstraction in Model Checking Nishant Sinha

Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does M satisfy p ?

Model Checking (safety) I Too many states to handle ! = bad state MUST ABSTRACT!!

Abstraction Eliminate details irrelevant to the property Obtain simple finite models sufficient to verify the property –E.g., Infinite state ! Finite state approximation Disadvantage –Loss of Precision: False positives/negatives

Data Abstraction hhhhh Abstraction Function h : S ! S S S

Data Abstraction Example Abstraction proceeds component-wise, where variables are components x:int Even Odd …, -3, -1, 1, 3, … …, -2, 0, 2, 4, … 1, 2, 3, … …, -3, -2, -1 0 Pos Neg Zero y:int

Data Abstraction Example Partition concrete variables into visible(V) and invisible(I) variables. The abstract model consists of V variables. I variables are existentially quantified out. The abstraction function maps each state to its projection over V.

Data Abstraction Example h x1 x2 x3 x4 x1 x2 Group concrete states with identical visible part to a single abstract state.

Data Type Abstraction int x = 0; if (x == 0) x = x + 1; Abstract Data domain (n<0) : NEG (n==0): ZERO (n>0) : POS Signs NEGPOSZERO int Code Signs x = ZERO; if (Signs.eq(x,ZERO)) x = Signs.add(x,POS);

How do we Abstract Behaviors? Abstract domain A –Abstract concrete values to those in A Then compute transitions in the abstract domain –Over-approximations: Add extra behaviors –Under-approximations: Remove actual behaviors

Formalism: Kripke Structures M = (S,s 0, !,L) on AP S: Set of States s 0 : Initial State ! : Transition Relation L: S ! 2 AP, Labeling on States pp !p p,q

Simulations on Kripke Structures M = (S, s 0, !, L) Definition: R S S is a simulation relation between M and M iff M simulates M (M ¹ M) iff (s 0, t 0 ) 2 R Intuitively, every transition in M can be matched by some transition in M (s,s) R implies 1.L(s) = L(s) 2.for all t s.t. s t, exists t s.t. s t and (t,t) R.

Guarantees from Abstraction Strong Preservation: –M ² P iff M ² P Weak Preservation: –M ² P ) M ² P Simulation preserves ACTL* properties – If M ¹ M then M ² AG p ) M ² AG p

Overview Formalizing Abstraction/Refinement –Homomorphic Abstractions –Abstract Interpretation Theory –Guarantees from Abstractions – Safe –Automated Abstraction Refinement - CEGAR Applications –Hardware – e.g., Hom. Abstraction –Software – e.g., Predicate Abstraction

Building an Abstraction Computing Abstract Domain Computing Abstract Transitions

Homomorphisms Clarke et. al.- 94, 00 Concrete States S, Abstract states S Abstraction function (Homomorphism) –h: S ! S –Induces a partition on S equal to size of S

Existential/Universal Abstractions Existential –Make a transition from an abstract state if at least one corresponding concrete state has the transition. –Abstract model M simulates concrete model M Universal –Make a transition from an abstract state if all the corresponding concrete states have the transition.

Existential Abstraction (Over-approximation) I I h S S

Universal Abstraction (Under-Approximation) I I h S S

Guarantees from Exist. Abstraction Preservation Theorem M φ M φ : counterexample may be spurious Converse does not hold M φ Let φ be a ACTL* property M existentially abstracts M, so M ¹ M M M

Guarantees from Univ. Abstraction Preservation Theorem M 2 φ Converse does not hold M φ Let φ be a existential-quantified property (i.e., expressed in ECTL*) and M simulates M

Why spurious counterexample? I I Deadend states Bad States Failure State f

Refinement Problem: Deadend and Bad States are in the same abstract state. Solution: Refine abstraction function. The sets of Deadend and Bad states should be separated into different abstract states.

Refinement h Refinement : h

Abstract Interpretation Cousot et. al. 77 Framework for approximating fixpoint computations Galois Connections –Concrete: S, Abstract: S –Abstract S. F(S) = S as S. F(S) = S –Homomorphisms are a particular case Widening/Narrowing

Galois Connections S – concrete, S – abstract S must be a complete lattice : 2 S S - abstraction function : S 2 S - concretization function Properties of and : –((A)) · A, for A in S –((X)) X, for X µ S The above properties mean that and are Galois-connected SS

Abs. Interpretation: Example int -> {even, odd, T} (even) = {..,-2,0,2,4..} (odd) = {..,-3,-1,1,3..} (T) = int Predicate abstraction is an instance

Computing Abstract Transition Relation Existential Abstraction R [Dams97]: (t, t 1 ) R iff s (t) and s 1 (t 1 ) s.t. (s, s 1 ) R This ensures that –M simulates M –Preservation Theorem applies Similarly, Universal Abstraction R 89 SS RR

Other kinds of Abstraction Cone of Influence Slicing

Automated Abstraction/Refinement Good abstractions are hard to obtain –Automate both Abstraction and Refinement processes Counterexample-Guided AR (CEGAR) –Build an abstract model M –Model check property P, M ² P? –If M ² P, then M ² P by Preservation Theorem –Otherwise, check if Counterexample (CE) is spurious –Refine abstract state space using CE analysis results –Repeat

Counterexample-Guided Abstraction-Refinement (CEGAR) Check Counterexample Obtain Refinement Cue Model Check Build New Abstract Model MM No Bug Pass Fail Bug Real CE Spurious CE

Use of Abstractions in Hardware and Software Verification

Applications Hardware Verification: –Thousands of Latches –Abstract using homomorphisms –SAT-based methods (Clarke et. al.) Software Verification: –Integer variables, Undecidability –Predicate Abstraction SLAM MAGIC, BLAST All these approaches are automated (CEGAR)

Verifying Hardware: Abstraction A number of approaches –Localization (Kurshan et. Al.) –SAT-based (02) –… We consider a homomorphism-based approach inside CEGAR framework

Counterexample-Guided Abstraction-Refinement (CEGAR) Check Counterexample Obtain Refinement Cue Model Check Build New Abstract Model MM No Bug Pass Fail Bug Real CE Spurious CE

Abstraction Function Partition variables into visible(V) and invisible(I) variables. The abstract model consists of V variables. I variables are made inputs (existentially quantified). The abstraction function maps each state to its projection over V.

Abstraction Function Example h x1 x2 x3 x4 x1 x2 Group concrete states with identical visible part to a single abstract state.

Abstract Model Computation I I h Existential Abstraction:

Obtaining Exist. Abstraction Symbolically Concrete Model : (S, I, R, L) Abstract Model: (S,I,R,L) h: S ! S S = {s j 9 s 2 S. h(s)=s} I = {s j 9 s 2 S. I(s) Æ h(s)=s} R = {(s 1,s 2 ) j 9 s 1,s 2. R(s 1,s 2 ) Æ h(s 1 )=s 1 Æ h(s 2 )=s 2 }

Checking the Counterexample Model check the abstract model –Yes or a Counterexample CE Counterexample : (c 1, …,c m ) –Each c i is an assignment to V. Simulate the counterexample on the concrete model.

Checking the Counterexample Concrete traces corresponding to the counterexample: (Initial State) (Unrolled Transition Relation) (Restriction of V to Counterexample) Refine if CE is spurious

Spurious counterexample? I I Deadend states Bad States Failure State f

Refinement hhhh h Refinement (h): Make Invisible variables Visible hh

Refinement methods… P Frontier Inputs Invisible Visible (R. Kurshan, 80s) Localization

Simulate counterexample on concrete model with SAT If the instance is unsatisfiable, analyze conflict Make visible one of the variables in the clauses that lead to the conflict (Chauhan, Clarke, Kukula, Sapra, Veith, Wang, FMCAD 2002) Abstraction/refinement with conflict analysis Refinement methods…

Refinement as Separation Deadend States Failure State f

Refinement as Separation Deadend States Bad States

Refinement as Separation d1d1 b1b1 b2b2 I V Refinement : Find subset U of I that separates between all pairs of deadend and bad states. Make them visible. Keep U small ! v 1 v 2 v 3 v 4 v 5 v 6 v 7

Refinement as Separation d1d1 b1b1 b2b I V Refinement : Find subset U of I that separates between all pairs of deadend and bad states. Make them visible. Keep U small ! v 1 v 2 v 3 v 4 v 5 v 6 v 7

Refinement as Separation The state separation problem Input: Sets D, B Output: Minimal U subset of I s.t.: d D, b B, u U. d(u) b(u) The refinement h is obtained by adding U to V.

Two separation methods ILP-based separation –Minimal separating set. –Computationally expensive. Decision Tree Learning based separation. –Not optimal. –Polynomial.

More Details.. SAT-based Abstraction Refinement Using ILP and Machine Learning, Edmund Clarke, Anubhav Gupta, James Kukula, Ofer Strichman. CAV02 Automated Abstraction Refinement for Model Checking Large State Spaces Using SAT Based Conflict Analysis, Pankaj Chauhan, Edmund M. Clarke, James H. Kukula, Samir Sapra, Helmut Veith, Dong Wang. FMCAD02

Software: Predicate Abstraction Graf, Saidi 97 Abstraction using Galois Connections –Predicates define abstract states –Existential abstraction using theorem provers Example –P = {p1, p2}: p1 ´ x<5, p2 ´ y ¸ 4 –States: (p1,p2), (!p1,p2) …

Defining an Abstract Domain Predicates on Variables –E.g., p1 ´ x<3 –Do not abstract program location variables Weakest Preconditions (WP) –WP(x=y+1, p1) ´ (y+1<3) ´ (y<2) –WP (Y, x=e) = Y [e/x] Predicate Discovery using WP x = y+1 x<3 y<2

CEGAR Build Model –Using initial set of predicates P Model Check –Generate reachable states explicitly/symbolically –Obtain CE Check if CE is spurious –SAT-based Refinement Cue –Find new predicates to add to P

Example Q: Is Error Reachable ? Example ( ) { 1: do { lock(); old = new; 2: if (*) { 3: unlock(); new ++; } 4: } while ( new != old); 5: unlock (); return; } unlock()lock() unlock() lock() sets LOCK=1 unlock() sets LOCK=0

Example ( ) { 1: do { lock(); old = new; 2: if (*) { 3: unlock(); new ++; } 4: } while ( new != old); 5: unlock (); return; } Example:CFG lock(); old = new [>][>] [>][>] [new==old] [new!=old] ret unlock() new++ unlock()

Example:CFG Q: Is Error Reachable ? ret unlock()lock() unlock() Example ( ) { 1: do { lock(); old = new; 2: if (*) { 3: unlock(); new ++; } 4: } while ( new != old); 5: unlock (); return; }

Step 1: Generate and Model Check Abstract space Set of predicates: LOCK=0, LOCK=1 1 LOCK=0 3 LOCK=1 lock(); old = new [>][>] unlock() 5 LOCK=0 unlock() new++ [new==old] 4 LOCK=0 2 LOCK=1 Err LOCK=0 lock(); old = new [>][>] [>][>] [new==old] [new!=old] ret unlock() new++ unlock()

Q: When can: Step 2: Analyze Counterexample 1 LOCK=0 2 LOCK=1 3 4 LOCK=0 5 Err LOCK=0 n Err ops Bad States = Pre (,ops) Err R n Æ Pre (,ops) = ? Err Fwd Reachable (Deadend) States at node n = R n Formulate as satisfiability problem for a logic

Step 2: Analyze Counterexample 1 LOCK=0 2 LOCK=1 3 4 LOCK=0 5 Err LOCK=0 lock(); old = new [new==old] unlock() LOCK=0 LOCK=0 Æ new = old [>][>] unlock(); new++ LOCK=1 Æ new+1 = old lock(); old = new [>][>] [>][>] [new==old] [new!=old] ret unlock() new++ unlock() LOCK=0 Æ new+1 = new Formulate as satisfiability problem for a logic unlock(); new++

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

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

Step 3: Resume Search 1 LOCK=0 2 LOCK=1 Æ new = old 3 4 LOCK=0 Æ : new = old ? 51 LOCK=0 Æ : new = old 4 LOCK=1 Æ new=old 5 1 ? ret LOCK=0 Æ new=old ERROR Unreachable Set of predicates: LOCK=0, LOCK=1, new = old lock(); old = new [>][>] [>][>] [new==old] [new!=old] ret unlock() new++ unlock()

CEGAR for Software Verification (C programs) SLAM 00 –Abstract C programs to Boolean programs (C2BP) –Symbolic Model Checker (Bebop), CE-analysis (Newton) (C programs) BLAST –On-the-fly Predicate Abstraction –Lazy Abstraction –Proof-based CE analysis (C programs) MAGIC –Handles concurrent message-passing programs –Two-level CEGAR (Java programs) ESC/Java, Bandera, …

Using SAT in Predicate Abstraction Build Abstraction: All-SAT for computing abstract transitions Model Check: BDD-based Checking CE: BMC-like simulation of CE Refinement: Uses proof of infeasibility of CE from SAT solver

Conclusion Formal basis for Abstraction/Refinement –Homomorphic Abstractions –Abstract Interpretation –Safe Abstractions Applications –Hardware – e.g., Hom. Existential Abstraction –Software – e.g., Predicate Abstraction

Acknowledgements We thank the following sources for the slides: –Model Checking Group, CMU –BLAST group, Berkeley –Bandera group, KSU