Underapproximating loops in C programs for fast counterexample detection
 915 Downloads
 2 Citations
Abstract
Many software model checkers only detect counterexamples with deep loops after exploring numerous spurious and increasingly longer counterexamples. We propose a technique that aims at eliminating this weakness by constructing auxiliary paths that represent the effect of a range of loop iterations. Unlike acceleration, which captures the exact effect of arbitrarily many loop iterations, these auxiliary paths may underapproximate the behaviour of the loops. In return, the approximation is sound with respect to the bitvector semantics of programs. Our approach supports arbitrary conditions and assignments to arrays in the loop body, but may as a result introduce quantified conditionals. To reduce the resulting performance penalty, we present two quantifier elimination techniques specially geared towards our application. Loop underapproximation can be combined with a broad range of verification techniques. We paired our techniques with lazy abstraction and bounded model checking, and evaluated the resulting tool on a number of buffer overflow benchmarks, demonstrating its ability to efficiently detect deep counterexamples in C programs that manipulate arrays.
Keywords
Model checking Loop acceleration Underapproximation Counterexamples1 Introduction
The generation of diagnostic counterexamples is a key feature of model checking. Counterexamples serve as witness for the refutation of a property, and are an invaluable aid to the engineer for understanding and repairing the fault.
Counterexamples are particularly important in software model checking, as bugs in software frequently require thousands of transitions to be executed, and are thus difficult to reproduce without the help of an explicit error trace. Existing software model checkers, however, fail to scale when analysing programs with bugs that involve many iterations of a loop. The primary reason for the inability of many existing tools to discover such “deep” bugs is that exploration is performed in a breadthfirst fashion: the detection of an unsafe execution traversing a loop involves the repeated refutation of increasingly longer spurious counterexamples. The analyser first considers a potential error trace with one loop iteration, only to discover that this trace is infeasible. As consequence, the analyser will increase the search depth, usually by considering one further loop iteration. In practice, the computational effort required to discover an assertion violation thus grows exponentially with the depth of the bug.
Notably, the problem is not limited to procedures based on abstraction, such as predicate abstraction or abstraction with interpolants. Bounded model checking (BMC) is optimised for discovering bugs up to a given depth \(k\), but the computational cost grows exponentially in \(k\).
The contribution of this paper is a new technique that enables scalable detection of deep bugs. We transform the program by adding a new, auxiliary path to loops that summarises the effect of a parametric number of iterations of the loop. Similar to acceleration, which captures the exact effect of arbitrarily many iterations of an integer relation by computing its reflexive transitive closure in one step [4, 8, 11], we construct a summary of the behaviour of the loop. By symbolically bounding the number of iterations, we obtain an underapproximation which is sound with respect to the bitvector semantics of programs. Thus, we avoid false alarms that might be triggered by modeling variables as integers.
In contrast to related work, our technique supports assignments to arrays and arbitrary conditional branching by computing quantified conditionals. As the computational cost of analysing programs with quantifiers is high, we introduce two novel techniques for summarising certain conditionals without quantifiers. The key insight is that many conditionals in programs (e.g., loop exit conditions such as \(\mathtt{i}\le 100\) or even \(\mathtt{i}\ne 100\)) exhibit a certain monotonicity property that allows us to drop quantifiers.
Our approximation can be combined soundly with a broad range of verification engines, including predicate abstraction, lazy abstraction with interpolation [19], and bounded software model checking [5]. To demonstrate this versatility, we combined our technique with lazy abstraction and the Cbmc [5] model checker. We evaluated the resulting tool on a large suite of benchmarks known to contain deep paths, demonstrating our ability to efficiently detect deep counterexamples in C programs that manipulate arrays.
2 Outline
2.1 Notation and preliminaries
Predicate transformers for simple program statements and paths
Path  Strongest postcondition  Weakest liberal precondition 

