Abstraction in Model Checking Nishant Sinha Model Checking
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 S h h h S’ Abstraction Function h : S ! S’
Data Abstraction Example • Abstraction proceeds component-wise, where variables are components x: int y: int …, -2, 0, 2, 4, … Even …, -3, -1, 1, 3, … Odd …, -3, -2, -1 Neg 0 Zero 1, 2, 3, … Pos
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 x 1 x 2 x 3 x 4 0 1 0 0 1 1 0 0 0 0 h x 1 x 2 0 0 Group concrete states with identical visible part to a single abstract state.
Data Type Abstraction Code int x = 0; if (x == 0) x = x + 1; Abstract Data domain int (n<0) : NEG (n==0): ZERO (n>0) : POS Signs x = ZERO; if (Signs. eq(x, ZERO)) x = Signs. add(x, POS); Signs NEG ZERO 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 p !p p, q p
Simulations on Kripke Structures M = (S, s 0, !, L) M’ = (S’, s’ 0, !’, L’) Definition: R S S’ is a simulation relation between M and M’ iff (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. 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’
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 onecorresponding 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 S h I S’
Universal Abstraction (Under-Approximation) I S h I S’
Guarantees from Exist. Abstraction Let φ be a ACTL* property M’ existentially abstracts M, so M ¹ M’ Preservation Theorem M’ ⊨ φ M ⊨ φ Converse does not hold M’ ⊭ φ M ⊭ φ M’ ⊭ φ : counterexample may be spurious M M’
Why spurious counterexample? Deadend states I I f Bad States Failure State
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 S – concrete, S’ – abstract S’ must be a complete lattice : 2 S → S’ - abstraction function : S’ → 2 S - concretization function Properties of and : S’ – ( (A)) · A, for A in S’ – ( (X)) ⊇ X, for X µ S • The above properties mean that and are Galois-connected
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 S S’ • R [Dams’ 97]: (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 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) M Build New Abstract Model M’ Pass Model Check No Bug Fail Obtain Refinement Cue Spurious CE Check Counterexample Real CE Bug
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) M Build New Abstract Model M’ Pass Model Check No Bug Fail Obtain Refinement Cue Spurious CE Check Counterexample Real CE Bug
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 x 1 x 2 x 3 x 4 0 1 0 0 1 1 0 0 0 0 h x 1 x 2 0 0 Group concrete states with identical visible part to a single abstract state.
Abstract Model Computation • Existential Abstraction: I h I
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, …, 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? Deadend states I I f Bad States Failure State
Refinement h’ h’ Refinement (h’): Make Invisible variables Visible
Refinement methods… Localization (R. Kurshan, 80’s) Frontier Visible Invisible Inputs P
Refinement methods… Abstraction/refinement with conflict analysis )Chauhan, Clarke, Kukula, Sapra, Veith, Wang, FMCAD 2002) • 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
Refinement as Separation Deadend States f Failure State
Refinement as Separation Deadend States Bad States
Refinement as Separation d 1 v 2 v 3 v 4 v 5 v 6 v 7 0 1 01 10 0 I b 1 0 0 10 01 0 b 2 0 1 11 11 0 V Refinement : Find subset U of I that separates between all pairs of deadend and bad states. Make them visible. Keep U small !
Refinement as Separation d 1 v 2 v 3 v 4 v 5 v 6 v 7 0 1 0 10 0 I b 1 0 0 1 01 0 b 2 0 1 1 11 0 V Refinement : Find subset U of I that separates between all pairs of deadend and bad states. Make them visible. Keep U small !
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. 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 = {p 1, p 2}: p 1´ x<5, p 2´ y¸ 4 – States: (p 1, p 2), (!p 1, p 2) …
Defining an Abstract Domain • Predicates on Variables – E. g. , p 1 ´ x<3 – Do not abstract program location variables • Weakest Preconditions (WP) – WP(x=y+1, p 1) ´ (y+1<3) ´ (y<2) – WP (Y, x=e) = Y e/x [ ] y<2 x = y+1 x<3 • Predicate Discovery using WP
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 ( ) { 1: do { lock(); old = new; 2: if (*) { 3: unlock(); new ++; } 4: } while ( new != old); 5: unlock (); return; } lock() sets LOCK=1 unlock() sets LOCK=0 lock() unlock() Q: Is Error Reachable ?
Example: CFG 1 Example ( ) { 1: do { lock(); old = new; 2: if (*) { 3: unlock(); new ++; } 4: } while ( new != old); 5: unlock (); return; } lock(); old = new [>] 2 [>] 3 unlock() new++ [new!=old] 4 [new==old] 5 unlock() ret
Example: CFG Example ( ) { 1: do { lock(); old = new; 2: if (*) { 3: unlock(); new ++; } 4: } while ( new != old); 5: unlock (); return; } 1 lock() 2 3 4 5 unlock() ret Q: Is Error Reachable ? lock()
Step 1: Generate and Model Check Abstract space 1 lock(); old = new [>] 3 unlock(); old = new 2 [>] [new!=old] 1 LOCK=0 2 LOCK=1 4 new++ [new==old] 5 unlock() new++ 3 unlock() ret LOCK=1 4 LOCK=0 5 LOCK=0 Err LOCK=0 [new==old] unlock() Set of predicates: LOCK=0, LOCK=1
Step 2: Analyze Counterexample 1 LOCK=0 2 LOCK=1 Q: When can: n Bad States = ops Err 3 LOCK=1 4 LOCK=0 5 LOCK=0 Err LOCK=0 Pre( Err , ops) Fwd Reachable (Deadend) States at node n = Rn Rn Æ Pre( Err , ops) = Æ ? Formulate assatisfiabilityproblem for a logic
Step 2: Analyze Counterexample 1 lock(); old = new [>] 2 [>] 3 unlock() [new!=old] lock(); old = new 4 new++ [>] 1 LOCK=0 Æ new+1 = new 2 LOCK=1 Æ new+1 = old [new==old] 5 unlock() ret 3 LOCK=1 Æ new +1 = old 4 LOCK=0 Æ new = old 5 LOCK=0 Err LOCK=0 unlock(); new++ [new==old] unlock() Formulate assatisfiabilityproblem for a logic
Step 2: Analyze Counterexample 1 lock(); old = new [>] 2 [>] 3 unlock() [new!=old] 4 new++ 1 LOCK=0 Æ new+1 = new 2 LOCK=1 Æ new+1 = old [new==old] 5 unlock() ret Track the predicate: new = old 3 LOCK=1 Æ new +1 = old 4 LOCK=0 Æ new = old 5 LOCK=0 Err LOCK=0
Step 3: Resume Search 1 lock(); old = new [>] 2 1 [>] 3 unlock() LOCK=0 [new!=old] 4 new++ LOCK=1 Æ new = old [>] [new==old] 5 unlock() ret 2 LOCK=1 Æ new = old 3 LOCK=0 Æ : new = old 4 [new!=old] ? Set of predicates: LOCK=0, LOCK=1, new = old 5 1 LOCK=0 Æ : new = old µ LOCK =0
Step 3: Resume Search 1 lock(); old = new [>] 2 1 [>] 3 unlock() LOCK=0 ERROR [new!=old] LOCK=1 Æ new = old 4 new++ [new==old] LOCK=1 Æ new = old 2 Unreachable 3 5 unlock() ret LOCK=0 Æ : new = old ? Set of predicates: LOCK=0, LOCK=1, new = old 5 4 4 1 5 LOCK=0 Æ : new = old LOCK=1 Æ new=old 1 ? ret LOCK=0Æ new=old
CEGAR for Software Verification • (C programs) SLAM ’ 00 – Abstract C programs to Boolean programs (C 2 BP) – 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
- Slides: 67