Inferring Interval-Valued Floating-Point Preconditions

Aggregated roundoff errors caused by floating-point arithmetic can make numerical code highly unreliable. Verified postconditions for floating-point functions can guarantee the accuracy of their results under specific preconditions on the function inputs, but how to systematically find an adequate precondition for a desired error bound has not been explored so far. We present two novel techniques for automatically synthesizing preconditions for floating-point functions that guarantee that user-provided accuracy requirements are satisfied. Our evaluation on a standard benchmark set shows that our approaches are complementary and able to find accurate preconditions in reasonable time

An iterative approach to precondition inference using constrained Horn clauses

We present a method for automatic inference of conditions on the initial states of a program that guarantee that the safety assertions in the program are not violated. Constrained Horn clauses (CHCs) are used to model the program and assertions in a uniform way, and we use standard abstract interpretations to derive an over-approximation of the set of unsafe initial states. The precondition then is the constraint corresponding to the complement of that set, under-approximating the set of safe initial states. This idea of complementation is not new, but previous attempts to exploit it have suffered from the loss of precision. Here we develop an iterative specialisation algorithm to give more precise, and in some cases optimal safety conditions. The algorithm combines existing transformations, namely constraint specialisation, partial evaluation and a trace elimination transformation. The last two of these transformations perform polyvariant specialisation, leading to disjunctive constraints which improve precision. The algorithm is implemented and tested on a benchmark suite of programs from the literature in precondition inference and software verification competitions.Comment: Paper presented at the 34nd International Conference on Logic Programming (ICLP 2018), Oxford, UK, July 14 to July 17, 2018 18 pages, LaTe

Augmenting Counterexample-Guided Abstraction Refinement with Proof Templates

Buffer overflow vulnerabilities are the result of programing errors that allow out-of-bounds writes to arrays. Verifying the safety of array writes is thus vital to ensuring program security. However, existing software model checkers based on abstraction-refinement perform poorly at this task, resulting in analyses which often depend on array size. We observe that many of these analyses can be made efficient by providing proof templates, which specify a modular proof strategy with predicates and assumptions to use and then discharge. Our proof tem-plates, which are associated with common programming idioms, guide the model checker towards proofs that are independent of array size. We have integrated this technique into our software model checker, PTYASM, and have evaluated our approach on a set of testcases derived from the Verisec suite, demonstrating that our technique enables verification of the safety of array accesses independently of array size.

Program analysis is harder than verification: A computability perspective

We study from a computability perspective static program analysis, namely detecting sound program assertions, and verification, namely sound checking of program assertions. We first design a general computability model for domains of program assertions and correspond- ing program analysers and verifiers. Next, we formalize and prove an instantiation of Rice\u2019s theorem for static program analysis and verifica- tion. Then, within this general model, we provide and show a precise statement of the popular belief that program analysis is a harder prob- lem than program verification: we prove that for finite domains of pro- gram assertions, program analysis and verification are equivalent prob- lems, while for infinite domains, program analysis is strictly harder than verification

Precondition Inference via Partitioning of Initial States

Precondition inference is a non-trivial task with several applications in program analysis and verification. We present a novel iterative method for automatically deriving sufficient preconditions for safety and unsafety of programs which introduces a new dimension of modularity. Each iteration maintains over-approximations of the set of \emph{safe} and \emph{unsafe} \emph{initial} states. Then we repeatedly use the current abstractions to partition the program's \emph{initial} states into those known to be safe, known to be unsafe and unknown, and construct a revised program focusing on those initial states that are not yet known to be safe or unsafe. An experimental evaluation of the method on a set of software verification benchmarks shows that it can solve problems which are not solvable using previous methods.Comment: 19 pages, 8 figure

Inferring sufficient conditions with backward polyhedral under-approximations

International audienceIn this article, we discuss the automatic inference of sufficient pre-conditions by abstract interpretation and sketch the construction of an under-approximating backward analysis. We focus on numeric domains and propose transfer functions, including a lower widening, for polyhedra, without resorting to disjunctive completion nor complementation, while soundly handling non-determinism. Applications include the derivation of sufficient conditions for a program to never step outside an envelope of safe states, or dually to force it to eventually fail. Our construction is preliminary and essentially untried, but we hope to convince that this avenue of research is worth considering

Counterexample-Guided Precondition Inference

Abstract. The precondition for an assertion within a procedure is use-ful for understanding, verifying and debugging programs. As the proce-dure might be used in multiple calling-contexts within the program, the precondition should be sufficiently precise to enable re-use. We present an extension of counterexample-guided abstraction refinement (CEGAR) for automated precondition inference. Starting with an overapproxima-tion of both the set of safe and unsafe states, we iteratively refine them until they become disjoint. The resulting precondition is then neces-sary and sufficient for the validity of the assertion, which prevents false alarms. We have implemented our approach and present experimental results using string and array-manipulating programs.

Precondition Inference from Intermittent Assertions and Application to Contracts on Collections

International audienceIn the context of program design by contracts, programmers often insert assertions in their code to be optionally checked at runtime, at least during the debugging phase. These assertions would better be given as a precondition of the method/procedure in which they appear. Potential errors would be discovered earlier and, more importantly, the precondition could be used in the context of separate static program analysis as part of the abstract semantics of the code. However in the case of collections (data structures such as arrays, lists, etc) checking both the precondition and the assertions at runtime appears superfluous and costly. So the precondition is often omitted since it is checked anyway at runtime by the assertions. It follows that the static analysis can be much less precise, a fact that can be difficult to understand since ''the precondition and assertions are equivalent'' (i.e. at runtime, up to the time at which warnings are produced, but not statically) e.g. for separate static analysis. We define precisely and formally the contract inference problem from intermittent assertions on scalar variables and elements of collections inserted in the code by the programmer. Our definition excludes no good run even when a non-deterministic choice (e.g. an interactive input) could lead to a bad one. We then introduce new abstract interpretation-based methods to automatically infer both the static contract precondition of a method/procedure and the code to check it at runtime on scalar and collection variables