\(\pi \)  \( sp({\pi },{P}) \)  \( wlp\left( {\pi },{Q}\right) \) 
\(\varepsilon \) / skip  \(P\)  \(Q\) 
x:= \(e\)  \(\exists {}^{\backprime }\mathtt{x}\,.\,(\mathtt{x}=e[\mathtt{x}/{}^{\backprime }\mathtt{x}])\wedge P[\mathtt{x}/{}^{\backprime }\mathtt{x}]\)  \(Q[\mathtt{x}/e]\) 
x:=*  \(\exists {}^{\backprime }\mathtt{x},v\,.\,(\mathtt{x}=v)\wedge P[\mathtt{x}/{}^{\backprime }\mathtt{x}]\)  \(\forall v\,.\,Q[\mathtt{x}/v]\) 
[\(R\)]  \(P\wedge R\)  \(R\Rightarrow Q\) 
assert( \(R\) )  \(P\wedge R\)  \(R\Rightarrow Q\) 
\(\pi _1\) ; \(\pi _2\)  \( sp({\pi _2},{ sp({\pi _1},{P})}) \)  \( wlp\left( {\pi _1},{ wlp\left( {\pi _2},{Q}\right) }\right) \) 
\( sp({\pi _1},{P}) \vee sp({\pi _2},{P}) \)  \( wlp\left( {\pi _1},{Q}\right) \wedge wlp\left( {\pi _2},{Q}\right) \) 
2.2 A motivating example
A common characteristic of many contemporary symbolic software model checking techniques (such as counterexampleguided abstraction refinement with predicate abstraction [1, 10], lazy abstraction with interpolants [19], and bounded model checking [5]) is that the computational effort required to discover an assertion violation may increase exponentially with the length of the corresponding counterexample path (c.f. [16]). In particular, the detection of assertion violations that require a large number of loop iterations results in the enumeration of increasingly longer spurious counterexamples traversing that loop. This problem is illustrated by the following example.
Example 1
The iterative exploration of increasingly deeper loops primarily delays the detection of assertion violations (c.f. [16]), but can also result in a diverging series of interpolants and predicates if the program is safe (see [12]).
2.3 Approximating paths with loops
 1.
We sensitise an existing tool to detect paths \(\pi \) that repeatedly traverse the loop body B (as illustrated in the left half of Fig. 2). We emphasise that \(\pi \) may span more than one iteration of the loop, and that the branches of B taken by \(\pi \) in different iterations may vary.
 2.
We construct a path \(\mathop {\pi }\limits ^{\leadsto }\) whose behaviour underapproximates Open image in new window . This construction does not correspond to acceleration in a strict sense, since \(\mathop {\pi }\limits ^{\leadsto }\) (as an underapproximation) does not necessarily represent an arbitrary number of loop iterations. Section 3 describes techniques to derive \(\mathop {\pi }\limits ^{\leadsto }\).
 3.
By construction, the assumptions in \(\mathop {\pi }\limits ^{\leadsto }\) may contain universal quantifiers ranging over an auxiliary variable which encodes the number of loop iterations. In Sect. 4, we discuss two cases in which (some of) these quantifiers can be eliminated, namely (a) if the characteristic function of the predicate \(\lnot wlp\left( {\pi ^n},{\mathsf {F}}\right) \) is monotonic in the number of loop iterations \(n\), or (b) if \(\pi ^n\) modifies an array and the indices of the modified array elements can be characterised by means of a quantifierfree predicate. We show that in certain cases condition (a) can be met by splitting \(\pi \) into several separate paths.
 4.
