2-Valued and 3-Valued Abstraction-Refinement Frameworks for Model Checking

1. 2-Valued and 3-Valued Abstraction-Refinement Frameworks for Model Checking Orna Grumberg Technion Haifa, Israel Tutorials at ATVA, 2009

2. Outline • 2-valued Abstraction • CounterExample-Guided Abstraction-Refinement (CEGAR) • 3-Valued Abstraction • Three-Valued abstraction-Refinement (TVAR)

3. Why (formal) verification? • safety-critical applications: Bugs are unacceptable! • Air-traffic controllers • Medical equipment • Cars • Bugs found in later stages of design are expensive, e.g. Intel’s Pentium bug in floating-point division • Hardware and software systems grow in size and complexity: Subtle errors are hard to find by testing • Pressure to reduce time-to-market Automated tools for formal verification are needed

4. Model Checking An efficient procedure that receives: • A finite-state model describing a system • A temporal logic formula describing a property It returns yes, if the system has the property no + Counterexample, otherwise [EC81,QS82]

5. Model Checking • Emerging as an industrial standard tool for verification of hardware designs: Intel, IBM, Cadence, … • Recently applied successfully also for software verification: SLAM (Microsoft), Java PathFinder and SPIN (NASA), BLAST (EPFL), CBMC (Oxford),…

6. Model of a systemKripke structure / transition system a,b a a b,c b a,c a,b c

7. Linear Time Every moment has a unique successor Infinite sequences (words) Linear Time Temporal Logic (LTL) Branching Time Every moment has several successors Infinite tree Computation Tree Logic (CTL) Temporal Logics • Temporal Logics • Express properties of event orderings in time

8. Propositional temporal logic In Negation Normal Form AP– a set of atomic propositions Temporal operators: Gp Fp Xp pUq Path quantifiers:A for all path E there exists a path

9. Branching-time Temporal Logics CTL*, -calculus - powerful branching-time logics, containing both CTL and LTL ACTL / ACTL* / A-calculus The universal fragments of the logics, with only universal path quantifiers

10. Main limitation of Model Checking The state explosion problem: Model checking is efficient in time but suffers from high space requirements: The number of states in the system model grows exponentially with • the number of variables • the number of components in the system

11. Solutions to the state explosion problem Small models replace the full, concrete model: • Abstraction • Compositional verification • Partial order reduction • Symmetry

12. Abstraction-Refinement • Abstraction: removes or simplifies details that are irrelevant to the property under consideration, thus reducing the number of states • Refinement might be needed

13. Manual abstraction requires • great creativity and • close familiarity with the checked system • Goal: • Automatically construct an abstract model • Automatically refine it, if necessary

14. 2-valuedCounterExample-Guided Abstraction Refinement (CEGAR)For ACTL* [CGJLV00]

15. Abstraction preserving ACTL/ACTL* Existential Abstraction: The abstract model is an over-approximation of the concrete model: • The abstract model has more behaviors • But no concrete behavior is lost • Every ACTL/ACTL* property true in the abstract model is also true in the concrete model

16. Existential Abstraction Given an abstraction function h : S SA, the concrete states are grouped and mapped into abstract states : MA MC MA h h h MC

17. h h h Existential Abstraction (cont.) Given an abstraction function h : S SA, the concrete states are grouped and mapped into abstract states : AP = {p} p p MA p MC p p p p p p p p

18. Widely used Abstractions (SA, h) • For Hardware:Localization reduction: each variable either keeps its concrete behavior or is fully abstracted (has free behavior) [Kurshan94] • For Software:Predicate abstraction: concrete states are grouped together according to the set of predicates they satisfy [GS97,SS99]

19. Logic preservation Theorem • TheoremMC MA, therefore for every ACTL* formula , MA|=  MC|= • However, the reverse may not be valid.

20. Abstraction functionh mapsgreen,yellowtogo. red go MA Traffic Light Example • Property: • =AGAF¬(state=red) red MC|=   green MA |=  yellow MC

21. MC|= butMA |=  Traffic Light Example (Cont) If the abstract model invalidates a specification, the actual model may still satisfy the specification. • Property: • =AGAF (state=red) red red green go yellow • SpuriousCounterexample: • red,go,go, ... MA MC

22. M and  generateinitial abstraction MA MA|=  model check MA|= generate counterexample TA stop refinement TA TA check spurious counterexample TA is not spurious is spurious The CEGAR Methodology

23. Generating the Initial Abstraction • If we use predicate abstraction then predicates are extracted from the program’s control flow and the checked property • If we use localization reduction then the unabstracted variables are those appearing in the predicates above

24. Counterexamples • For AGp it is a finitepath to a state satisfying p • For AFp it is aninfinite pathrepresented by a lasso (finite path+loop), where allstates satisfyp

