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