We augment the control flow graph with an additional branch of the loop containing \(\mathop {\pi }\limits ^{\leadsto }\) (Fig. 2, right). Section 5 demonstrates empirically how this program transformation can accelerate the detection of bugs that require a large number of loop iterations.
Example 2
The following presents techniques to compute the underapproximation \(\mathop {\pi }\limits ^{\leadsto }\).
3 Underapproximation techniques
This section covers techniques to compute underapproximations \(\mathop {\pi }\limits ^{\leadsto }\) of Open image in new window such that \(\mathop {\pi }\limits ^{\leadsto }\) is a condensation of the CFG fragment to the right. Formally, we only require that \( sp({\mathop {\pi }\limits ^{\leadsto }},{P}) \Rightarrow \exists n\in \mathbb {N}\,.\, sp({\pi ^n},{P}) \) for all \(P\).
The construction of \(\mathop {\pi }\limits ^{\leadsto }\) has two aspects. Firstly, we need to make sure that all variables modified in \(\mathop {\pi }\limits ^{\leadsto }\) are assigned values consistent with \(\pi ^n\) for a nondeterministic choice of \(n\). Secondly, \(\mathop {\pi }\limits ^{\leadsto }\) must only allow choices of \(n\) for which \(\lnot wlp\left( {\pi ^n},{\mathsf {F}}\right) \) is satisfiable, i.e., the corresponding path \(\pi ^n\) must be feasible.
Our approximation technique is based on the observation that the sequence of assignments in \(\pi ^n\) to a variable \(\mathtt{x}\in \mathtt{X}\) corresponds to a recurrence equation (c.f. Example 2). The goal is to derive an equivalent closed form \(\mathtt{x\mathtt :=}\,f_\mathtt{x}(\mathtt{X}, n)\). While there is a range of techniques to solve recurrence equations, we argue that it is sufficient to consider closedform solutions that have the form of lowdegree polynomials. The underlying argument is that a superpolynomial growth of variable values typically leads to an arithmetic overflow after a small number of iterations, which can be detected at low depth using conventional techniques.
The following subsection focuses on deriving closed forms from a sequence of assignments to scalar integer variables, leaving conditionals aside. Section 3.2 covers assignments to arrays. Conditionals and path feasibility are addressed in Sect. 3.3. Section 3.4 addresses bitvector semantics and arithmetic overflow.
3.1 Computing closed forms of assignments
3.1.1 Syntactic matching
3.1.2 Constraintbased acceleration
The disadvantage of a syntaxbased approach is that it is limited to assignments following a simple pattern. Moreover, the technique is contingent on the syntax of the program fragment and may therefore fail even if there exists an appropriate polynomial representing the given assignments. In this section, we present an alternative technique that relies on a constraint solver to identify the coefficients of the polynomial \(f_\mathtt{x}\).
Lemma 1
A set of vectors \({\mathcal {X}} = \{\mathbf {x}_1, \ldots , \mathbf {x}_n \}\) in vector space \(\mathcal {V}\) is linearly independent if a projection of \({\mathcal {X}}\) onto a subspace \({\mathcal {W}}\) is linearly independent.
Proof
Let \({\mathcal {Y}} = \{ \mathbf {y}_1, \ldots , \mathbf {y}_m \} \) be the projection of \({\mathcal {X}}\) onto \({\mathcal {W}}\). Assume for contradiction that \({\mathcal {X}}\) is linearly dependent, then there is a set of scalars \(a_1, \ldots , a_n\) such that \(\sum _i a_i \mathbf {x}_i = \mathbf{0}\). But when we project onto \({\mathcal {W}}\) we have \(\sum _i a_i \mathbf {y}_i = \mathbf{0}\), contradicting the assumption that \({\mathcal {Y}}\) is linearly independent. \(\square \)
Theorem 1
We can uniquely determine the coefficients for a polynomial over \(k\) variables by evaluating the loop at \(2k+2\) points with \(n \le 2\).
Proof
Induction Assume we have a linearly independent set of \(2\cdot k+2\) equations for \(k\) variables. We can extend the vectors by setting \(x_{k+1}=0\) in the vectors with \(n=0\) and \(n=1\), and by setting \(x_{k+1}=1\) in the vector with \(n=2\). By Lemma 1 this maintains linear independence.
Remark
The construction of underapproximations is not limited to the two techniques discussed above and can be based on other (and potentially more powerful) recurrence solvers. that are commonly applied in compiler construction [23] and in the context of invariant generation (see [14], for instance). While techniques such as [7] support a larger class of recurrence equations, our approach suffices cover the most common cases like linear counters. Given that we restrict acceleration to intervals in which overflows can be ruled out (see Sect. 3.4), there is no necessity to handle loop counters that increase exponentially, as these cases can be handled efficiently by traditional unwinding.
3.2 Assignments to arrays
Notably, the membership test determining whether an array element is modified or not introduces quantifier alternation, posing a challenge to contemporary decision procedures. Section 4 addresses the elimination of the existential quantifier.
3.3 Assumptions and feasibility of paths
The techniques discussed in Sect. 3.1 yield polynomials and constraints representing the assignment statements of \(\pi ^n\), but leave aside the conditional statements which determine the feasibility of the path. In order to guarantee that only states that are reachable in the original program can be reached via accelerated paths, we need to make sure that \(\mathop {\pi }\limits ^{\leadsto }\) is only feasible for values of \(n\) for which \(\pi ^n\) is also feasible. We achieve this by computing a precondition for \(\mathop {\pi }\limits ^{\leadsto }\) that rules out values of \(n\) for which \(\pi ^n\) is not feasible. In the following, we demonstrate how to derive such a precondition \(\lnot wlp\left( {\pi ^n},{\mathsf {F}}\right) \) using the polynomials \(f_\mathtt{x}\) for \(\mathtt{x}\in \mathtt{X}\).
Lemma 2
Proof
Intuitively, the path \(\pi ^n\) is infeasible if for any \(j<n\) the first timeframe of the suffix \(\pi ^{(nj)}\) is infeasible. We prove the claim by induction over \(n\). Due to (3) and (4) we have \(f_\mathtt{X}(\mathtt{X}, 0)=\mathtt{X}\) and \(f_\mathtt{X}(f_\mathtt{X}(\mathtt{X}, n), 1)=f_\mathtt{X}(\mathtt{X}, n+1)\) (for \(n\ge 0\)).
Base case \( wlp\left( {\pi },{\mathsf {F}}\right) \equiv \exists j\in [0,0)\,.\left( wlp\left( {\pi },{\mathsf {F}}\right) \right) [\mathtt{X}/f_\mathtt{X}(\mathtt{X},j)]=\mathsf {F}\)
 The effect of assignments in \(\pi \) on \(Q\) is characterised by \(Q[\mathtt{X}/f_\mathtt{X}(\mathtt{X},1)]\). We obtain:$$\begin{aligned} Q[\mathtt{X}/f_\mathtt{X}(\mathtt{X},1)]\;\equiv & {} \; \exists j\in [0,n1)\,.\left( wlp\left( {\pi },{\mathsf {F}}\right) \right) [\mathtt{X}/f_\mathtt{X}(f_\mathtt{X}(\mathtt{X}, 1),j)]\;\\\equiv & {} \exists j\in [1,n)\,.\left( wlp\left( {\pi },{\mathsf {F}}\right) \right) [\mathtt{X}/f_\mathtt{X}(\mathtt{X},j)]\nonumber \end{aligned}$$

