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

h h hh h

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

Zeroy: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

0 0

0 0 0 00 0 0 10 0 1 00 0 1 1

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

NEG POSZERO

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,s0,!,L) on AP S: Set of States s0: Initial State !: Transition Relation L: S ! 2AP, Labeling on States

pp

!p

p,q

Simulations on Kripke Structures

M = (S, s0, !, L)

M’ = (S’, s’0, !’, L’)

Definition: R S S’ is a simulation relation between M and M’ iff

M’ simulates M (M ¹ M’) iff (s0, t0)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 TheoremM’ ⊨ φ M ⊨ φ

M’ ⊭ φ : counterexample may be spurious

Converse does not holdM’ ⊭ φ M ⊭ φ

Let φ be a ACTL* property M’ existentially abstracts M, so M ¹ M’

M’

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 : 2S

→ S’ - abstraction function

: S’ → 2S - 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

S S’

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 [Dams’97]: (t, t1) R’ iff

s (t) and s1 (t1) s.t. (s, s1) R

• This ensures that – M’ simulates M – Preservation Theorem applies

• Similarly, Universal Abstraction R89

S S’

R R’

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 CheckBuild New

Abstract Model

M’M

No Bug

Pass

Fail

BugReal CESpurious 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 CheckBuild New

Abstract Model

M’M

No Bug

Pass

Fail

BugReal CESpurious 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

0 0

0 0 0 00 0 0 10 0 1 00 0 1 1

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 9s 2 S. h(s)=s’}

• I’ = {s’ j 9s 2 S. I(s) Æ h(s)=s’}

• R’ = {(s1’,s2’) j

9 s1,s2. R(s1,s2) Æ h(s1)=s1’ Æ h(s2)=s2’}

Checking the Counterexample

• Model check the abstract model– Yes or a Counterexample CE

• Counterexample : (c1, …,cm)

– Each ci 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

h’

h’

h’

h’

h’

Refinement (h’): Make Invisible variables Visible

h’

h’

Refinement methods…

PFrontier

Inputs

Invisible

Visible

(R. Kurshan, 80’s)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 SeparationDeadend States

Failure State

f

Refinement as SeparationDeadend States

Bad States

Refinement as Separation

0 1 0 1 0 1 0

0 0 1 0 0 1 0

0 1 1 1 0 1 0

d1

b1

b2

I

V

0

1

1

1

0

1

Refinement : Find subset U of I that separates between all pairs of deadend and bad states. Make them visible.

Keep U small !

v1 v2 v3 v4 v5 v6 v7

Refinement as Separation

0 1 0 1 0 1 0

0 0 1 0 0 1 0

0 1 1 1 0 1 0

d1

b1

b2

0

1

1

I

V

Refinement : Find subset U of I that separates between all pairs of deadend and bad states. Make them visible.

Keep U small !

v1 v2 v3 v4 v5 v6 v7

Refinement as Separation

The state separation problemInput: Sets D, BOutput: 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. CAV’02

• 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. FMCAD’02

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

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]

2

1

3

4

5

ret

unlock()

new++

unlock()

Example:CFG

Q: Is Error Reachable ?

2

1

3

4

5

ret

unlock() lock()

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]

2

1

3

4

5

ret

unlock()new++

unlock()

Q: When can:

Step 2: Analyze Counterexample

1 LOCK=0

2 LOCK=1

3 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0

n Errops

Bad States = Pre( ,ops) Err

Rn Æ Pre( ,ops) = ? Err

Fwd Reachable (Deadend)

States at node n = Rn

Formulate as satisfiability problem for a logic

Step 2: Analyze Counterexample

1 LOCK=0

2 LOCK=1

3 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0

lock();

old = new

[new==old]

unlock()

LOCK=0

LOCK=0 Æ new = old

[>]

unlock();

new++

LOCK=1 Æ new+1 = old

LOCK=1 Æ new +1 = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

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 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0 LOCK=0

LOCK=0

LOCK=0 Æ new = old

LOCK=0 Æ new+1 = new

LOCK=1 Æ new+1 = old

LOCK=1 Æ new +1 = old

Track the predicate:

new = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

Step 3: Resume Search

1LOCK=0

? 5[new!=old]

1

LOCK=0 Æ : new = old µ LOCK =0

Set of predicates:

LOCK=0, LOCK=1, new = old

3LOCK=1 Æ new = old

[>]

4LOCK=0 Æ : new = old

2LOCK=1 Æ new = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

Step 3: Resume Search

1LOCK=0

2LOCK=1 Æ new = old

3LOCK=1 Æ new = old

4LOCK=0 Æ : new = old

? 5 1

LOCK=0 Æ : new = old

4LOCK=1 Æ new=old

5 1

?

retLOCK=0Æ new=old

ERROR

Unreachable

Set of predicates:

LOCK=0, LOCK=1, new = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

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