Astrée: Proving the Absence of Runtime Errors
Total Page：16
File Type：pdf, Size：1020Kb
Astrée: Proving the Absence of Runtime Errors Daniel Kästner,1 Stephan Wilhelm,1 Stefana Nenova,1 Patrick Cousot,† Radhia Cousot,† Jérôme Feret,† Laurent Mauborgne,† Antoine Miné,† Xavier Rival,† 1: AbsInt Angewandte Informatik GmbH. Science Park 1, D-66123 Saarbrücken, Germany 2: École Normale Supérieure. 45, rue d’Ulm, F-75230 Paris, France Abstract: Safety-critical embedded software has without actually running the software under analy- to satisfy stringent quality requirements. Testing sis. The results thus obtained hold for any possi- and validation consumes a large – and growing – ble input scenario and any possible program execu- fraction of development cost. The last years have tion. Examples are tools for computing the worst- seen the emergence of semantics-based static anal- case execution time [28, 13] or the maximal stack ysis tools in various application areas, from runtime usage of tasks [12], the accuracy of floating-point error analysis to worst-case execution time predic- computations [20], and the absence of run-time er- tion. Their appeal is that they have the poten- rors [2,6,8]. Modern semantics-based static ana- tial to reduce testing effort while providing 100% lyzers scale well and support the analysis of large coverage, thus enhancing safety. Static runtime industrial software projects. error analysis is applicable to large industry-scale This article focuses on a certain class of errors, the projects and produces a list of definite runtime er- so-called runtime errors. Examples for runtime er- rors and of potential runtime errors which might be rors are floating-point overflows, array bound vio- true errors or false alarms. In the past, often only lations, or invalid pointer accesses. Runtime er- the definite errors were fixed because manually in- rors lead to undefined program behavior; the con- specting each alarm was too time-consuming due to sequences range from erroneous program behavior a large number of false alarms. Therefore no proof to wholesale crashes. A well-known example for the of the absence of runtime errors could be given. In possible effects of runtime errors is the explosion this article the parameterizable static analyzer As- of the Ariane 5 rocket on its maiden flight in 1996 trée is presented. By specialization and parameter- [19]. ization Astrée can be adapted to the software under analysis. This enables Astrée to efficiently compute An important goal when developing critical soft- precise results. Astrée has successfully been used ware is to prove that no such errors can occur at to analyze large-scale safety-critical avionics soft- runtime. Software testing can be used to detect ware with zero false alarms. errors, but since usually no complete test cover- age can be achieved, it cannot provide guarantees. Keywords: Proof of absence of runtime errors, ab- Semantics-based static analysis allows to derive stract interpretation, static C code analysis, DO- such guarantees even for large software projects. 178B, ISO-26262 The success of static analysis is based on the fact that safe overapproximations of program semantics 1. Introduction can be computed. This means that the results of Safety-critical embedded software has to satisfy such analyses will be either “(i) statement x will not stringent quality requirements. A system failure cause an error”, or “(ii) statement x may cause an or malfunction can have severe consequences and error”. In the first case, the user can rely on the ab- cause high costs. Testing and validation consumes a sence of errors, in the second case either an error large – and growing – fraction of development cost. has been found, or there is a false alarm. This im- Thus, developers face the challenge of ensuring the precision allows sound static analyzers to compute correct functioning of the software, but this has to results in acceptable time, even for large software be done with reasonable effort. projects. Nevertheless the results are reliable, i.e., In the avionics, automotive, and healthcare indus- the analysis will only err on the safe side: if the tries static analyzers based on abstract interpreta- analyzer does not detect any error, the absence of tion have increasingly been used to validate pro- errors has been proven - the coverage is 100%. gram properties of safety-critical software. The re- Each alarm has to be manually investigated to de- sults are only computed from the software structure termine whether there is an error that has to be ERTS2 2010 – May 19–21, 2010 – Toulouse Page 1/9 corrected, or whether it was just a false alarm. If all cluding style checkers looking for deviations from the alarms raised by an analysis have been proven coding style rules, like the MISRA guidelines pre- to be false, then the proof of absence of runtime scribed by the Motor Industry Software Reliability errors is completed. This could be checked manu- Association [24]. Such style checkers are usually ally, but the problem is that such a human analy- not “semantics-based”, and thus cannot check for sis is error-prone and time consuming, especially correct runtime behavior. since there might be interdependencies between Furthermore static analyzers can be categorized in the false alarms. If the analyzer does not report sound vs. unsound analyzers. A program analyzer any alarm the absence of runtime errors is auto- is unsound when it can omit to signal an error that matically proven by the analyzer run. Therefore the may appear at runtime in some execution environ- ideal solution is to enable the analyzer to finish the ment. Unsound analyzers are bug hunters or bug analysis with zero alarms. finders aiming at finding some of the bugs in a well- To that end, it is important that the analyzer is defined class. Their main defect is unreliability, be- precise, i.e., produces only few false alarms with- ing subject to false negatives thus claiming that out particular user interaction. This can only be they can no longer find any bug while many may achieved by a tool that can be specialized to a be left in the considered class. Unsoundness can be class of properties for a family of programs. Ad- caused e.g., by skipping program parts which are ditionally the analyzer must be parametric enough hard to analyze, ignoring some types of errors, dis- for the user to be able to fine tune the analysis regarding some runtime executions, or adopting a of any particular program of the family. General simplified program semantics. Example tools from software tools not amenable to specialization and this class are ESC Java [18], Coverity CMC [11], parametrization usually report a large number of Klocwork K7 [16], PRE-fast [25], or Splint [17]. A false alarms. That is the reason why in indus- more comprehensive overview is found in [6]. try such tools are only used to detect runtime er- Such unsound approaches are all excluded in As- rors, and not to prove their absence. The analyzer trée. Astrée is a bug eradicator in that sense that should also provide flexible annotation mechanisms all bugs from a well-defined class, i.e., runtime er- for users to communicate external knowledge to the rors, are found. Another tool from this class is analyzer. Only by a combination of high analyzer Polyspace Verifier [8]. More precisely, Astrée is a precision and support for semantic annotations the sound semantics-based static analyzer based on Ab- goal of zero false alarms can be achieved. stract Interpretation. In our article we focus on the static analyzer As- trée (Analyseur statique de logiciels temps-réel em- 2.1 Abstract Interpretation barqués)[1], which originates from the École Nor- Static analyzers compute invariants for all program male Supérieure [10]. Since February 2009 Astrée points by fixed point iteration over the program is commercially available and is now developed and structure or the control flow graph. The theory of distributed by AbsInt under license of CNRS/ENS. abstract interpretation [5] offers a semantics-based Astrée has been specifically designed to meet the methodology for static program analysis. The con- above mentioned requirements: it produces only a crete semantics is mapped to an abstract semantics small number of false alarms for control/command by abstraction functions. While most interesting programs written in C, and provides the user with program properties are undecidable in the concrete enough options and directives to help reduce this semantics, the abstract semantics can be chosen to number down to zero. Astrée has been successfully be computable. The static analysis is computed with used to analyze industrial Airbus avionics software respect to that abstract semantics. Compared to an [27]. We give an overview of the structure of Astrée analysis of the concrete semantics, the analysis re- and describe how developers can use it to achieve sult may be less precise but the computation may the goal of zero false alarms and thus efficiently val- be significantly faster. By skilful definition of the idate the absence of run-time errors. abstract domains a suitable trade-off between pre- cision and efficiency can be obtained. 2. Static Analyzers Abstract interpretation supports formal correctness Static analyzers compute their results only from the proofs: it can be proven that an analysis will ter- program structure by inspecting the source code or minate and that it computes an overapproximation binary code, but without actually executing it. of the concrete semantics, i.e., that the analysis re- Static analyzers are sometimes understood as in- sults are sound. A static runtime error analysis is ERTS2 2010 – May 19–21, 2010 – Toulouse Page 2/9 called sound if it never omits to signal an error that 3.1 Handling Undefined Behavior can appear in some execution environment. If no For runtime errors corresponding to undefined be- potential error is signalled, definitely no runtime haviors Astrée produces an alarm and continues error can occur.