1. Automatic Predicate Abstraction of C-Programs T. Ball, R. Majumdar T. Millstein, S. Rajamani

2. Overview (1) Motivation: Software systems typically infinite state –model checking finite state  check an abstraction of a software system Automatic predicate abstraction: –1st proposed by Graf & Saidi –concrete states mapped to abstract states under a finite set of predicates –designed and implemented for finite state systems infinite state systems specified as guarded commands –not implemented for a programming language such as C The C2BP tool: –performs automatic predicate abstraction of C programs –given (P, E)  BP(P, E) boolean program (P: C program, E: finite set of predicates)

3. Overview (2) Boolean program BP(P, E): a C program with bool as single type –plus some additional constructs –same control structure as P –contains only |E| boolean variables, one for each predicate in E –e.g. (x<y)  E  {x<y} is a boolean variable for BP(P, E). then: {x<y} is true at program point P  (x<y) is true at P –transfer function: automatically for each statement s in P conservatively represents the effect of s on predicates in E BEBOP model checker: –used to analyze the boolean program –performs interprocedural dataflow analysis using binary dicision diagrams (BDDs)

4. Results from applying C2BP Pointer manipulating programs: identify invariants involving pointers –more precise alias information than with a flow sensitive alias analysis –structural properties of the heap preserved by list manipulating code Examples on proof-carrying code: to identify loop invariants SLAM toolkit: to check safety properties of windows NT device drivers –C2BP & BEBOP to statically determine whether or not an assertion violation can take place in C-code –demand-driven abstraction-refinement to automatically find new predicates for a particular assertion –convergence (undeniability) was not a problem on all Windows NT drivers checked

5. Challenges of predicate abstraction in C (1) Pointers: two related subproblems treated in a uniform way –assignments through dereferenced pointers in original C-program –pointers & pointer-dereferences in the predicates for the abstraction Procedures: allow procedural abstraction in boolean programs. They also have: –global variables –procedures with local variables –call-by-value parameter passing –procedural abstraction – signatures constructed in isolation Procedure calls: abstraction process is challenging in the presence of pointers –after a call the caller must conservatively update local state modified by procedure –sound and precise approach that takes side-effects into account Make both abstraction and analysis more efficient by exploiting procedural abstraction.  recursive proc. e.g. inlining

6. Challenges of predicate abstraction in C (2) Unknown values: it is not always possible to determine the effect of a statement in the C-program in terms of the input predicate set E –such nondeterminism (  ) handled in BP with * (non-determenistic choice) which allows to implicitly express 3-valued domain for boolean variables Precision-efficiency tradeoff: computing abstract transfer function for a statement s in the C-program with respect to the set E of predicates may require the use of a theorem prover –O(2^|E|) calls to the theorem prover –apply optimization techniques to reduce this number

7. Predicate abstraction overview PA Problem: given (P, E) where –P is a C-program –E = {φ 1, …, φ n } is a set of pure boolean C-expressions over variables and constants of the C-language Compute BP(P, E) which is a boolean program that –has some control structure as P –contains only boolean variables V = {b 1, …, b n } where b i = {φ i } represents predicate φ i –guaranteed to be an abstraction of P (superset of traces modulo …) Assumption over a C-program: –all interprocedural control flow is by if and goto –all expressions are free of side-effects & short-circuit evaluation –all expressions do not contain multiple pointer dereferences (e.g. **P) –function calls occur at topmost level of expressions

8. Weakest precondition and cube (monoids) Weakest precondition WP(s, φ): {ψ} s {φ} –the weakest predicate whose truth before s entails truth of φ after s terminates (if it terminates) –assignment: WP(x=e, φ) = φ[e/x] (no side-effects) Example: WP(x=x+1, x<5) = (x<5)[x+1/x] = x+1 < 5 = x<4 –central to predicate abstraction: p: s andφ i  E p’:WP(s, φ i ) = true b j = {WP(s, φ i )} C-codeBP(P, E) code However, no such bj may exist if WP(s, φ)  E Example: E = {(x<5), (x=2)} WP(x=x+1, x<5) = x <4  E  strengthen the predicate by using DP x=2  x<4use x=2 instead p: if (b j ) then b i = true p‘:

9. Strengthening and weakening Cube over V: a conjunction c i 1  …  c i k where c i 1  {b i j,  b i j } for b i j  V Concretization function ε: ε(b i ) = φ i, ε(  b i ) =  φ i –extend ε over disjunction of cubes in natural way Predicate F v (φ): largest disjunction of cubes c over V so that ε(c)  φ –F v (φ) = { Vc i | c i  cubes_over(V)  ε(c i )  φ} Strengthening of φ: ε(F v (φ)) –weakest predicate over ε(V) that implies φ –Example: ε(F v (x<4)) = (x=2) Weakening of φ: ε(G v (φ)) where G v (φ) = F v (  φ) –ε(G v (φ)) is the strongest predicate over ε(V) implied by φ Theorem prover: for each cube, check implication  decision procedure –Simplify & Vampyre: equational (Nelson-Oppen) style provers