25. therefore, M|= Path Counterexample Assume that we have four abstract states {1,2,3}   {4,5,6}   {7,8,9}   {10,11,12}   Abstract counterexample Th= , , ,      Th is not spurious,

26. Remark: •  and {10, 11, 12} are labeled the same • If  satisfies p then 10, 11, 12 also satisfy p Therefore, (1, 4, 9, 12) is a concrete path counterexample

27. failure state Spurious Path Counterexample Th is spurious The concrete states mapped to the failure state are partitioned into 3 sets

28. Refining The Abstraction • Goal : refine h so that the dead-end states and bad states do not belong to the same abstract state. • For this example, two possible solutions.

29. Automatic Refinement If the counterexample is spurious • Find a splitting criterion that separates the bad states from the dead-end states in the failure state • Apply the splitting criterion to splitting either only the failure state or all states • Faster convergence of the CEGAR loop • Faster growing abstract models

30. Checking for Spurious Path Counterexample • T = (a1,…an) - a path abstract counterexample h-1(a) = { s | h(s) = a }

31. Checking for Spurious Path Counterexample (cont.) The set of concrete counterexamples corresponding to T = (a1,…an) : h-1(T) = { (s1,…sn) | ih(si)=ai  I(s1)  iR(si,si+1) } Ish-1(T)empty?

32. dead-end Checking for Spurious Path Counterexample Th is spurious 

33. Refining the abstraction • Refinement separates dead-end states from bad states, thus, eliminates the spurious transition from ai-1 to ai

34. Three-ValuedAbstraction Refinement (TVAR) for Full CTL* [SG03,GLLS05] Thanks to Sharon Shoham for the slides on TVAR

35. Goal:Logic preservation for CTL* Theorem If MA is an abstraction of MCthen for every CTL* formula , MA|=  MC|= MA|  MC| • But sometimes[MA|=  ] = don’t know

36. Abstract Models for CTL* • Two transition relations [LT88] • Kripke Modal Transition System (KMTS) • M = (S, S0, Rmust, Rmay, L) • Rmust: an under-approximation • Rmay: an over-approximation • Rmust ⊆ Rmay

37. Abstract Models for CTL* (cont.) Labeling function : • L: S→ 2Literals • Literals = AP ⋃ {p | pAP } • At most one of p and p is in L(s). • Concrete: exactlyone of p and p is in L(s). • KMTS: possibly none of them is in L(s).

38.    Abstract Models for CTL* (cont.) Labeling of abstract states ¬p MA p MC ¬p p p ¬p p ¬p ¬p p

39. must: under approximation () may: over approximation ()    Abstract Models for CTL* (cont.) must and may transitions: MA MC

40. 3-Valued Semantics • Universal properties (A): - Truth is examined along allmay-successors -Falsity is shown by a single must-successor • Existential properties (E): - Truth is shown by a single must-successor - Falsity is examined along allmay-successors

41. tt, ff are definite 3-Valued Framework • Additional truth value: (indefinite) • Abstraction preserves both truth and falsity • (abstract) sa represents (concrete) sc: •  is true in sa⇒ is true in sc •  is false in sa⇒ is false in sc •  is  in sa⇒ the value of  in sc is unknown [BG99]

42. M and  generateinitial abstraction MA [MA |=3] = tt,ff model check refinement [MA|= 3] =  stop find and analyze failure node The TVAR Methodology

43. M: s t p, q p,q  = AXp EXq 3-Valued Model Checking:Example

44. M: s t p, q p,q  = AXp EXq MC graph (s, AXpEXq) (s, AXp) (s, EXq) (s, p) (t, p) (s, q) (t, q)

45. M: s t p, q p,q  = AXp EXq 7 tt ff ⊥ 5 6 reason for unknown: may-son - not enough to verify - prevents refutation 1 2 3 4 Coloring the MC graph (s, AXpEXq) (s, AXp) (s, EXq) (s, p) (t, p) (s, q) (t, q)

46. Abstraction-Refinement • Traditional abstraction-refinement is designed for 2-valued abstractions: • True holds in the concrete model. • False may be a false alarm. ⇒ Refinement is needed when the result is false and is based on a counterexample analysis.

47. 3-Valued Model Checking Results • ttandff are definite: hold in the concrete model as well. • ⊥ is indefinite ⇒ Refinement is needed.

48.    Refinement • As for the case of 2-values, done by splitting abstract states MA MC

49. Refinement • Identify a failure state: a state sa for which some subformula is  in sa • Done during model checking • Split sa so that • an indefinite atomic proposition becomes definite (true or false), or • A may transition becomes a must transition or disappears

50. Refinement (cont.) • Uses the colored MC graph • Find a failurenodenf: • a node colored  whereas none of its sons was colored  at the time it got colored. • the point where certainty was lost • purpose: change the  color of nf . Refinement is reduced to separatingsubsets of the concrete states represented by nf.