1 Verification Approach

The submission presents a composite setting comprised of a mature static verification tool CPAchecker [1] and an experimental reachability slicer (a Frama-C [2] plugin) intended to speed up verification by pruning the verification scope prior the application of the main analysis. By verification scope we understand the code to be analyzed rather than the search space explored by the main analysis since the slicer doesn’t prune the search space as it is, but rather removes statements (including function calls) that can be proved to not influence the verification outcome. The slicer included in this submission is currently only applicable to reachability verification tasks, though the underline algorithm is not generally limited to reachability of a small number of error locations and so can be potentially extended to support e.g. memory safety properties.

The slicer is based on a relatively simple mark-and-sweep algorithm, where the relevant statements are first identified by computing transitive closure of the dependency relation, then marked, and finally the remaining statements are removed to produce a sliced verification task. The mark-and-sweep slicing is performed on top of preliminary region analysis, which allows to handle abstract memory locations ascribed to the corresponding disjoint memory regions essentially similar to usual unaliased program variables.

The region analysis implemented in the current submission is a conservative over-approximation of context-sensitive flow-insensitive separation analysis with polymorphic regions for deductive verification. It was first described in [3] and later substantially extended in [4]. The conservative approximation is needed because the original analysis generally requires user annotations. The over-approximation is expressed in the form of additional dependencies introduced on the marking stage rather than in the region analysis itself. The dependencies allow to approximate reinterpretations of memory regions (corresponding to the use of unions and arbitrary pointer type casts), but not some corner cases of pointer arithmetic (mostly arithmetic dependent on a particular layout of structure fields), so the resulting analysis remains unsound in the general case. However, the results of analysis benchmarking using CPAchecker as reachability verifier on the tasks in SV-COMP SoftwareSystems category showed no cases of unsoundness caused by the region analysis. This may be explained by the fact that most of the cases where the analysis is unsound with respect to a low-level C memory model are also regarded as undefined behavior by the C standard, so are probably quite rarely used in practice.

2 Software Architecture

The main CPAchecker verification framework is included in the submission without any considerable changes. The combined tool is implemented as a wrapper script that encapsulates the main verifier invocation and does the following:

  • extracts the property specification and verification task from the arguments;

  • runs the slicer with timeout of 400 s (the sliced program is written to an intermediate C file);

  • runs CPAchecker configuration ldv-bam-svcomp on the sliced program;

  • post-processes the witness produced by CPAchecker.

The slicer (named Crude_slicer) is implemented as a plugin to Frama-C [2], an extensible platform for source-code analysis of C software. The plugin implementation does not interact with other Frama-C plugins and only makes use of the Frama-C kernel. The plugin also uses OCamlgraph [5] library. Both the Frama-C platform and the Crude_slicer plugin are implemented in OCaml.

The witness post-processing stage currently simply removes the character offsets from the resulting witness (the line numbers are preserved using line directives supported by CPAchecker) and substitutes checksum of the original program source.

Since the SoftwareSystems category of the competition also contains memory safety (and overflow) verification tasks, the submission also includes memory safety configuration smg-ldv based on shape analysis presented in [6].

3 Evaluation of the Approach

The slicer is currently able to handle only reachability verification tasks. It was evaluated on 2734 tasks from the Systems_DeviceDriversLinux64_ReachSafety subcategory of the SV-COMP’18 benchmarks on Intel Xeon E3-1230 v5 (3.4 GHz) machines in the competition setting. The submitted configuration with slicing was compared to baseline CPA-BAM-BnB [7, 8] configuration (-ldv-bam-svcomp) without slicing that was also submitted to this year’s competition. The results are presented in the following table:

TRUE verdicts

FALSE verdicts

Speedup

New (\(+\))

Lost (−)

Total

New (\(+\))

Lost (−)

Total

Min

Max

Average

151

10

2252

97

11

267

0.03 \(\times \)

18.59 \(\times \)

1.17 \(\times \)

The table presents the results for correct verdicts only and does not take witness checking into account.

There are two significant limitations of the approach. First, the slicing is performed under assumption that all possible execution paths in the verified program are finite. This does not lead to unsoundness, since reachability (as a safety property) can be assumed to be violated only on finite paths. However, there is 3 wrong FALSE verdicts reported on the benchmarks where an error location is spuriously reached after passing through an infinite loop removed by the slicer. Another limitation is that the resulting tool can not produce precise witnesses both due to imprecision in source code locations and (more importantly) due to unavailability of either invariants or error paths in the sliced out parts of the code. The caused 1090 TRUE verdicts and all FALSE verdicts to fail to be confirmed by the witness checkers on the competition.

The time required for slicing varies from 0.08 to 1905.47 s with an average of 14.82 s. So in the submission the slicer is run with a timeout of 400 s and the remaining tasks (17 out of 2734 in the evaluation) are passed to the main verifier without slicing.

4 Tool Setup and Configuration

The submission is available for download as a ZIP archive named cpa-bam-slicing.zip from the SV-COMP repository by following URL: https://gitlab.com/sosy-lab/sv-comp/archives/tree/master/2018. The submission includes CPAchecker version 1.6.1 and a statically linked version of Frama-C Sulfur-20171101-beta with Crude_slicer plugin. The version of the plugin corresponds to commit fcd3b927. CPAchecker requires Java 8 runtime environment. The invocation of the slicer is embedded in the CPAchecker wrapper script, so the whole tool has to be executed with the following command line:

figure a

The tool participates in SoftwareSystems category, the corresponding benchmark definition is cpa-bam-slicing.xml.