Assumptions in \(\pi \) contribute the disjunct \( wlp\left( {\pi },{\mathsf {F}}\right) \).
We emphasise that our construction (unlike many acceleration techniques such as [11]) does not restrict the assumptions in \(\pi \) to a limited class of relations on integers. The construction of the path (7), however, does require closed forms of all assignments in \(\pi \). Since we do not construct closed forms for array assignments (as opposed to assignments to array indices, c.f. Sect. 3.2), we cannot apply Lemma 2 if \( wlp\left( {\pi },{\mathsf {F}}\right) \) refers to an array assigned in \(\pi \). In this case, we do not construct \(\mathop {\pi }\limits ^{\leadsto }\).
For assignments of variables not occurring in \( wlp\left( {\pi },{\mathsf {F}}\right) \), we augment the domain(s) of the variables X with an undefined value \(\bot \) (implemented using a Boolean flag) and replace \(f_\mathtt{x}\) with \(\bot \) whenever the respective closed form is not available. Subsequently, whenever the search algorithm encounters an (abstract) counterexample, we use slicing to determine whether the feasibility of the counterexample depends on an undefined value \(\bot \). If this is the case, the counterexample needs to be dismissed. Thus, any path \(\mathop {\pi }\limits ^{\leadsto }\) containing references to \(\bot \) is an underapproximation of \(\pi ^n\) rather than an acceleration of \(\pi \).
Example 3
For a path \(\pi \mathop {=}\limits ^{\mathrm{\tiny def}}[\mathtt{x}<10];\,\mathtt{x:=x+1;}\,\mathtt{y:=y^2}\), we obtain the underapproximation \(\mathop {\pi }\limits ^{\leadsto }\equiv n\mathtt{:=*;}\,[\forall j\in [0,n). \mathtt{x}+j<10]\mathtt{;}\, \mathtt{x:=x}+n\mathtt{;}\,\mathtt{y:=}\bot \). A counterexample traversing \(\mathop {\pi }\limits ^{\leadsto }\) is feasible if its conditions do not depend on y.
3.4 Arithmetic overflows
The fact that the techniques in Sect. 3.1 used to derive closed forms do not take arithmetic overflow into account may lead to undesired effects. For instance, the assumption made in Example 2 that the characteristic function of the predicate \((\mathtt{i}+n<\mathtt{BUFLEN})\) is monotonic in \(n\) does not hold in the context of bitvectors or modular arithmetic. Since, moreover, the behaviour of arithmetic over or underflow in C is not specified in certain cases, we conservatively rule out all occurrences thereof in \(\mathop {\pi }\limits ^{\leadsto }\). For the simple assignment \(\mathtt{i\,:=\,i}+n\) in Example 2, this can be achieved by adding the assumption \((\mathtt{i}+n\le 2^l1)\) to \(\mathop {\pi }\limits ^{\leadsto }\) (for unsigned \(l\)bit vectors). In general, we have to add respective assumptions \((e_1\otimes e_2 \le 2^l1)\) for all arithmetic (sub)expressions \(e_1\otimes e_2\) of bitwidth \(l\) and operations \(\otimes \) in \(\mathop {\pi }\limits ^{\leadsto }\).
While this approach is sound (eliminating paths from \(\mathop {\pi }\limits ^{\leadsto }\) does not affect the correctness of the instrumented program, since all behaviours following an overflow are still reachable via nonapproximated paths), it imposes restrictions on the range of \(n\). Therefore, the resulting approximation \(\mathop {\pi }\limits ^{\leadsto }\) deviates from the acceleration \(\pi ^*\) of \(\pi \). Unlike acceleration over linear affine relations, this adjustment makes our approach bitlevel accurate. We emphasise that the benefit of the instrumentation can still be substantial, since the number of iterations required to trigger an arithmetic overflow is typically large.
3.5 Path selection
In the following, we discuss heuristics to select paths \(\pi \) to accelerate. Depending on which model checking technique we are incorporating acceleration into, several path selection strategies are available. Some model checkers already come equipped with a strategy for enumerating paths, for example Impact [19] enumerates paths by iteratively unrolling the CFG of the program under analysis. During this process, if a path is found to be “looping” (i.e. some program location is visited repeatedly) then that path is a candidate for acceleration. By contrast, if we use a model check technique that is not explicitly path based (such as bounded model checking), we must devise a strategy for selecting paths to accelerate.
A necessary condition for \(\pi \) to be acceleratable is that \(\pi ^2\) is feasible, for if it were not, \(\pi ^n\) (for \(n > 1\)) would be infeasible, resulting in a trivial accelerator. Accordingly, paths \(\pi \) for which \(\pi ^2\) is feasible are promising candidates for acceleration. We can find such paths by using symbolic execution to build a system of constraints and solving the system with a SAT solver. Our encoding guarantees that if these constraints have a solution, the solution includes a path \(\pi \) where \(\pi ^2\) is feasible. Our encoding can be easily generalised and applied to paths \(\pi ^k\) with a higher number \(k\) of iterations, though this results in a higher computational effort. In practice, choosing \(k=2\) results in a reliable predictor that enables us to identify candidates efficiently.
Since each of the distinguisher variables \(d_i\) is equal to the shadow distinguisher \(s_i\) at the end of each copy of \(\text {Instr}(L)\), we know that the only feasible paths through this program are those in which both copies took the same path. This path is identified by the values of the \(s_i\). So if there are any feasible paths through this program, they identify a path \(\pi \) such that \(\pi ^2\) in the original program is feasible. We can identify a feasible path through this program by appending the statement assert(false) to the end of the program and using a BMCbased model checker (which ultimately creates a SAT/SMT instance) to check the safety of the constructed program. We can iterate this process to enumerate candidate paths: if we have previously found the paths \(\pi _1, \ldots , \pi _n\) we can add assumptions to the end of our pathenumerating program to prevent the rediscovery of these \(\pi _i\).
4 Eliminating quantifiers from approximations
A side effect of the approximation steps in Sects. 3.2 and 3.3 is the introduction of quantified assumptions. While quantification is often unavoidable in the presence of arrays, it is a detriment to performance of the decision procedures underlying the verification tools. In the worst case, quantifiers may result in the undecidability of path feasibility.
In the following, we discuss two techniques to eliminate or reduce the number of quantifiers in assumptions occurring in \(\mathop {\pi }\limits ^{\leadsto }\).
4.1 Eliminating quantifiers over monotonic predicates
We show that the quantifiers introduced by the technique presented in Sect. 3.3 can be eliminated if the predicate is monotonic in the quantified parameter.
Definition 1
(Representing function, monotonicity) The representing function \(f_P\) of a predicate \(P\) with the same domain takes, for each domain value, the value 0 if the predicate holds, and 1 if the predicate evaluates to false, i.e., \(P(\mathtt{X})\Leftrightarrow f_P(\mathtt{x})=0\). A predicate \(P(n): {\mathbb {N}}\rightarrow {\mathbb {B}}\) is monotonically increasing (decreasing) if its representing function \(f_P(n):{\mathbb {N}}\rightarrow {\mathbb {N}}\) is monotonically increasing (decreasing), i.e., \(\forall m,n\,.\,m\le n\Rightarrow f_P(m)\le f_P(n)\).
We extend this definition to predicates over variables X and \(n\in {\mathbb {N}}\) as follows: \(P(\mathtt{X},n)\) is monotonically increasing in \(n\) if \((m\le n)\wedge P(\mathtt{X}, n)\wedge \lnot P(\mathtt{X}, m)\) is unsatisfiable.
Proposition 1
\(P(\mathtt{X},n1)\equiv \forall i\in [0,n)\,.\, P(\mathtt{X},i)\) if \(P\) is monotonically increasing in \(i\).
The validity of Proposition 1 follows immediately from the definition of monotonicity. Accordingly, it is legitimate to replace universally quantified predicates in \(\mathop {\pi }\limits ^{\leadsto }\) with their corresponding unquantified counterparts (c.f. Proposition 1).
This approach is akin to trace partitioning [9], however, our intent is quantifier elimination rather than refining an abstract domain. We rely on a templatebased approach to identify predicates that can be split (a constraint solverbased approach is bound to fail if \(c\) is symbolic). While this technique effectively deals with a broad number of standard cases, it does fail for quantifiers over array indices, since the array access operation is not monotonic.
4.2 Eliminating quantifiers in membership tests for array indices
This subsection aims at replacing the existentially quantified membership test in Predicate (6) by a quantifierfree predicate. To define a set of sufficient (but not necessary) conditions for when this is possible, we introduce the notion of increasing and dense array indices (c.f. [13]):
Definition 2
Note that if the closed form \(f_\mathtt{x}(\mathtt{X}^{\langle {0}\rangle },n)\) of a variable x is a linear polynomial, then x is necessarily monotonic. The following proposition uses this property:
Proposition 2
Let \(f_\mathtt{x}(\mathtt{X}^{\langle {0}\rangle },j)\) be the closed form (2) of \(\mathtt{x}^{\langle {j}\rangle }\), where \(\alpha _{(2\cdot k +2)}=0\), i.e., the polynomial \(f_\mathtt{x}\) is linear. Then \(\Delta f_\mathtt{x} \mathop {=}\limits ^{\mathrm{\tiny def}}f_\mathtt{x}(\mathtt{X}^{\langle {0}\rangle },j+1)f_\mathtt{x}(\mathtt{X}^{\langle {0}\rangle },j)\) (for \(j\in [0,n)\)) is the (symbolic) constant \(\sum _{i=1}^k\alpha _{(k+i)}\cdot \mathtt{x}^{\langle {0}\rangle }_i+\alpha _{(2\cdot k+1)}\). The variable x is (strictly) increasing in \(\pi ^n\) if \(\Delta f_\mathtt{x}\ge 0\) (\(\Delta f_\mathtt{x}>0\), respectively) and dense if \(0\le \Delta f_\mathtt{x}\le 1\).
Lemma 3
The validity of Lemma 3 follows immediately from Proposition 2. Using Lemma 3, we can replace the existentially quantified membership test in Predicate (6) by a quantifierfree predicate if one of the side conditions in (8) holds. Given that the path prefix reaches the entry node of a loop, these conditions \(\Delta f_\mathtt{x}>0\) and \(0\le \Delta f_\mathtt{x}\le 1\) can be checked using a satisfiability solver.
Example 4
5 Implementation and experimental results
 1.
