1 / 30

Concrete Model Checking with Abstract Matching and Refinement

Concrete Model Checking with Abstract Matching and Refinement. Corina Păsăreanu QSS, NASA Ames Research Center Radek Pelánek Masaryk University, Brno, Czech Republic Willem Visser RIACS/USRA, NASA Ames Research Center. Introduction. Abstraction in software verification

annisk
Télécharger la présentation

Concrete Model Checking with Abstract Matching and Refinement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Concrete Model Checking with Abstract Matching and Refinement Corina Păsăreanu QSS, NASA Ames Research Center Radek Pelánek Masaryk University, Brno, Czech Republic Willem Visser RIACS/USRA, NASA Ames Research Center

  2. Introduction • Abstraction in software verification • Used to reduce data domains of a program • Described as abstract interpretation • Classic approach: over-approximation • SLAM, Blast, Magic; see also Bandera, Feaver • Preserves true results • Abstract counter-examples may be infeasible • Counter-example based iterative refinement Our approach: • Under-approximation based abstraction with refinement • Goal: error detection • Explores only feasible system behaviors • Preserves errors of safety properties • Iterative refinement based on checking “exactness” of abstraction

  3. Predicate Abstraction • Maps a (possibly infinite state) concrete transition system into a finite state system • Via a set of predicates: Preds = {p1, p2 … pn} • Abstraction function a: ConcreteStates → BitVectors • a(s) = b1b2…bn, bi=1  s╞ pi Traditional approaches: • May abstract transitions: • Over-approximate concrete transitions • a1 →may a2 :  s1 s.t. a(s1)= a1 and  s2 s.t. a(s2)=a2, s.t. s1 → s2 • Must abstract transitions: • Under-approximate concrete transitions • a1 →must a2 : s1 s.t. a(s1)= a1,  s2 s.t. a(s2)=a2 and s1 → s2 • Compute may/must transitions automatically: • Use a theorem prover/decision procedure: require 2n × n × 2 calls

  4. Our Approach Concrete search with abstract matching: • Traverse the concrete system • For each explored concrete state • Store abstract version of the state • Use predicate abstraction • Abstract state used to determine if the search should continue or backtrack • Does not build abstract transitions • It executes the concrete transitions directly • Decision procedure invoked during refinement: • At most 2 calls for each explored transition

  5. Example A,0 A,p A,p B,1 C,0 B,p C,p B,p C,p D,1 D,0 D,p D,p E,2 E,1 E,!p E,p May abstractionp = (x < 2) Over-approximation Must abstractionp = (x < 2) Under-approximation Concrete system

  6. p p p B,1 D,1 E,2 !p Example A,0 A,p A,p A,0 B,1 C,0 B,p C,p B,p C,p D,1 D,0 D,p D,p E,2 E,1 E,!p E,p Concrete search w/ abstract matchingp = (x < 2) May abstractionp = (x < 2) Over-approximation Must abstractionp = (x < 2) Under-approximation Concrete system

  7. p p p p B,1 C,0 D,0 D,1 E,2 !p Example A,0 A,p A,p A,0 B,1 C,0 B,p C,p B,p C,p D,1 D,0 D,p D,p E,2 E,1 E,!p E,p Concrete search w/ abstract matchingp = (x < 2) May abstractionp = (x < 2) Over-approximation Must abstractionp = (x < 2) Under-approximation Concrete system

  8. p p p B,1 C,0 D,0 D,1 p E,2 abstraction not “exact” !p Example A,0 A,p A,p A,0 B,1 C,0 B,p C,p B,p C,p D,1 D,0 D,p D,p E,2 E,1 E,!p E,p Concrete search w/ abstract matchingp = (x < 2) May abstractionp = (x < 2) Over-approximation Must abstractionp = (x < 2) Under-approximation Concrete system

  9. p p p p abstraction not “exact” !p p,!q Example A,0 A,p A,p A,0 A,0 p,q B,1 C,0 B,p C,p B,p C,p B,1 B,1 C,0 C,0 p,q p,q D,0 D,0 D,1 D,0 D,p D,p D,1 D,1 p,q E,2 E,1 E,!p E,p E,2 E,2 E,2 p,!q !p,!q refine Concrete search w/ abstract matchingp = (x < 2) q = (x < 1) May abstractionp = (x < 2) Over-approximation Must abstractionp = (x < 2) Under-approximation Concrete search w/ abstract matchingp = (x < 2) Concrete system

  10. (Concrete) Search Algorithm PROCEDURE dfs() BEGIN add(s0, VisitedStates); push(s0, Stack); WHILE ! empty(Stack) DO s = pop(Stack); FOR all transitions t enabled in s DO s' = successor(s, t); IF s' NOT IN VisitedStates THEN add(s', VisitedStates); push(s', Stack); FI; OD; OD; END;

  11. Search w/ Abstract Matching PROCEDURE aSearch ( Preds ) BEGIN add(αPreds (s0), VisitedStates); push(s0, Stack); WHILE ! empty(Stack) DO s = pop(Stack); FOR all transitions t enabled in s DO s' = successor(s, t); IF αPreds (s') NOT IN VisitedStates THEN add(αPreds (s'), VisitedStates); push(s', Stack); FI; OD; OD; END;

  12. A,2 A,2 x>0 x+1>0True x>0 x-1>0 False x=x+1 x=x-1 wp(x>0,x=x+1) wp(x>0,x=x-1) B,3 B,1 x>0 x>0 Abstraction Refinement Check if abstraction is exact with respect to each transition t: s  s’ • Check if the induced abstract transition is a must transition w/ a decision procedure • If not, add new predicates • Use weakest precondition calculations a(s)  wp(a(s’),t) Abstraction is refined Add new predicate (x-1>0) from failed check and repeat aSearch Abstraction is exact

  13. Iterative Refinement • Check if bad state erris reachable BEGIN Preds = ; WHILE true DO aSearch(Preds); /* during aSearch perform: • IF erris reachable THEN output counterexample FI; • check if abstraction is exact for each transition • NewPreds = newly generated predicates from failed checks */ IF NewPreds =  THEN output unreachable FI; Preds = Preds ∪ NewPreds; OD; END;

  14. Correctness and Termination • In general • The iterative algorithm might not terminate • If it terminates • It finds an error or • It computes a finite bisimilar structure • Refinement is non-monotonic • If a finite (reachable) bisimulation quotient exists then • It will eventually compute a finite bisimilar structure • May still fail to terminate

  15. p = (y ≥ 0) q = (x+y ≥ 0) r = (2x+y ≥ 0) A,p A,p,q A,p,q,r p = (y ≥ 0) q = (x+y ≥ 0) p = (y ≥ 0) B,p B,p,q B,p,q,r … C,p y = x + y C,p,q C,p,q,r Pathological Example • The algorithm may not terminate even for systems with finite (reachable) states • Example (check “D is unreachable”): A: x = 0; y = 0; B: while (y >= 0) C: y = x + y; D: Heuristic to enforce termination

  16. Implementation • Implementation for simple guarded command language • PERL, OCAML • Uses SIMPLIFY as a decision procedure • Working on integrating the technique in Java PathFinder (JPF) model checker • Supports symbolic execution - using the Omega Library • Use forward (instead of backward) refinement • Handle dynamic data structures

  17. Applications • Property verification for the Bakery mutual exclusion protocol • Search order matters 5 iterations for breadth first search order 4 iterations for depth first search order • Error detection in RAX (Remote Agent Executive) • Component extracted from an embedded spacecraft-control application • Deadlocked in space • Error found faster than over-approximation based analysis • Test input generation for Java container classes using JPF • Abstract matching but no refinement • Explore method call sequences • Match states between calls to avoid generation of redundant tests • Better testing coverage as compared to other methods

  18. Related Work • Refinement of under-approximations • For SAT based bounded model checking – Grumberg et al. [POPL’05] • May and must abstractions • Branching time properties – Godefroid et al [Concur’01] • “Hyper” must transitions for monotonicity – Shoham and Grumberg [TACAS’04] • Dams and Namjoshi, de Alfaro et al [LICS’04], Ball et al [CAV’05] • Our previous work – choice free search [TACAS’01] • Model driven software verification • Use abstraction mappings during concrete model checking – Holzmann and Joshi [SPIN’04] • Over-approximation based predicate abstraction

  19. Conclusions • Model checking algorithm • Under-approximation refinement • Integrates abstract analysis with concrete program execution • Uses decision procedure to detect incompleteness of abstraction and to refine the abstraction • Comparison with standard over-approximation abstraction • Finds errors faster (potentially) • More efficient (in the number of theorem prover calls) • Complementary, should be combined • Prototype implementation • Used for the analysis of concurrent programs • Future work • Complex properties (e.g. liveness), backward vs. forward refinement, • Evaluation, better criteria for termination

  20. Applications • Property verification for the Bakery mutual exclusion protocol • Search order matters 5 iterations for breadth first search order 4 iterations for depth first search order

  21. Applications • Error detection in RAX (Remote Agent Executive) • Component extracted from an embedded spacecraft-control application • Deadlocked in space • Error found in one iteration (BFS) • Error found faster than over-approximation based analysis

  22. Applications • RAX: also tried to compute bisimilar structure • Algorithm does not terminate • Keeps refining unreachable state space • Added two new predicates: e1≥0, e2≥0 • Algorithm terminates after 3 iterations

  23. Applications • Test input generation for Java container classes using JPF • Abstract matching but no refinement • Explore method call sequences • Match states between calls to avoid generation of redundant tests • Better testing coverage as compared to other methods • Coverage highly dependent on abstraction • Automatic refinement essential

  24. SUT (Java container) API put remove … Env (M, N, A) M = seq. length of API calls [0,N) = range of input values A = specifies the abstraction Test case: put(1); put(0); remove(0); Model checking Explore call sequences Measure coverage Generate test cases Applications • Test input generation for Java containers • Abstract matching but no refinement • Match states between API calls • Better testing coverage as compared to other methods • Coverage highly dependent on abstraction • Automatic refinement essential

  25. Non-monotonic Refinement State space explored Refinement Matched

  26. Non-monotonic Refinement Refinement

  27. Explanation • Bisimulation: symmetric relation ~ • s ~ s’ iff for every s → s1 there exists s’→ s1’ s.t. s1 ~ s1’ • Two transition systems are bisimilar if • Their initial states are bisimilar • ~ induces a quotient transition system • States are equivalence classes • A → B if there exist s in A and s’ in B s.t. s → s’

  28. … … x>0 x>0 1 2 1 2 x=x-1 x=x+1 … … x>0 x≤0 0 1 x>0 2 3 Predicate Abstraction • Maps a (possibly infinite state) concrete transition system into a finite state system • Via a set of predicates: Preds = {p1, p2 … pn} • Abstraction function: a: ConcreteStates → BitVectors • a(s) = b1b2…bn, bi=1  s╞ pi May abstract transitions: Must abstract transitions: Over-approximate concrete Under-approximate concrete transitions transitions • Compute may/must transitions automatically: • Use a theorem prover/decision procedure: require 2n × n × 2 calls

  29. State space: Refinement Concrete System Comparison Over-approximation Based Predicate Abstraction Our approach State space: Refinement Concrete System • Show property holds • Over-approximation based • Counter-example driven refinement • Expensive computation to calculate abstraction • Find defects • Under-approximation based • Abstraction driven refinement • Simple computation to calculate abstraction mapping

  30. To say: • Reachability properties • We don’t abstract the program counter

More Related