Reduction in End-User Shape Analysis Bor-Yuh Evan Chang University of Colorado, Boulder Xavier Rival INRIA and ENS Paris Abstract: Xisa is a shape analyzer parametrized by user-provided data structure definitions that guide the analysis abstraction. These definitions come in the form of data structure validation code, which are interpreted as inductive definitions in separation logic. The user may provide different definitions that correspond to equivalent or related concretizations, which makes the framework quite expressive. However, as a consequence, we must deal with multiple possible abstractions at any point during the program analysis. In this talk, we observe that interestingly, we can derive lemmas about related abstractions by applying and reusing our parametric abstract domain on the user-provided data structure definitions (that will then be its input for the program analysis). Such lemmas are needed by a reduction operator for Xisa that converts between abstractions during the program analysis phase. Dagstuhl - Typing, Analysis, and Verification of Heap-Manipulating Programs – July 24, 2009 If some of the symbols are garbled, try either installing TexPoint (http://texpoint.necula.org) or the TeX fonts (http://www.cs.colorado.edu/~bec/texpoint-fonts.zip).

Why think about the analyzer’s end-user? Tool Accessibility end-users are not experts in verification and logic want adoption of our tools and techniques Why do we care about the end-user of our analyzer? The most obvious reason is accessibility. But perhaps more importantly and why we are interested, end-users are not completely incompetent either. By interacting with users, we hope to improve expressivity, efficiency, and feasibility of program analysis. Expressivity, Efficiency, and Feasibility end-users are not completely incompetent either can provide guidance to tools, understand the code best Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Summaries and their operations Shape analysis is an abstract interpretation on abstract memory descriptions with … Splitting of summaries (materialization) To reflect updates precisely And summarizing for termination (summarization) cur l “sorted dl list” Main Design Decision: Summaries and their operations cur l cur l cur l Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

The Wild Wild World of Shape Analysis Choosing the heap abstraction difficult Some representative approaches: Parametric in low-level, analyzer-oriented predicates + Very general and expressive - Harder for non-expert TVLA [Sagiv et al.]  Built-in high-level predicates - Harder to extend + No additional user effort Space Invader [Distefano et al.] Our approach: Parametric in high-level, developer-oriented predicates + Extensible + Targeted to developers Xisa Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Our Approach: Executable Specifications Utilize “run-time validation code” as specification for static analysis. Build the abstraction for analysis directly out of the developer-supplied validation code h.dll(p) := h = null Æ emp Ç 9n. h@prev  p ¤ h@next  n ¤ n.dll(h) h.dll(p) := if (h = null) then true else h!prev = p and h!next.dll(h) checker assert(l.purple_dll(null)); for each node cur in list l { make cur red; } assert(l.red_dll(null)); l Automatically generalize checkers for intermediate states (generalized segment) cur l p specifies where prev should point l Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Xisa is … An automated shape analysis with a precise memory abstraction based around invariant checkers. Xisa h.dll(p) = if (h = null) then true else h!prev = prev and h!next.dll(h) checkers Extensible and targeted for developers Parametric in developer-supplied checkers—viewed as inductive definitions in separation logic Precise yet compact abstraction for efficiency Data structure-specific based on properties of interest to the developer Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Problem: Non-Unique Representations With user-guided abstraction, different summaries may have the same (or related) concretizations. l.dll(p) := if (l = null) then true else l!prev = p and l!next.dll(l) l.dll_back(n) := if (l = null) then true else l!next = n and l!prev.dll_back(l) checker dll(null) h dll(null) h dll_back(null) t dll_back(null) t summary h t concrete instance Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Need: Convert between related summaries Prove lemmas about related checkers e.g., “dll , dll_back” Observation: Our widening operator can derive these facts on an appropriate program Basic Idea: l.dll(p) := … semantics of dll_back parametric abstract domain summarization (widening) S Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Need: Convert between related summaries Find out which lemmas are needed and when to apply them during program analysis work-in-progress not in this talk Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

New “Pre-Program Analysis Analysis” checker analysis (“pre-program analysis”) program analysis Derives information about checkers to use them effectively Xisa shape analyzer abstract interpretation level-type inference for unfolding splitting and interpreting update dll(h, p) = if (h = null) then true else h!prev = prev and dll(h!next, h) checkers summarizing lemma proving for reduction Overall, we have a new “pre-program analysis analysis”. And interestingly, this new phase shares the same abstract domain as the program analysis. S S Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Outline Memory abstraction A semantics of checker definitions Example: graphs segments A semantics of checker definitions Example: a segment of a list , a list segment Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Abstract memory as graphs Make endpoints and segments explicit ° cur l “dll segment” dll(±, °) ® ¯ ± memory address (value) memory cell (points-to: °!next = ±) checker summary (inductive pred) Some number of memory cells (thin edges) l ® segment summary cur ° ± dll(null) dll(¯) ¯ prev next h.dll(p) = if (h = null) then true else h!prev = p and h!next.dll(h) dll(°) Segment generalization of a checker (Intuitively, ®.dll(null) up to °.dll(¯).) (®.dll(null) ¤= °.dll(¯)) ¤ °@prev  ¯ ¤ °@next  ± ¤ ±.dll(°) Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Segments as Partial Checker “Runs” (conceptually) Summary i ® ¯ c(°) c0(°0) ® dll(null) dll(¯) ° Instance ® ¯ next prev null next ° ± prev null null Complete Checker “Run” i ®.dll(null) ¯.dll(®) c(®,°) … i = 0 ® = ° ¯ = null °.dll(¯) ±.dll(°) null.dll(±) c = c0 ® = ¯ ° = °0 c0(¯,°0) [POPL’08] Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Outline Memory abstraction A semantics of checker definitions Example: graphs segments A semantics of checker definitions Example: a segment of a list , a list segment Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Example: User-Defined List Segments l.ls(e) := if (l = e) then true else l!next.ls(l) l.list() := if (l = null) then true else l!next.list() checker ls(¯) ® l ¯ e ® list() ¯ summary l e “a list segment” “a segment of a list” Want a decision procedure for these inclusions: v ? ls(¯) ® l ¯ e list() Can reuse our parametric abstract domain! Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

An Alternative Semantics for Checkers summary generator of “concrete” graphs ls(¯) ® l ¯ e ® l ¯ e ® = ¯ ° ® l next ®0 ¯ e ®0 = ¯ ¯ e ®00 = ¯ ® l next ®0 ®00 … set of concrete stores … l e addrof(®) addrof(¯) Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

X v Show r r Widening … Properties ls(¯) ® l ¯ e list() Widening Properties Soundness: computes an over-approximation Termination: ensures chain stabilizes Algorithm Iteratively split regions by matching nodes (ok by ¤) Find common abstraction for matched regions (calling on v to check inclusion) [SAS’07] ® l ¯ e ® = ¯ r ® l ¯ e list() ® l next ®0 ¯ e ®0 = ¯ r ® l ¯ e list() ¯ e ®00 = ¯ ® l next ®0 ®00 X Our widening is a non-symmetric binary operator interleaves region matching and summarizing … Apply abstract interpretation using only list as a checker parameter to the domain Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

v Inclusion Check Inclusion Check Algorithm Iteratively split regions by matching nodes Check inclusion by unfolding and matching edges until obvious (emp v emp) ® l next ®0 ® l next ®0 ¯ e ®0 = ¯ v ® l ¯ e list() ® l next ®0 ® l next ®0 ¯ e list() ®0 = ¯ ¯ e ® l next ®0 Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Summary: Reuse domain to decide relations amongst checker definitions checker analysis (“pre-program analysis”) program analysis Xisa shape analyzer abstract interpretation level-type inference for unfolding splitting and interpreting update dll(h, p) = if (h = null) then true else h!prev = prev and dll(h!next, h) checkers summarizing lemma proving for reduction S S Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

Conclusion and Next Steps Non-unique representation problem magnified with user-supplied checkers Need reduction to convert between representations Ordering on checkers needed to apply reduction Ordering shown by applying Xisa to a checker def To put into practice Needed lemmas: pre-compute ordering or on-demand? When to apply: level types for unfolding may help Derive new checkers (e.g., dll_back from dll)? Bor-Yuh Evan Chang and Xavier Rival - Reduction in End-User Shape Analysis

http://xisa.cs.berkeley.edu