Impulse first explores the paths of the CFG following the LAwI paradigm. If Impulse encounters a path containing a loop with body \(\pi \), it computes \(\mathop {\pi }\limits ^{\leadsto }\) (processing inner loops first in the presence of nested loops), augments the CFG accordingly, and proceeds to phase 2.
 2.
Cbmc inspects the instrumented CFG up to an iteration bound of 2. If no counterexample is found, Impulse returns to phase 1.
We evaluated the effectiveness of underapproximation on the Verisec benchmark suite [18], which consists of manually sliced versions of several open source programs that contain buffer overflow vulnerabilities. We chose Verisec over the small synthetic benchmarks in the loopacceleration category of the competition on software verification [2], since the Verisec suite is based on realworld vulnerabilities.
Number of accelerated loops (in 284 programs)
Tool  Solved  # Loops accelerated  # Programs accelerated 

Impulse (w/o acc.)  17  0  0 
Impulse  102  258  119 
Satabs  33  0  0 
Finally, on the 8 safe instances from the Verisec benchmark that Impulse can solve (using interpolants computed via the weakest precondition), underapproximation did not improve (or impair) the runtime on safe instances.
6 Related work
The underapproximation technique presented in this paper is based on our previous work on loop detection [16, 17]. The algorithm in [16], however, does not yield a strict underapproximation, and thus necessitates an additional step to validate the unwound counterexample. Our new technique avoids this problem.
The techniques in Sect. 3.1 constitute a simple form of acceleration [4, 8]. The subsequent restrictions in Sects. 3.3 and 3.4 on \(\mathop {\pi }\limits ^{\leadsto }\), however, impose a symbolic bound on the number of iterations, yielding an underapproximation. In contrast to acceleration of integer relations, our approximation is sound for bitvector arithmetic. Sinha uses term rewriting to compute symbolic states parametrised by the loop counter, stating that his technique can be extended to support bitvectors [22].
The quantifier elimination technique of Sect. 4.1 bears similarities with splitter predicates [21], a program transformation facilitating the generation of disjunctive invariants. Similarly, trace partitioning [9] splits program paths to increase the precision of static analyses. Neither technique aims at eliminating quantifiers.
Loop summarisation [15] and path invariants [3] avoid loop unrolling by selecting an appropriate overapproximation of the loop from a catalogue of invariant templates. Overapproximations are also used in the context of loop bound inference [24] and reasoning about termination [6]. However, overapproximations do not enable the efficient detection of counterexamples.
Hojjat et al. [11] uses interpolation to derive inductive invariants from accelerated paths. While this work combines under and overapproximation, it is not aimed at counterexample detection. Motivated by the results of [11], we believe that underapproximation can, if combined with interpolation, improve the performance of verification tools on safe programs. We plan to support interpolation in a future version of our implementation.
Techniques to solve recurrences are frequently used in compiler construction [23]. For example, van Engelen et al. [7] present an algorithm to compute closed forms for systems of recurrence equations, which also supports induction variables that are updated conditionally by introducing a dynamic range for each variable. While it would be straight forward to incorporate these ideas into our work, the technique discussed in Sect. 3 is sufficient for all practical purposes if the bounded range of program variables is taken into account (see our remark at the end of Sect. 3.1.2).
We refer the reader to [17] for a description of additional related work.
7 Conclusion and future work
We present a sound underapproximation technique for loops in C programs with bitvector semantics. The approach is very effective for finding deep counterexamples in programs that manipulate arrays, and compatible with a variety of existing verification techniques. A shortcoming of our underapproximation technique is its lack of support for dynamic data structures, which we see as a challenging future direction.
Footnotes
 1.
