Static Analysis and Verification of Aerospace Software Static Analysis and Verification of Aerospace Software by Abstractby Abstract InterpretationInterpretation Patrick CousotJulien Bertraneand Radhia∗ Cousot Ecole´ normale sup´erieure, Paris , Patrick Cousot∗ ∗∗ jointCourant work Institute with: of Mathematical Sciences, NYU, New York & Ecole´ normale sup´erieure, Paris Radhia Cousot∗ J´erˆome Feret∗ Ecole´ normale sup´erieure & CNRS, Paris Ecole´ normale sup´erieure & INRIA, Paris , Laurent Mauborgne∗ ‡ Ecole´ normale sup´erieure, Paris & IMDEA Software, Madrid Antoine Min´e∗ Xavier Rival∗ Ecole´ normale sup´erieure & CNRS, Paris Ecole´ normale sup´erieure & INRIA, Paris We discuss the!Workshop principles on of formal static analysisverification by abstract of avionics interpretation software andproducts report on the automatic verification of the absence of runtime errors in large embedded aerospaceJune 24, 2010 Airbussoftware France, by Toulouse, static analysis France based on abstract interpretation. The first industrial applications concerned synchronous control/command software in open loop. Recent advances consider Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 © P Cousot et al. imperfectly synchronous, parallel programs, and1 target code validation as well. Future research directions on abstract interpretation are also discussed in the context of aerospace software. Nomenclature S program states I initial states t state transition t I collecting semantics t I trace semantics t I prefix trace semantics C T P F prefix trace transformer t I reachability semantics F reachability transformer P R R 0 Fι interval transformer 1S identity on S (also t ) t ◦ r composition of relations V set of all program variables x program variable t and r t reflexive transitive closure tn powers of relation t ρ reduction of relation t α abstraction function γ concretization function lfp⊆ F least fixpoint of F for widening narrowing ⊆ x absolute value of x X abstract counterpart of X ℘(S) parts of set S (also 2S) | | q quaternion q conjugate of quaternion q q norm of quaternion q || || N naturals Z integers R reals ∗Ecole´ normale sup´erieure, D´epartement d’informatique, 45 rue d’Ulm, 75230 Paris cedex 05, [email protected]. ∗∗Courant Institute of Mathematical Sciences, New York University, 251 Mercer Street New York, N.Y. 10012-1185, [email protected] . ‡Fundaci´on IMDEA Software, Facultad de Inform´atica (UPM), Campus Montegancedo, 28660-Boadilla del Monte, Madrid, Spain. 1of38 American Institute of Aeronautics and Astronautics Content • Brief motivation • An informal introduction to abstract interpretation • A short overview of a few applications and on-going work at ENS on aerospace software • A recent comprehensive overview paper (with all theoretical and practical details and references): J. Bertrane, P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné and X. Rival Static analysis and verification of aerospace software by abstract interpretation AIAA Infotech@Aerospace 2010, Atlanta, Georgia, USA, April 20, 2010 Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 2 © P Cousot et al. Motivation Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 3 © P Cousot et al. Computer scientists have made great contributions to the failure of complex systems All Computer Scientists Have Experienced Bugs Ariane 5.01 failure Patriot failure Mars orbiter loss (overflow) (float rounding) (unit error) • Checking the presence of bugs is great but never It is preferableends to verify that mission/safety-critical pro- gramsProving do not their go absence wrong before is even running better! them. Workshop• on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 © P Cousot et al. 4 Sep. 5, 2006 September 5, 2006 J¡¡¡—3—[] ¨ — £££I ľ P. Cousot Abstract interpretation Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 5 © P Cousot et al. Abstract interpretation • Started in the 70’s and well-developped since then • Originally for inferring program invariants (with first applications to compilation, optimization, program transformation, to help hand-made proofs, etc) • Based on the idea that undecidability and complexity of automated program analysis can be fought by approximation • Applications evolved from static analysis to verification • Does scale up! Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 6 © P Cousot et al. Fighting undecidability and complexity in program verification • Any automatic program verification method will definitely fail on infinitely many programs (Gödel) • Solutions: • Ask for human help (theorem-prover based deductive methods) • Consider (small enough) finite systems (model- checking) • Do sound approximations or complete abstractions (abstract interpretation) Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 7 © P Cousot et al. An informal introduction to abstract interpretation Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 8 © P Cousot et al. 1) Define the programming language semantics Formalize the concrete execution of programs (e.g. transition system) y y (x,y) t=0 x t=2 x t=… t=1 t Trajectory Space/time trajectory in state space Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 9 © P Cousot et al. II) Define the program properties of interest Formalize what you are interested to know about program behaviors Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 10 © P Cousot et al. III) Define which specification must be checked Formalize what you are interested to prove about program behaviors Forbiden zone Possible trajectories Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 11 © P Cousot et al. IV) Choose the appropriate abstraction Abstract away all information on program behaviors irrelevant to the proof Zone interdite Possible trajectories Abstraction of the trajectories Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 12 © P Cousot et al. V) Mechanically verify in the abstract The proof is fully automatic Forbidden zone Possible trajectories Abstraction of the trajectories Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 13 © P Cousot et al. Soundness of the abstract verification Never forget any possible case so the abstract proof is correct in the concrete Forbidden zone Possible trajectories Abstraction of the trajectories Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 14 © P Cousot et al. Unsound validation: testing Try a few cases Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 15 © P Cousot et al. Unsound validation: bounded model-checking Simulate the beginning of all executions Forbidden zone Possible trajectories Bounded model-checking Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 16 © P Cousot et al. Unsound validation: static analysis Many static analysis tools are unsound (e.g. Coverity, etc.) so inconclusive Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 17 © P Cousot et al. Incompleteness When abstract proofs may fail while concrete proofs would succeed Forbidden zone Alarm !!! Possible trajectories Error or false alarm ? By soundness an alarm must be raised for this overapproximation! Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 18 © P Cousot et al. True error The abstract alarm may correspond to a concrete error Forbidden zone Alarm !!! Possible trajectories Error Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 19 © P Cousot et al. False alarm The abstract alarm may correspond to no concrete error (false negative) Forbidden zone Alarm !!! Possible trajectories False alarm Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 20 © P Cousot et al. What to do about false alarms? • Automatic refinement: inefficient and may not terminate (Gödel) • Domain-specific abstraction: • Adapt the abstraction to the programming paradigms typically used in given domain-specific applications • e.g. synchronous control/command: no recursion, no dynamic memory allocation, maximum execution time, etc. Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 21 © P Cousot et al. ASTRÉE Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 22 © P Cousot et al. Target language and applications • C programming language • Without recursion, longjump, dynamic memory allocation, conflicting side effects, backward jumps, system calls (stubs) • With all its horrors (union, pointer arithmetics, etc) • Reasonably extending the standard (e.g. size & endianess of integers, IEEE 754-1985 floats, etc) • Synchronous control/command • e.g. generated from Scade Workshop