A Library Modeling Language for the Static Analysis of C Programs

Abstract

We present a specification language aiming at soundly modeling unavailable functions in a static analyzer for C by abstract interpretation. It takes inspiration from Behavioral Interface Specification Languages popular in deductive verification, notably Frama-C's ACSL, as we annotate function prototypes with pre and post-conditions expressed concisely in a first-order logic, but with key differences. Firstly, the specification aims at replacing a function implementation in a safety analysis, not verifying its functional correctness. Secondly, we do not rely on theorem provers; instead, specifications are interpreted at function calls by our abstract interpreter. We implemented the language into Mopsa, a static analyzer designed to easily reuse abstract domains across widely different languages (such as C and Python). We show how its design helped us support a logic-based language with minimal effort. Notably, it was sufficient to add only a handful transfer functions (including very selective support for quantifiers) to achieve a sound and precise analysis. We modeled a large part of the GNU C library and C execution environment in our language, including the manipulation of unbounded strings, file descriptors, and programs with an unbounded number of symbolic command-line parameters, which allows verifying programs in a realistic setting. We report on the analysis of C programs from the Juliet benchmarks and Coreutils.

A Multilanguage Static Analysis of Python Programs with Native C Extensions

“…We reuse the states defined in the work of Monat et al [33] for Python and Ouadjaout and Miné [37] for C. A set of heap addresses Addr (potentially infinite) is common to the states. Previous works [11,33,37] define the semantics of Python and C. Python state (Figure 3). Python objects are split into a nominal part and a structural part.…”

“…We assume the abstract semantics of Python and C are provided through E # p • , E # c • . These can be instantiated in practice using previous works [37,34]. We assume that each language's abstract state relies on an address allocation abstraction (such as the callsite abstraction or the recency abstraction [2]) and a numeric abstraction (such as intervals, octagons, …).…”

“…A specific feature of Mopsa is to provide loosely-coupled abstract domains that the user combines through a configuration file to define the analysis. We were able to reuse off-the-shelf value analyses of C programs [37] and Python programs [34] already implemented into Mopsa. The only modification needed was to add a multilanguage domain, implementing the semantics of the operators at the boundary, just as our semantics (both concrete and abstract) do.…”

“…Our analyzer works by induction on the syntax and switches from one language to the other just as the concrete program execution does. We present a multilanguage static analysis built upon pre-existing value static analyses by abstract interpretation [9] of C [37] and Python [33,34]. It detects runtime errors in the native C code (invalid pointer operations, invalid memory accesses, integer overflows), in the Python code (raised exceptions), and at the boundary between the languages.…”

The e-ACSL perspective on runtime assertion checking

“…Yet, DV à la Dijkstra [24] is the tool of choice for proving them for all possible executions. Abstract interpretation à la Cousot [49] is also possible [18,45], as well as model checking [6], even if several logical properties cannot be easily verified with these techniques. Nowadays, most tools based on BISL support both RAC and DV, e.g.…”