The composite analysis presented in this thesis had great success (cf. Chapter 6), mainly because it combines two fundamentally different verification approaches. With CPAchecker it is easy to mix and match various verification approaches, and novel combinations of existing or new CPAs sure would yield benefits for special use cases. Furthermore, new insights here may also have an impact on (inter-analysis) refinement selection (cf. Chapters 8), i. e., where inter-analysis refinement selection has to decide which analysis is better to be refined. In that regard, it would also be possible to evaluate inter-analysis refinement selection with more than just two different CPAs. However, before investigating that, better heuristics for intra- and inter-analysis refinement selection would be needed. For example, so far, we only investigated which program variables are referenced by different refinements, but for the predicate analysis, one could also differentiate refinements based on whether more equality predicates or more inequality predicates are being referenced. The former are generally considered less suitable, because they may lead to loop unrollings. Symbolic execution is being used in many fields, especially for testing, and refinement selection helped to boost the performance of the analysis for symbolic execution in CPAchecker significantly . Hence, it would be interesting if the successful combination of symbolic execution and refinement selection has an impact on more applications of symbolic execution. Additionally, refinement selection and infeasible sliced prefixes could be used for finding and generating invariants, and make them available to other analyses . Furthermore, being able to extract more infeasible sliced prefixes while also applying ABE would perhaps allow guided refinement selection to work even better for the predicate analysis. Finally, we firmly believe that guided refinement selection could be even more successful if it could make use of domain knowledge, e. g., knowing before starting the verification process which program variables are likely to be needed for reasoning over a given verification task. We are proud that the value analysis with CEGAR and the composite analysis of the value analysis and the predicate analysis are actively used by practitioners and researchers as part of the Linux Driver Verification program 1 , but having more industrial partners would allow us to obtain more insights and tune the concepts and ideas, as well as the whole analyses themselves, in order to enable automatic softwareverification in practice.
Abstract in German
Unser Anliegen ist die Korrektheit von Software und wir präsentieren einen allgemeinen Ansatz zur Verifikation von Programmeigenschaften in nahezu beliebigen Programmier- sprachen. Dieser Ansatz besteht aus zwei Schritten: Zuerst führen wir das zu analysie- rende Programm symbolisch aus, um eine endliche Überapproximation aller möglichen Programmläufe für alle möglichen Eingaben zu erhalten. Wir nennen diese Überap- proximation einen symbolischen Auswertungsgraphen (symbolic execution graph). Im Un- terschied zu den meisten existierenden Ansätzen, welche abstrakte Interpretationen nut- zen, wird die Konstruktion eines solchen Graphen stark durch das zu analysierende Programm gesteuert, anstatt programmunabhängige Widening-Operatoren zu nutzen. Anschließend synthetisieren wir aus dem Graphen Programme in einfachen Programmier- sprachen, welche die wesentlichen Programmeigenschaften ausdrücken, die wir analysie- ren wollen. Auf diese Weise wird die nachfolgende Analyse dieser Programmeigenschaf- ten auf Grundlage der synthetisierten Programme substanziell vereinfacht. Wir nutzen also Synergien zwischen Techniken zur Programmanalyse und zur Programmsynthese, um mächtige Verifikationsverfahren zu entwickeln.
Software is used in many safety- and security-critical systems. Soft- ware development is, however, an error-prone task where a software developer tries to precisely formalize in a programming language their imprecise ideas about a program. Formal methods help to reduce this problem. These methods add another layer to the software develop- ment allowing to formalize and to check desired properties of a pro- gram. Deductive softwareverification is a formal method for proving the correctness of a program with respect to a requirement specifica- tion. However, since programs often have faults, i.e., they do not satisfy the required program properties, program correctness proofs often do not succeed. The ability to detect software faults is therefore important to increase the efficiency of softwareverification. Another deficiency of softwareverification is that it is often not practical to apply softwareverification rigorously to a program and all other components that are critical for the the correct behavior of the program. The combination of softwareverification with software testing is therefore important even if a correctness proof for a program (subset) has been established.
Our results demonstrate that precision transducers are a useful and practi- cal concept for softwareverification. Novel sharing strategies that are made expressible based on precision transducers can solve tasks for which es- tablished strategies fail. The performance of the sharing and scoping strat- egy Global was surprising because we would have expected that the costs for predicate abstraction would explode in many cases. At least for our ver- ifier configuration and the set of benchmark programs, results suggest that reducing the number of refinement iterations seems to be one of the best ways to gain performance in terms of time for a verification run. Neverthe- less, the promising results of our novel strategy Context witness that there are strategies that become expressible with the introduction of our preci- sion transducers and that make verifiers more effective in terms of solved tasks. Expanding the scope of precisions based on statistics on refinements could be one way to go [ 147 ] in the future. In general, we observe that the chosen strategy for scoping and sharing has a massive influence on the per- formance of a verification approach. That is, the chosen strategy should be at least a controlled variable in empirical studies on abstraction-based ver- ification techniques! For precision synthesis, the results heavily depend on the case study: Linux supports our hypothesis that precision synthesis can make verification more effective and efficient by reducing the number of re- finements; this conclusion is not possible based on the results for BusyBox. While we were able to come up with exciting results, we consider them to be only the start of a series of studies on transducer-guided synthesis and shar- ing of abstraction precisions. The concept of precision transducers provides a perspective that brings problems of sharing, scoping, and synthesizing of precisions into the focus, and thus, the problem of balancing the number of refinement iterations and the size of the abstract model.
6.1 Summary and Discussion
We started this thesis with the aim to improve verification for control systems in model- based design (MBD). Particularly, we mentioned the lack of explicit support for floating point numbers and control designs. Thereafter, we presented the necessary background in softwareverification and control theory. We covered abstract interpretation, model checking, satisfiability modulo theory (SMT) and touched hybrid systems. Moreover, we highlighted findings relating to floating point computations and showed how test suits, guaranteeing decision coverage, can be generated. Afterwards, focus was set con control theory, starting with linear matrix inequalities (LMIs) and convex optimization, which are techniques applied in robust control. Various systems were shown, including linear time invariant (LTI), linear difference inclusion (LDI) and Lur’e systems. Special classes of nonlinear systems were introduced, for instance, polynomial systems, reset control systems and positive systems. Finally, we mentioned briefly the work on nonlinear systems in general, e.g., the small gain theorem.
Showing the satisfiability of a first-order logic (FOL) formula means to show the existence of an interpretation in which the formula evaluates to true. This is an important and long studied problem in different ap- plication domains such as formal softwareverification, software testing, and artificial intelligence. In softwareverification and testing the mod- els, i.e. interpretations, are used as counterexamples to debug programs and specifications and to generate test data, respectively. The approach that we suggest is to use programs to represent partial models and to use formal verification in order to evaluate quantified formulas to true. The technique described in this chapter is a model generation tech- nique which is a sub-component of our software-fault detection ap- proach described in Chapter 4. This technique is required in order to generate counterexamples for verification conditions that could not be proved during a verification attempt. If a verification condition has a counterexample and the branch of the proof tree on which the verifica- tion condition occurs is validity preserving (see Chapters 4 and 5), then the target program does not satisfy its specification. Hence, a software fault is detected and the counterexample helps finding the fault because it represents the initial state of the program run that reveals the fault. The generation of counterexamples is further important in counterex- ample guided abstraction refinement (CEGAR) [Clarke et al., 2000] and for checking the consistency, i.e. contradiction-freeness, of axioms and of preconditions in specifications.
Examples of verifiers for object-oriented programs based on verification condi- tion generation are ESC/Java [Flanagan et al., 2002], its successor ESC/Java2 [Cok and Kiniry, 2005], Spec# [Barnett et al., 2005, 2010], and a number of offsprings of Spec# [Leino, 2008; Smans et al., 2008] that also use its backend Boogie [Barnett et al., 2006] for generating verification conditions. In the spirit of the “verifying compiler”, these tools are fully automatic, in the sense that when executed, they run to termination without any interaction in between. Ideally, this architecture should spare their users the need to understand their internals. However, full automation of functional softwareverification is today way beyond the state of the art. Thus, in practice, one does need to interact with these tools: the interaction consists of guiding the tool along by writing auxiliary source code annotations [Beckert et al., 2009a]. If the employed SMT solver—dealing heuristically with instances of an undecidable problem—is unable to prove a valid verification condition, verifying a correct program may fail; a human verification expert may be able to solve this problem by adding appropriate annotations. JACK [Burdy et al., 2003] and Krakatoa [March´ e et al., 2004] are Java verifiers based on verification condition generation that are unusual in that they target interactive provers for higher-order logic (in particular Coq) for proving the ver- ification conditions, in addition to SMT solvers.
Abstract—Six softwareverification tools have been applied to space flight software and the findings reported by each tool have been compared in order to derive footprints of the tools regarding capabilities of fault identification. Currently available results are provided in this paper: sensitivity and precision of individual tools and combinations of pairs of tools out of the set. A reader should bear in mind that the results as presented here depend on the spectrum of fault types as present in the reference software and on the configuration of tools towards real defects and fault types which are of interest for embedded systems and space flight software.
Abstract—Mastering the continuously increasing amount of software requires identification of more efficient strategies for softwareverification. Currently, fault coverage is only indirectly addressed, e.g. by code coverage. The idea as presented in this paper is to get a better understanding of fault coverage by a systematic classification of software fault types, derivation of footprints of verification tools regarding coverage of such fault types, and recording of required effort. A number of issues regarding fault identification and classification are discussed in this context.
United Kingdom The Netherlands
Verification of strategic properties is complicated, even for very small protocols. In this work we look at voting protocols that allow three agents to vote over three alternatives, and investigate what properties of those protocols can be expressed in different logics. We first verify some basic requirements using a logic of coalition powers. Then we investigate a few advanced properties in complete and incomplete information context, using two more expressive logics. Along the way, we propose a new compact way to represent game trees.
Finiteness is not required for the soundness of our abstraction technique, but without resulting finite abstract systems it would be useless for verification purposes. As the finiteness of abstract transition systems using HRG abstraction strongly depends on the program, we cannot guarantee finiteness generally for any program as in the singly- linked setting. Even if the abstract transition system of a given program is finite, it may not be so for another. In fact, we will always be able to construct programs that result in infinite abstract transition systems. However, we have developed a test that gives us an indication if an abstraction grammar is suitable for a given data structure. This suitability is a necessary precondition for a finite abstract semantics for non-trivial programs with read-only access (data structure traversal). In fact, for read-only access with a single variable (next to arbitrarily many variables that are not updated by the program) it is also sufficient for finiteness of the abstract semantics.
Gruppen verzahnt sind" (Floyd 1994: 29). Die heutigen Schwierigkeiten der Software- Entwicklung, soweit sie durch diesen Problemkomplex gekennzeichnet sind, unterscheiden sich mithin deutlich von der Software-Krise der sechziger Jahre. Sie beruhen nicht mehr in erster Linie auf Mängeln bei der methodischen Strukturierung des Entwicklungsvorganges. Das Problem besteht vielmehr darin, die nur schwer formalisierbaren Anforderungen organisationaler Einsatzumgebungen bei der Erstellung von Software zu berücksichtigen. Organisationsbezogene Software-Entwicklung wird damit zu einer Aufgabe, bei der die technische Problemlösung und ihre Einbettung in einen sozialen Einsatzzusammenhang zwangsläufig miteinander verschmelzen. Eine solche Sichtweise repräsentiert der Begriff der Software-Gestaltung. Hier wird Software-Entwicklung nicht mehr exklusiv als Ingenieurwis- senschaft betrachtet, sondern gleichermaßen als Designwissenschaft (vgl. Floyd 1994: 29; Schulz-Schaeffer 1994), also als ein Handlungsbereich, der "sich nicht mit dem Notwendigen (befaßt), sondern mit einem Freiheitsspielraum: nicht damit, wie die Dinge sind, sondern damit, wie sie sein könnten" (Simon 1990: VIII). Freiheitsspielräume für Gestaltungsent- scheidungen werden sichtbar, wenn man nicht allein nach den technisch effizientesten Verfahren fragt, sondern mögliche technische Lösungen auch unter dem Kriterium der Angemessenheit im jeweiligen Einsatzzusammenhang auswählt. Dies wiederum setzt voraus, daß man die möglichen Entscheidungen im Entwicklungsprozeß nicht vollständig als durch die Vorgaben einer innertechnischen Rationalität vorgezeichnet ansieht, sondern als einen Gestaltungsprozeß, bei dem mit dem technischen System zugleich auch die sozialen Zusammenhänge seiner Verwendung modelliert werden müssen.
Resources Satellite 1 (JERS-1), was launched from JAXA’s Tanegashima Space Center in January 2006. An important contribution to the ALOS mission is the verification of PALSAR products to be distributed by the European ADEN node using the PALSAR processor developed by JAXA. A total of 28 ALOS PALSAR products have been analysed with respect to radiometric, geometric and polarimetric quality (including effects of Faraday rotation caused by the ionosphere) and a summary of the results is shown in this paper.
In this section, we describe the verification of a C implementation of the con- nected components checker within Isabelle/HOL. To translate from C to Is- abelle we use the C-to-Isabelle parser that was developed as part of the seL4 project [Klein et al., 2010] and was used to verify a full operating system kernel. We do not work on the output of the parser directly, but use the AutoCorres tool [Greenaway et al., 2012] that simplifies reasoning about C in Isabelle/HOL. This approach (the AutoCorres approach) avoids double formalizations in two systems and reduces the trusted code base: instead of trusting VCC, one now has to trust the C-to-Isabelle parser, a significantly simpler program. Since we are the first external users of AutoCorres, it was not clear at the beginning of our work whether the AutoCorres approach would be competitive. In the case studies we carried out, we found it to be competitive, if not superior.
Dieser wurde ins Deutsche als Fremdwort übernommen, umgangssprachlich vielleicht sogar rascher als in der Fachliteratur. Die älteren Lehrbücher führen das Wort noch nicht im Sachregister, 8 bis es dann doch vereinzelt in Informatik-Einfüh-
rungen erwähnt und erläutert wird: »Als Software bezeichnet man alle Teile einer ADVA [Automatischen Datenverarbeitungsanlage], die in Form von Programmen vorliegen.« 9 Spätestens ab diesem Zeitpunkt aber wurde das Fremdwort so sehr zu
Bei der Analyse und Verifikation von Systemen ist automatisches Beweisen bereits weit verbreitet. F¨ ur reine Hardwaresysteme und eine eingeschr¨ankte Klasse von Software sind die auftretenden Verifikationsprobleme von Natur aus endlich. Entscheidungsverfahren f¨ ur propositionale Logik (SAT-Solver) k¨onnen solche Probleme sehr effizient l¨osen. F¨ ur komplexe Systeme und andere Arten von Software kann eine Endlichkeit der Verifikationsprobleme nicht angenom- men werden. Um Eigenschaften solcher Systeme ausdr¨ ucken und beweisen zu k¨onnen, brauchen wir eine formale Sprache und Beweismethoden, die mit uni- verseller Quantifizierung, arithmetischen Ausdr¨ ucken und unbeschr¨ankten Da- tentypen gleichzeitig umgehen k¨onnen. Es gibt Beweissysteme f¨ ur Pr¨ adikatenlo- gik, die gut mit quantifizierten Formeln umgehen k¨onnen, und effiziente Entschei- dungsverfahren f¨ ur (nicht quantifizierte) Probleme in Theorien von Arithmetik und Datentypen. Um die anfallenden Verifikationsprobleme zu l¨osen, ben¨otigen wir Verfahren, die die St¨arken dieser beiden Ans¨ atze zusammenbringen.
developers, non-academic users, and reviewers can all greatly beneﬁt from a com- mon set of realistic and challenging examples that new algorithms and tools are consistently benchmarked and compared on and that may indicate the practical- ity of a new method or tool. Such sets, and the associated push to standardised semantics, formats, and interfaces, have proven their usefulness in other areas such as software veriﬁcation [ 4 ] and SMT solving [ 3 ].