In a preliminary interpolationbased implementation, Z3 was in many cases unable to provide interpolants for path formulas \(\mathop {\pi }\limits ^{\leadsto }\) with quantifiers, arrays, and bitvectors.
 2.
Our new technique discovered bugs in 10 of the benchmarks that had been labelled safe. Satabs timed out before identifying these bugs.
 3.
Unfortunately, loop detection in Satabs is neither available nor maintained anymore.
Notes
Acknowledgments
Supported by the Engineering and Physical Sciences Research Council (EPSRC) under grant no. EP/H017585/1, the EU FP7 STREP PINCETTE, the ARTEMIS VeTeSS project, and ERC project 280053. Georg Weissenbacher: Funded by the Vienna Science and Technology Fund (WWTF) through project VRG11005 and the Austrian Science Fund (FWF) through RiSE (S11403N23).
References
 1.Ball T, Cook B, Levin V, Rajamani SK (2004) Slam and static driver verifier: technology transfer of formal methods inside Microsoft. In: IFM, LNCS, vol 2999. Springer, New YorkGoogle Scholar
 2.Beyer D (2014) Status report on software verification—(competition summary SVCOMP 2014). In: TACAS, LNCS, vol 8413. Springer, New York, pp 373–388Google Scholar
 3.Beyer D, Henzinger TA, Majumdar R, Rybalchenko A (2007) Path invariants. In: PLDI. ACM, pp 300–309Google Scholar
 4.Boigelot B (1999) Symbolic methods for exploring infinite state spaces. Ph.D. thesis, Université de LiègeGoogle Scholar
 5.Clarke EM, Kroening D, Lerda F (2004) A tool for checking ANSIC programs. In: TACAS. Springer, New York, pp 168–176Google Scholar
 6.Cook B, Podelski A, Rybalchenko A (2011) Proving program termination. Commun ACM 54(5):88–98CrossRefGoogle Scholar
 7.van Engelen R, Birch J, Gallivan K (2004) Array data dependence testing with the chains of recurrences algebra. In: IEEE Innovative architecture for future generation highperformance processors and systems, pp 70–81Google Scholar
 8.Finkel A, Leroux J (2002) How to compose Presburgeraccelerations: applications to broadcast protocols. In: FSTTCS 2002, LNCS, vol 2556. Springer, New York, pp 145–156Google Scholar
 9.Handjieva M, Tzolovski S (1998) Refining static analyses by tracebased partitioning using control flow. In: SAS, LNCS, vol 1503. Springer, New York, pp 200–214Google Scholar
 10.Henzinger TA, Jhala R, Majumdar R, Sutre G (2002) Lazy abstraction. In: POPL. ACM, pp 58–70Google Scholar
 11.Hojjat H, Iosif R, Konecny F, Kuncak V, Ruemmer P (2012) Accelerating interpolants. In: ATVA, LNCS. Springer, New York 7561:197–202Google Scholar
 12.Jhala R, McMillan KL (2006) A practical and complete approach to predicate refinement. In: TACAS, LNCS, vol 3920. Springer, New York, pp 459–473Google Scholar
 13.Kovács L, Voronkov A (2009) Finding loop invariants for programs over arrays using a theorem prover. In: FASE, LNCS, vol 5503. Springer, New York, pp 470–485Google Scholar
 14.Kovács LI, Jebelean T (2005) An algorithm for automated generation of invariants for loops with conditionals. In: IEEE symposium on symbolic and numeric algorithms for scientific computing (SYNASC), pp 245–249Google Scholar
 15.Kroening D, Sharygina N, Tonetta S, Tsitovich A, Wintersteiger CM (2008) Loop summarization using abstract transformers. In: ATVA, LNCS, vol 5311. Springer, New York, pp 111–125Google Scholar
 16.Kroening D, Weissenbacher G (2006) Counterexamples with loops for predicate abstraction. In: CAV, LNCS, vol 4144. Springer, New York, pp 152–165Google Scholar
 17.Kroening D, Weissenbacher G (2010) Verification and falsification of programs with loops using predicate abstraction. Form Asp Comput 22:105–128MATHCrossRefGoogle Scholar
 18.Ku K, Hart TE, Chechik M, Lie D (2007) A buffer overflow benchmark for software model checkers. In: ASE. ACM, pp 389–392. doi: 10.1145/1321631.1321691
 19.McMillan KL (2006) Lazy abstraction with interpolants. In: CAV, LNCS, vol 4144. Springer, New York, pp 123–136Google Scholar
 20.Nelson G (1989) A generalization of Dijkstra’s calculus. TOPLAS 11(4):517–561CrossRefGoogle Scholar
 21.Sharma R, Dillig I, Dillig T, Aiken A (2011) Simplifying loop invariant generation using splitter predicates. In: CAV, LNCS, vol 6806. Springer, New York, pp 703–719Google Scholar
 22.Sinha N (2008) Symbolic program analysis using term rewriting and generalization. In: Formal methods in computeraided design, pp 1–9Google Scholar
 23.Zima H, Chapman B (1991) Supercompilers for parallel and vector computers. ACM, New YorkGoogle Scholar
 24.Zuleger F, Gulwani S, Sinn M, Veith H (2011) Bound analysis of imperative programs with the sizechange abstraction. In: SAS, LNCS, vol 6887. Springer, New York, pp 280–297Google Scholar
Copyright information
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.