Automatic Predicate Abstraction of C-Programs

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 = {b1, …, bn} where bi = {φ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 Ep’: WP(s, φi) = true bj = {WP(s, φi)}C-code BP(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<4 use x=2 instead p: if (bj) then bi = truep‘:

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