Adapting Side-Effects Analysis for Modular Program Model Checking

1. Adapting Side-Effects Analysis for Modular Program Model Checking M.S. Defense Oksana Tkachuk Major Professor: Matthew Dwyer Support US National Science Foundation (NSF CISE/SEL) US Department of Defense Advanced Research Projects Agency (DARPA/IXO PCES) US Army Research Office (ARO CIP/SW)

2. Software Model Checking • Problems • State space explosion due to large data domains • Solutions • Reduction • Abstraction • Modular Verification

3. Modular Verification Unit Unit • Break the entire system into modules and verify one at a time. Module under analysis is called unit • Unit is not self-executable system, need to model environment Code Base

4. Environment Generation Problem • In OO (Java) systems, boundaries and interactions between unit and environment are complex • Control effects: invoking of methods • Data effects: passing data and modifying data Unit • Locking, exceptions, global references • Hard to identify interaction points Code Base

5. Solutions in Bandera Environment Generator (BEG) • Finds points of interaction (unit interface) • Identifies environment classes that directly interact with the unit • Cuts away classes that don’t directly interact with the unit • Generates models for the remaining classes Unit Code Base

6. Environment Models • Universal environments • Safe but impractical • Environment assumptions may be used to generate more precise environments • User supplied • Automatically extracted from environment implementation using static analysis techniques

7. Modular Verification Drivers Unit Stubs Java + modeling primitives Environment classes are broken into • Active classes hold a thread of control (drivers) • Passive classes (stubs) + Unit Properties  Java Model Checker Closed Unit Code Base

8. Current State of Tool Support • Generation of universal stubs and drivers • Generation of drivers from • assumptions (LTL,Regular Expressions) • future work: customized control flow analysis • Generation of stubs from • assumptions (Java-like exprs/assignments) • static analysis results • side-effects analysis to calculate data effects • future work: control effects, safe locks

9. In This Talk… • Identifying environment data effects using a customized side-effects analysis • Identifying the unit • Identifying environment • Analyzing environment • Modeling environment from analysis results

10. Identifying the unit/environment Unit Stubs • The unit is user defined based on properties to be checked • BEG scans the unit for external references that drive generation of environment classes

11. Analyzing Environment • Staged Analysis • Scope-based analysis to eliminate methods that can’t side-effects the unit data • Points-to analysis to approximate objects pointed to by a reference variable in store statements (l.f = r, l[i]=r) • Side-Effects analysis to detect side-effects on the unit data through store statements

12. Detecting Independent Methods Unit Stubs • BEG builds a call graph for environment methods immediately called from unit Call Graph • Excluding the methods that can’t effect unit data based on scope analysis

13. Side Effects Analysis • Traditional side-effects analyses are designed to calculate the set of memory locations that may be modified by method execution • Do not approximate the values that are assigned in a store statement (l.f = r, l[i]=r) • Do not distinguish between unit and environment locations • Are usually designed to be fast rather than precise

14. BEG Side-Effects • Tracks side-effects to unit locations, ignores side-effects to environment locations • Tracks the value on the right hand side of side effecting statements (l.f = r, l[i] = r) • Increases precision • Flow and context-sensitivity (parameterized) • Access-path based with user controlled k-limiting • Tracking type and reachabilty of unit locations • Calculating must side-effects • Incorporating return sensitivity

15. Example class Node { Node next; Data data; … } class … { … void m(Node n, Data d) { n.next.next.data = d; } } t = n.next; t = t.next; t.data = d;

16. Assignments through References n.next.next.data = d; n d t = n.next; t = t.next; t.data = d; next // data // t

17. Assignments through References n.next.next.data = d; n d t = n.next; t = t.next; t.data = d; next // data // t

18. Assignments through References n.next.next.data = d; n d t = n.next; t = t.next; t.data = d; next // data // t

19. Assignments through References n.next.next.data = d; n d t = n.next; t = t.next; t.data = d; next // data // t

20. 1-limited Analysis n.next.next.data = d; n d t = n.next; t = t.next; t.data = d; next // data // t

21. 1-limited Analysis n.next.next.data = d; n d t = n.next; t = t.next; t.data = d; next // data // t

22. 1-limited Analysis with Reachability n.next.next.data = d; n t = n.next; t = t.next; t.data = d; d next // data // t

23. 1-limited Analysis with Reachability n.next.next.data = d; n t = n.next; t = t.next; t.data = d; d next // data // t

24. Abstract Access Paths • Roots: static fields, formal parameters, new instances • We restrict the tracking of access paths through unit fields • The language of abstract access paths

25. Extension Operator r r root root   l=r.f ) f f l l ? r!, l!.f ) r!

26. Extension Operator r r root root   l=r.f ) f f l l

27. Prefixing Operator arg arg root p’ ret’  ’(p’) p’ ret’ ’(p’) l p’ arg root  l = C.m’(arg) return ret’ arg

28. Prefixing Operator arg root p’ ret’  ’(p’) l

29. Prefixing Operator arg root p’ ret’  ’(p’) l denote

30. Data Flow Frameworks • Join semi-lattice L • Partial ordering v • Merge operator t • Least element ? • Flow, initial point and value • Function Space F of monotone functions over lattice • Mapping from labels to transfer functions f in F

31. Our Analyses Using DFF

32. Pt Analysis Correctness

33. Modeling Environment void m(Node n, Data d) { n.next.next.data = d; } • Example code • Analysis summary • Generated model void m(Node param1, Data param2) { if(Bandera.choose()) Bandera.chooseReachable(param1.next,”Data”) = param2; }

34. Examples and Experience • Container Examples • Identified container properties and how to guide the analysis to preserve such properties in the environment • Replicated Workers • Found a deadlock • Autopilot • Identified mode confusion scenario

35. Related Work • Side-effects analysis [Landi & Ryder] • Parameterized points-to analysis [Liang & Harrold] • Closing open systems [Godefroid] • Generation of environment data [Stoller] • Environment assumption generation [Giannakopoulou et al.]

36. Limitations and Future Work • Assumptions • Atomicity of environment methods • Lack of divergence, indefinite blocking, and lock acquisition in the environment • Designing/reusing analyses to discharge the above assumptions • Designing/reusing analyses for drivers • Integration with Bandera and Bogor • Exploiting richer specifications (e.g., JML)

37. Summary • Overview of BEG capabilities • Presentation of • Side-effects analysis • Environment modeling strategies • BEG work is ongoing • Will be included in the upcoming Bandera release http://beg.projects.cis.ksu.edu