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)

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

Unit Code Base 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

Environment Generation Problem Unit Code Base 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 Hard to identify interaction points Locking, exceptions, global references

Unit Code Base 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 Solutions in Bandera Environment Generator (BEG)

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

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

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 Current State of Tool Support

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

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

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

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

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

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 BEG Side-Effects

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;

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

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

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

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

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

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

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

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

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

Extension Operator root r  l )  l r f r ! r !  r !  l ! .f ) l=r.f f ?

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

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

Prefixing Operator  rootp’ arg l  ’(p’) ret’

Prefixing Operator  rootp’ arg l  ’(p’) ret’ denote

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

Our Analyses Using DFF May PtMust PtMay SeMust Se L P (Var-> P (AbsPath)) P (AbsPath-> P (AbsValue)) vµ¶µ¶ t  ?; Var-> P (AbsPath) ; AbsPath-> P (AbsValue) F Forward Flow, initial statement s 0, initial value ; FfFf F= {f:L ! L j 9 l k, l g :f(l)=(l - l k )  l g } f s (l)=(l-Kill(s))  Gen(s)

Pt Analysis Correctness p ` 11 B semantics 22 R sc ) p ` Pt 1 c B concerete paths Pt 2 c R ca ) p ` Pt 1 a B abstract paths Pt 2 a

Se Analysis Correctness p ` 11 B semantics 22 R sc ) p ` Se 1 c B concerete paths Se 2 c R ca ) p ` Se 1 a B abstract paths Se 2 a

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

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

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.]

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)

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