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 on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 23 © P Cousot et al. The semantics of C implementations is very hard to define The Semantics of C is Hard (Ex. 2: Runtime Errors) What is the effect of out-of-bounds array indexing? %catunpredictable.c #include
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 24 © P Cousot et al.
MPI, 8/26/2008 — 46 — ľ P. Cousot Implicit specification • Absence of runtime errors: overflows, division by zero, buffer overflow, null & dangling pointers, alignment errors, … • Semantics of runtime errors: • Terminating execution: stop (e.g. floating-point exceptions when traps are activated) • Predictable outcome: go on with worst case (e.g. signed integer overflows result in some integer, some options: e.g. modulo arithmetics) • Unpredictable outcome: stop (e.g. memory corruption) Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 25 © P Cousot et al. II.P. Combination of abstract domains Abstract interpretation-based tools usually use several different abstract domains, since the design of a complex one is best decomposed into a combination of simpler abstract domains. Here are a few abstract 2 domain examples used in the Astree´ staticAbstractions analyzer: y y y
x x x
Collecting semantics:1, 5 Intervals:20 Simple congruences:24 partial traces x [a, b] x a[b] ∈ ≡ y y y t x x
Octagons:25 Ellipses:26 Exponentials:27 x y a x2 + by2 axy d abt y(t) abt ± ± − − Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 26 © P Cousot et al. Such abstract domains (and more) are described in more details in Sects. III.H–III.I. The following classic abstract domains, however, are not used in Astree´ because they are either too imprecise, not scalable, difficult to implement correctly (for instance, soundness may be an issue in the event of floating-point rounding), or out of scope (determining program properties which are usually of no interest to prove the specification): y y y
x x x
Polyhedra:9 Signs:7 Linear congruences:28 too costly too imprecise out of scope
Because abstract domains do not use a uniform machine representation of the information they manip- ulate, combining them is not completely trivial. The conjunction of abstract program properties has to be performed, ideally, by a reduced product 7 for Galois connection abstractions. In absence of a Galois connec- tion or for performance reasons, the conjunction is performed using an easily computable but not optimal over-approximation of this combination of abstract domains. Assume that we have designed several abstract domains and compute lfp⊆ F1 D1,...,lfp⊆ Fn Dn in these abstract domains D ,...,D , relative to a collecting semantics t I. The∈ combination of∈ these 1 n C analyses is sound as t I γ (lfp⊆ F ) γ (lfp⊆ F ). However, only combining the analysis results is C ⊆ 1 1 ∩ ···∩ n n not very precise, as it does not permit analyses to improve each other during the computation. Consider, for instance, that interval and parity analyses find respectively that x [0, 100] and x is odd at some iteration. Combining the results would enable the interval analysis to continue∈ with the interval x [1, 99] and, e.g., avoid a useless widening. This is not possible with analyses carried out independently. ∈ Combining the analyses by a reduced product, the proof becomes “let F ( x ,...,x ) ρ( F (x ),..., 1 n 1 1 Fn(xn ) and r1,...,rn =lfp⊆ F in t I γ1(r1) γn(rn)” where ρ performs the reduction between abstract domains. For example ρ( [0,C100], odd⊆ )= ∩[1···, 99]∩, odd . 10 of 38
American Institute of Aeronautics and Astronautics Octagon Abstract Domain
Code Sample:
while (1) { • At !, the interval domain gives R=A-Z; L ≤ max(max A, (max Z)+(max V)). L=A; if (R>V) • In fact, we have L ≤ A. { ! L=Z+V;} ! • To discover this, we must know at ! that } R = A-Z and R > V. OctagonOctagon Abstract Domain Domain Solution: we need a numerical relational abstract domain. CodeExample Sample: of general purpose abstraction: octagons Code" The Sample:octagon abstract domain [Min´e03] is a good cost / precision trade-off. Octagon Abstract DomainN2 N3 "whileInvariants (1) of the form ± x± y ≤ c, with O( ) memory and O( ) time cost. •while (1) {{ • At !, the interval domain gives Code" Here,R=A-Z; Sample:R = A-Z cannot be discovered,• At !, but the we interval get L- domainZ ≤ max givesR which is sufficient. • Example:R=A-Z; LL ≤≤ max(maxmax(max AA,, (max (max ZZ)+(max)+(max VV)))).. " WeL=A;L=A; use many octagons on small packs of variables instead of a large one using if (R>V) • allif variables (R>V) to cut costs. • InIn fact, we have LL ≤≤ AA.. while! (1) { { ! L=Z+V;L=Z+V;} • At !, the interval domain gives R=A-Z;{ } • To discover this, we must know at ! that PLDI’03!! - A Static Analyzer for Large Safety-Critical• To discoverL ≤ max(max Software this, weA must, (max knowZ)+(max at ! thatV)). 11/21 L=A; R = A-Z and R > V. }} R = A-Z and R > V. if (R>V) • In fact, we have L ≤ A. Solution:{ we! needL=Z+V; a numerical} relational abstract domain. Solution:! we need a numerical relational• To discoverabstract this, domain. we must know at ! that " The abstract domain [Min´e03]R = A-Z isand a goodR > costV. / precision trade-off. " }The octagonoctagon abstract domain [Min´e03] is a good cost / precisionII.P. Combination trade-o of abstractff. domains 2 Abstract3 interpretation-based tools usually use several different abstract domains, since the design of a " N2 Ncomplex3 one is best decomposed into a combination of simpler abstract domains. Here are a few abstract " InvariantsInvariants of the form ±±xx±±yy ≤≤ cc,, with with OO((N )) memorymemory and OO((Ndomain) examples) timetime used in the cost.Astree´ static analyzer:2 y y y Solution:•"" Here,Here, RR ==weAA--ZZ needcannotcannot a numerical be discovered,relational but we we get getabstractLL--ZZ ≤≤ maxmax domain.RR whichwhich is suffifficient.cient. x x x """WeWe use many octagons on on smallsmall packs ofof variables instead of a large large one one using using The octagon abstract domain [Min´e03] is a good cost / precision trade-o1, 5 ff. 20 24 • Collecting semantics: Intervals: Simple congruences: all variables to cut costs. partial traces x [a, b] x a[b] all variables to cut costs. 2 3 ∈ ≡ " Invariants of the form ± x± y ≤ c, with O(N ) memory and O(N )y time cost.y y t x x PLDI’03PLDI’03" Here, - A StaticR = AnalyzerA-Z cannot for for Large Large be Safety-Critical Safety-Critical discovered, Software Software but we get L-Z ≤ max R which is 11/ 11/ su2121fficient.
25 26 27 Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 © POctagons: Cousot et al. Ellipses: Exponentials: " 27 x y a x2 + by2 axy d abt y(t) abt We use many octagons on small packs of variables instead of a large± ± one using− − Such abstract domains (and more) are described in more details in Sects. III.H–III.I. The following classic abstract domains, however, are not used in Astree´ because they are either too all variables to cut costs. imprecise, not scalable, difficult to implement correctly (for instance, soundness may be an issue in the event of floating-point rounding), or out of scope (determining program properties which are usually of no interest to prove the specification): y y y PLDI’03 - A Static Analyzer for Large Safety-Critical Software 11/21 x x x
Polyhedra:9 Signs:7 Linear congruences:28 too costly too imprecise out of scope
Because abstract domains do not use a uniform machine representation of the information they manip- ulate, combining them is not completely trivial. The conjunction of abstract program properties has to be performed, ideally, by a reduced product 7 for Galois connection abstractions. In absence of a Galois connec- tion or for performance reasons, the conjunction is performed using an easily computable but not optimal over-approximation of this combination of abstract domains. Assume that we have designed several abstract domains and compute lfp⊆ F1 D1,...,lfp⊆ Fn Dn in these abstract domains D ,...,D , relative to a collecting semantics t I. The∈ combination of∈ these 1 n C analyses is sound as t I γ (lfp⊆ F ) γ (lfp⊆ F ). However, only combining the analysis results is C ⊆ 1 1 ∩ ···∩ n n not very precise, as it does not permit analyses to improve each other during the computation. Consider, for instance, that interval and parity analyses find respectively that x [0, 100] and x is odd at some iteration. Combining the results would enable the interval analysis to continue∈ with the interval x [1, 99] and, e.g., avoid a useless widening. This is not possible with analyses carried out independently. ∈ Combining the analyses by a reduced product, the proof becomes “let F ( x ,...,x ) ρ( F (x ),..., 1 n 1 1 Fn(xn ) and r1,...,rn =lfp⊆ F in t I γ1(r1) γn(rn)” where ρ performs the reduction between abstract domains. For example ρ( [0,C100], odd⊆ )= ∩[1···, 99]∩, odd . 10 of 38
American Institute of Aeronautics and Astronautics Example of general purpose abstraction: Example of abstract domaindecision functor trees in Astrée: decision trees – Code Sample: /* boolean.c */ typedef enum {F=0,T=1} BOOL; BOOL B; void main () { unsigned int X, Y; while (1) { ... B=(X==0); ... if (!B) { The boolean relation abstract Y=1/X; domainThe boolean is parameterized relation abstract by the do- main is parameterized by the height } height of the decision tree (an ... of the decision tree (an analyzer } analyzeroption) and the option) abstract and domain the at } abstractthe leafs domain at the leaves Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 28 © P Cousot et al. MPI, 8/26/2008 — 66 — ľ P. Cousot Example of domain-specificExample of analysis abstraction: by Astrée ellipses(suite) typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; BOOLEAN INIT; float P, X; void filter () { static float E[2], S[2]; if (INIT) { S[0] = X; P = X; E[0] = X; } else {P=(((((0.5*X)-(E[0]*0.7))+(E[1]*0.4)) +(S[0]*1.5))-(S[1]*0.7));} E[1] = E[0]; E[0] = X; S[1] = S[0]; S[0] = P; /* S[0], S[1] in [-1327.02698354, 1327.02698354]*/ II.P. Combination of abstract domains Abstract interpretation-based tools usually use several different abstract domains, since the design of a } complex one is best decomposed into a combination of simpler abstract domains. Here are a few abstract domain examples used in the Astree´ static analyzer:2 void main () { X = 0.2 * X + 5; INIT = TRUE; y y y while (1) { x x x
Collecting semantics:1, 5 Intervals:20 Simple congruences:24 X=0.9*X+35;/* simulated filter input */partial traces x [a, b] x a[b] ∈ ≡ filter (); INIT = FALSE; } y y y t } x x Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 29 Octagons: 25 © Ellipses:P Cousot26 et al. Exponentials:27 x y a x2 + by2 axy d abt y(t) abt ± ± − − Such abstract domains (and more) are described in more details in Sects. III.H–III.I. The following classic abstract domains, however, are not used in Astree´ because they are either too imprecise, not scalable, difficult to implement correctly (for instance, soundness may be an issue in the event of floating-point rounding), or out of scope (determining program properties which are usually of no interest to prove the specification): y y y
x x FICS’08, Shanghai, 3–6/6/2008 — 64 — x ľ P. Cousot
Polyhedra:9 Signs:7 Linear congruences:28 too costly too imprecise out of scope
Because abstract domains do not use a uniform machine representation of the information they manip- ulate, combining them is not completely trivial. The conjunction of abstract program properties has to be performed, ideally, by a reduced product 7 for Galois connection abstractions. In absence of a Galois connec- tion or for performance reasons, the conjunction is performed using an easily computable but not optimal over-approximation of this combination of abstract domains. Assume that we have designed several abstract domains and compute lfp⊆ F1 D1,...,lfp⊆ Fn Dn in these abstract domains D ,...,D , relative to a collecting semantics t I. The∈ combination of∈ these 1 n C analyses is sound as t I γ (lfp⊆ F ) γ (lfp⊆ F ). However, only combining the analysis results is C ⊆ 1 1 ∩ ···∩ n n not very precise, as it does not permit analyses to improve each other during the computation. Consider, for instance, that interval and parity analyses find respectively that x [0, 100] and x is odd at some iteration. Combining the results would enable the interval analysis to continue∈ with the interval x [1, 99] and, e.g., avoid a useless widening. This is not possible with analyses carried out independently. ∈ Combining the analyses by a reduced product, the proof becomes “let F ( x ,...,x ) ρ( F (x ),..., 1 n 1 1 Fn(xn ) and r1,...,rn =lfp⊆ F in t I γ1(r1) γn(rn)” where ρ performs the reduction between abstract domains. For example ρ( [0,C100], odd⊆ )= ∩[1···, 99]∩, odd . 10 of 38
American Institute of Aeronautics and Astronautics Example of domain-specificArithmetic-geometric abstraction: progressions exponentials (Example 2) %catcount.c typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; volatile BOOLEAN I; int R; BOOLEAN T; void main() { R=0; while (TRUE) { __ASTREE_log_vars((R)); potential overflow! if (I) { R = R + 1; } else { R = 0; } T=(R>=100); __ASTREE_wait_for_clock(()); II.P. Combination of abstract domains }} Abstract interpretation-based tools usually use several different abstract domains, since the design of a complex one is best decomposed into a combination of simpler abstract domains. Here are a few abstract domain examples used in the Astree´ static analyzer:2 %catcount.config y y y
__ASTREE_volatile_input((I [0,1])); x x x __ASTREE_max_clock((3600000)); Collecting semantics:1, 5 Intervals:20 Simple congruences:24 partial traces x [a, b] x a[b] %astree–exec-fnmain–config-semcount.configcount.c|grep’|R|’∈ ≡ y y y t |R| <= 0. + clock *1. <= 3600001. x x
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 © P Cousot et al. 30 Octagons:25 Ellipses:26 Exponentials:27 2 2 bt bt More precise than the clock domain (intervalsx y a x + by a forxy d aX y(t), a X + clock, ± ± − − Such abstract domains (and more) are described in more details in Sects. III.H–III.I. The following classic abstract domains, however, are not used in Astree´ because they are either too imprecise, not scalable, difficult to implement correctly (for instance, soundness may be an issue in the event X clock) which could thereforeof floating-point be rounding),suppressed! or out of scope (determining program properties which are usually of no interest ` to prove the specification): y y y MPI, 8/26/2008 — 84 — ľ P. Cousot x x x
Polyhedra:9 Signs:7 Linear congruences:28 too costly too imprecise out of scope
Because abstract domains do not use a uniform machine representation of the information they manip- ulate, combining them is not completely trivial. The conjunction of abstract program properties has to be performed, ideally, by a reduced product 7 for Galois connection abstractions. In absence of a Galois connec- tion or for performance reasons, the conjunction is performed using an easily computable but not optimal over-approximation of this combination of abstract domains. Assume that we have designed several abstract domains and compute lfp⊆ F1 D1,...,lfp⊆ Fn Dn in these abstract domains D ,...,D , relative to a collecting semantics t I. The∈ combination of∈ these 1 n C analyses is sound as t I γ (lfp⊆ F ) γ (lfp⊆ F ). However, only combining the analysis results is C ⊆ 1 1 ∩ ···∩ n n not very precise, as it does not permit analyses to improve each other during the computation. Consider, for instance, that interval and parity analyses find respectively that x [0, 100] and x is odd at some iteration. Combining the results would enable the interval analysis to continue∈ with the interval x [1, 99] and, e.g., avoid a useless widening. This is not possible with analyses carried out independently. ∈ Combining the analyses by a reduced product, the proof becomes “let F ( x ,...,x ) ρ( F (x ),..., 1 n 1 1 Fn(xn ) and r1,...,rn =lfp⊆ F in t I γ1(r1) γn(rn)” where ρ performs the reduction between abstract domains. For example ρ( [0,C100], odd⊆ )= ∩[1···, 99]∩, odd . 10 of 38
American Institute of Aeronautics and Astronautics ExampleExample of domain-specific of analysis by abstraction:Astrée (suite) exponentials Example of analysis by Astrée (suite) %catretro.c typedef%catretro.c enum {FALSE=0, TRUE=1} BOOL; void main() void main() BOOL FIRST;typedef enum {FALSE=0, TRUE=1} BOOL; {FIRST=TRUE; {FIRST=TRUE; volatileBOOL BOOL FIRST; SWITCH; while (TRUE) { while (TRUE) { volatilevolatile float E; BOOL SWITCH; dev( ); dev( ); float P,volatile X, A, B; float E; FIRST = FALSE; float P, X, A, B; __ASTREE_wait_for_clock(());FIRST = FALSE; void dev( ) }} __ASTREE_wait_for_clock(()); {X=E; void dev( ) %catretro.config}} if (FIRST){X=E; { P = X; } __ASTREE_volatile_input((E%catretro.config [-15.0, 15.0])); else if (FIRST) { P = X; } __ASTREE_volatile_input((SWITCH__ASTREE_volatile_input((E [0,1])); [-15.0, 15.0])); {P=else (P-((((2.0*P)-A)-B) __ASTREE_max_clock((3600000));__ASTREE_volatile_input((SWITCH [0,1])); {P= (P-((((2.0*P)-A)-B) __ASTREE_max_clock((3600000)); *4.491048e-03));}; |P| <= (15. + 5.87747175411e-39 *4.491048e-03));}; B=A; /1.19209290217e-07)*(1+|P| <= (15. + 5.87747175411e-39 B=A; II.P. Combination of abstract domains if (SWITCH) {A = P;} /1.19209290217e-07)*(1+Abstract interpretation-based tools usually use several different abstract domains, since the design of a 1.19209290217e-07)ˆclockcomplex one is best decomposed into - a combination 5.87747175411e-39 of simpler abstract domains. Here are a few abstract if (SWITCH) {A = P;} 2 else {A = X;} /1.19209290217e-07<=1.19209290217e-07)ˆclockdomain examples used in the Astr23.0393526881ee´ static analyzer: - 5.87747175411e-39 } else {A = X;} /1.19209290217e-07<=y y23.0393526881y } x x x
Collecting semantics:1, 5 Intervals:20 Simple congruences:24 partial traces x [a, b] x a[b] ∈ ≡ y y y t x x
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 31 Octagons: 25 Ellipses: 26 Exponentials: © P Cousot 27et al. x y a x2 + by2 axy d abt y(t) abt ± ± − − FICS’08, Shanghai, 3–6/6/2008 — 65 — Such abstract domains (and more) are described in more details in Sects.ľ III.H–III.I.P. Cousot The following classic abstract domains, however, are not used in Astree´ because they are either too FICS’08, Shanghai, 3–6/6/2008 —imprecise, 65 not — scalable, difficult to implement correctly (for instance, soundness may be anľ issue in theP. event Cousot of floating-point rounding), or out of scope (determining program properties which are usually of no interest to prove the specification): y y y
x x x
Polyhedra:9 Signs:7 Linear congruences:28 too costly too imprecise out of scope
Because abstract domains do not use a uniform machine representation of the information they manip- ulate, combining them is not completely trivial. The conjunction of abstract program properties has to be performed, ideally, by a reduced product 7 for Galois connection abstractions. In absence of a Galois connec- tion or for performance reasons, the conjunction is performed using an easily computable but not optimal over-approximation of this combination of abstract domains. Assume that we have designed several abstract domains and compute lfp⊆ F1 D1,...,lfp⊆ Fn Dn in these abstract domains D ,...,D , relative to a collecting semantics t I. The∈ combination of∈ these 1 n C analyses is sound as t I γ (lfp⊆ F ) γ (lfp⊆ F ). However, only combining the analysis results is C ⊆ 1 1 ∩ ···∩ n n not very precise, as it does not permit analyses to improve each other during the computation. Consider, for instance, that interval and parity analyses find respectively that x [0, 100] and x is odd at some iteration. Combining the results would enable the interval analysis to continue∈ with the interval x [1, 99] and, e.g., avoid a useless widening. This is not possible with analyses carried out independently. ∈ Combining the analyses by a reduced product, the proof becomes “let F ( x ,...,x ) ρ( F (x ),..., 1 n 1 1 Fn(xn ) and r1,...,rn =lfp⊆ F in t I γ1(r1) γn(rn)” where ρ performs the reduction between abstract domains. For example ρ( [0,C100], odd⊆ )= ∩[1···, 99]∩, odd . 10 of 38
American Institute of Aeronautics and Astronautics Example of analysis by Astrée (suite) An erroneousA common common believe belief on static on analyzersstatic analyzers typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; “The properties that canBOOLEAN be proved INIT; byfloat staticP, X; analyzers are often void filter () { simple” [2] static float E[2], S[2]; Like in mathematics: if (INIT) { S[0] = X; P = X; E[0] = X; } else {P=(((((0.5*X)-(E[0]*0.7))+(E[1]*0.4)) – May be simple to state (no overflow)+(S[0]*1.5))-(S[1]*0.7));} E[1] = E[0]; E[0] = X; S[1] = S[0]; S[0] = P; – But harder to discover/*(( S[0],P S[1][ 1325 in [-1327.02698354:4522; 1325,:4522]1327.02698354) ]*/) } 2 ` – And difficult to provevoid(sincemain () it { requires X = 0.2 * finding X + 5; INIT a non = TRUE; trivial non-linear invariant forwhile second(1) { order filters with complex roots [Fer04], which canX=0.9*X+35; hardly be found/* simulated by exhaustive filter input enu- */ filter (); INIT = FALSE; } meration) }
Reference
[2] Vijay D’Silva, Daniel Kroening, and Georg Weissenbacher. A Survey of Automated Techniques for Formal Software Verification. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 27, No. 7, July 2008. FICS’08, Shanghai, 3–6/6/2008 — 64 — ľ P. Cousot MPI, 8/26/2008 J✁✁ ✁ – 37 – ? [] ¨ – ✄ ✄✄ I ľ P. Cousot
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 32 © P Cousot et al. Industrial applications
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 33 © P Cousot et al. Examples of applications • Verification of the absence of runtime-errors in • Fly-by-wire flight control systems
• ATV docking system
• Flight warning system (on-going work)
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 34 © P Cousot et al. Industrialization • 8 years of research (CNRS/ENS/INRIA): www.astree.ens.fr
• Industrialization by AbsInt (since Jan. 2010): www.absint.com/astree/
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 35 © P Cousot et al. On-going work
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 36 © P Cousot et al. Verification of target programs
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 37 © P Cousot et al. Verification of compiled programs • The valid source may be proved correct while the certified compiler is incorrect so the target program may go wrong • Possible approaches: • Verification at the target level • Source to target proof translation and proof check on the target ✴ Translation validation (local verification of equivalence of run-time error free source and target) • Formally certified compilers
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 38 © P Cousot et al. Verification of imperfectly clocked synchronous systems
Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 39 © P Cousot et al. But these computations are performed according to two clocks C and C. It may be that these clocks are synchronous. This case is depicted in the lower left part of Fig. 2. The two alternating boolean outputs of the two systems being always equal, the comparison always results in no alarm (OK statement). But maybe the clocksButC theseand C computations are slightly desynchronized are performed according by a small to delay two clocksε. ThisC and caseC is. depicted It may be in that the these clocks are lower right part ofsynchronous. Fig.2. The two This alternating case is depicted boolean in outputsthe lower of left the part two of systems Fig. 2. are The then two alternatingalmost always boolean outputs of equal, but they difftheer near two systems every clock being tick. always Then, equal,Imperfect the the comparison comparison being always made results synchrony precisely in no alarm on those (OK statement). tick, it always results into anBut alarm maybe (“!= the” statement). clocks C and However,C are slightly thisdesynchronized alarm is probably by a unnecessary small delay ε in. This that case case, is depicted in the since the desynchronizationlower right delay part is of very Fig.2. small. The This two desynchronization alternating boolean delay outputs is in practice of the two unavoidable, systems are since then almost always clocks are physical objectsequal, but andExample they cannot differ be near perfect. of every This(buggy) clock implementation tick. Then, communicating the of an comparison alarm is therefore being made flawed.synchronous precisely Such on those tick, systems: it errors cannot be alwaysalways• discovered results into by an hand. alarm Their (“!= detection” statement). has to However, be done this automatically alarm is probably and statically. unnecessary in that case, since the desynchronization delay is very small. This desynchronization delay is in practice unavoidable, since clocks are physical objects and cannot be perfect. This implementation of an alarmblackboard is therefore flawed. inputs Such errors cannot be always discovered by hand. Their detection has to be done automatically and statically. READ READ C C’ • negate previous input NOT COMPARE READ NOT READ C C’ (on clocks C and C’)
C NOT COMPARE C’ NOT • compare inputs System 1 System 2 C Real C’ Real 023451 time 023451 time System 1 System 2 Synchronized andC’ dysynchronized executions:C’ true true System 2 • Real Real 023451 time 023451 time false false C’ C’ System 2 true true false false true true
false false System 1 εεεε ε true C true C false false Systemtrue 1 true εεεε ε OKOK OK OK OK !=C != != != != C false false COMPARE true C true C OKOK OK OK OK !=!= != != != false false flawed COMPARE Figure 2. Example of two similar imperfectly-synchronous systems with an alarm watchingC differences in their outputs. C alarms WorkshopFigure on formal 2. Exampleverification of avionics of two software similar products, imperfectly-synchronous Airbus France, Toulouse, June 24–25, systems 2010 with 40 an alarm watching di ff erences in their outputs. © P Cousot et al. IV.B. Syntax and semantics
We assume that eachIV.B. part Syntax of the synchronous and semantics software compiled for one precise computer will execute according to the clock C of that computer with a period (the time between two consecutive clock ticks) remaining inside a knownWe assume interval that [µC each; νC], part with of 0 <µ theC synchronous νC. In the software quasi-synchronous compiled for framework one precise introduced computer will execute formally by Caspi etaccording al.,58 two to theclocks clock supposedC of that to computertick synchronously with a period are allowed (the time to betweendesynchronize two consecutive in the clock ticks) following way: at mostremaining two consecutive inside a known ticks interval of one [ ofµC; theνC], clock with 0may<µ happenC νC. In between the quasi-synchronous two consecutive framework ticks introduced 58 of the other clock. Thisformally hypothesis by Caspi is et quite al., weak,two and clocks we supposed usually work to tick with synchronously a clock whose are parameter allowed to is desynchronize such in the following way: at most two consecutive ticks of one of the clock may happen between two consecutive ticks that 2 µC νC, which implies quasi-synchrony compared to a perfect clock whose period is between µC and × of the other clock. This hypothesis is quite weak, and we usually work with a clock whose parameter is such νC.WhenµC is close to νC, our hypothesis is stronger and we expect to be able to prove more properties. that 2 µC νC, which implies quasi-synchrony compared to a perfect clock whose period is between µC and Furthermore, each communication× channel ch has an interval [αch; βch] as parameter such that the delays between the emissionνC.When of a valueµC is and close its to receptionνC, our hypothesis must always is stronger belong to and this we interval. expect to The be communications able to prove more properties. over a given channel areFurthermore, still considered each communicationserial, which means channel thatch ifhas a value an intervala is sent [αch over; βch] channel as parameterch before such that the delays between the emission of a value and its reception must always belong to this interval. The communications a value b,thena is received before b. over a given channel are still considered serial, which means that if a value a is sent over channel ch before In this realistic framework, idealistic cases usually considered can still be modelled. It is then assumed a value b,thena is received before b. that all clocks C, C’,... are perfect: µ = ν = µ = ν = ... and that communications are instantaneous, In this realisticC framework,C C’ idealisticC’ cases usually considered can still be modelled. It is then assumed i.e., 0 = αch = βch = αch’ = βch’ for all the channels ch, ch’,... in the system. that all clocks C, C’,... are perfect: µC = νC = µC’ = νC’ = ... and that communications are instantaneous, i.e., 0 = αch = βch = αch’ = βch’ for all the channels ch, ch’,... in the system.
26 of 38
American Institute of Aeronautics and Astronautics26 of 38 American Institute of Aeronautics and Astronautics were in fact designed in a continuous world (through differential equations) in an environment (made of space and time) that is a continuous object. In addition, using a continuous-time semantics enables the use of very well-known mathematical theories about continuous numbers which are not so frequently used in static analysis. were in fact designed in a continuous world (through differential equations) in an environment (made of IV.D. Temporal abstract domains space andwere time) in that fact designed is a continuous in a continuous object. In world addition, (through using di afferential continuous-time equations) semantics in an environment enables the (made use of IV.D.1. Abstractof constraints very well-knownspace and time) mathematical that is a continuous theories about object. continuous In addition, numbers using a whichcontinuous-time are not so semantics frequently enables used the in use A first domain ofstatic abstract analysis. constraints59 abstracts ℘(R V) as conjunctive sets of universal and existential of very well-known→ mathematical theories about continuous numbers which are not so frequently used in constraints. A universal constraint over a signal s R V is defined by a time interval [a; b] and a value x, ∈ → and denoted t [a; b]:s(t)=staticx. Its concretization analysis. is the set of signals in R V that take the value x during the whole time∀ interval∈IV.D. [a; b]. Temporal An existential constraint abstractSemantics over a domains signal and sabstractionsis defined→ by a time interval [a; b] and a value x, and denoted t [a; b]:s(t)=x.Continuous Its concretization semantics is the (value set of s(t) signals of signals in R s atV thatany take the value x at least once during∃ the∈ timeIV.D. interval• [a Temporal; b]. For example, abstractt [0; 1] : domainss(t)=true →t [0; 1] : s(t)=false IV.D.1. Abstracttime constraints t) ∃ ∈ ∧∃ ∈ is the abstraction of functions in R B that change their boolean value at least once between t = 0 and t = 1. IV.D.1.→ Abstract constraints A first domain of• Clock abstract ticks and constraints serial communications59 abstracts do happen℘(R in V) as conjunctive sets of universal and existential The operators defined for usual operationsknown in time abstract intervals domains [l, h], ( l ≤, h) as well59 as the backward→ abstract operators correspondingconstraints. to synchronousA first A universal domain language of primitives constraint abstract ( >, constraints overpre∪,∩blackboard a signalabstracts reading,s etc.)℘ are(Ris quite definedV) as conjunctive by a time interval sets of universal [a; b] andand a valueexistentialx, − R V → precise in this domain. constraints.• Examples A universal of abstractions constraint: over a signal∈ →s R V is defined by a time interval [a; b] and a value x, and denoted t [a; b]:s(t)=x. Its concretization is the∈ set of→ signals in R V that take the value x during and∀ denoted∈ t [a; b]:s(t)=x. Its concretization is the set of signals→ in R V that take the value x during IV.D.2. Changesthe counting whole domain time interval• ∀ [∈a; b]. An existential constraint over a signal s is defined by→ a time interval [a; b] and a the whole time interval [a; b]. An existential constraint over a signal s is defined by a time interval [a; b] and a A second domainvalue of changex, and counting denoted60 was• designedt [a in; orderb]:s to(t deal)= automaticallyx. Its concretization with reasoning on is the the set of signals in R V that take the value value x, and denoted∃ ∈ t [a; b]:s(t)=x. Its concretization+ is the set of signals→ in R V that take the value stability and thex variabilityat least of systems. once during The• abstractchange the properties counting time∃ ∈ interval ( k, a [ba); andb]. ( Fork, a example,b), for a, b tR [0; 1] : s(t)=true t →[0; 1] : s(t)=false and k , respectively meanx thatat behaviors least once do not during change thetheir timevalue more interval (respectively [a; b]. less) For than example,k∃times∈ ∈ t [0; 1] : s(t)=∧∃true ∈ t [0; 1] : s(t)=false N is the abstraction of(signal functions changes inless (more) thanthat k times change in time their boolean value at least once between t = 0 and during∈ the time interval [a; b]. R B ∃ ∈ ∧∃ ∈ is the abstractioninterval [ ofa, b functions]) → in R B that change their boolean value at least once between t = 0 and This domaint is= more 1. precise for forward operators and defines a very precise→ reduced product with the t = 1.Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 41 © P Cousot et al. abstract constraint domain.The operators defined for usual operations in abstract domains ( , ) as well as the backward abstract An example of reduction is (withThe times operatorsa American Institute28 of of 38 Aeronautics and Astronautics American Institute of Aeronautics and Astronautics Real code Analysis Analysis Static analysis of communicatingReal code Analysis imperfectlyAnalysis clocked redundantStatic units analysisExample of communicating of static imperfectly analysis clocked redundant units SENSORS Changes Counting SENSORS Constraints Constraints Changes Counting [ ! ; "] [ # ; $ ] Constraints Constraints For how long Changes Changes [ ; ] Counting [ ! ; "] Counting # $ Changes Changes Counting Counting should the input REDUNDANT UNIT #1 REDUNDANT UNIT #2 be stabilized REDUNDANT UNIT #1 REDUNDANT UNIT #2 before deciding Changes Changes Counting [ % ; &] Counting Changes [ ' ; (] Changes Counting [ % ; &] Counting [ ' ; (] on disagreement? Constraints ACTUATORS Changes ConstraintsACTUATORS ACTUATORS Counting Changes ACTUATORS Counting VOTER VOTER Integral bounding Integral bounding SpecificationSpecification:noalarmraisedwithanormalinput:noalarmraisedwithanormalinput 0 0 2/3 ) 2/3 ) ) ) < 2 2 > input stabilityinput< ∆ stability: Between∆ : 3 Between× ∆ input3 × ∆ stabilityinput> stability∆ :theanalyzer∆ :theanalyzer counter-examplecounter-exampleand ∆ : ? and ∆ : ?proves theproves specification the specification Julien Bertrane, ENS Paris Static analysis of imperfectly-clocked synchronous systems using continuous-time abstract domains 45/49 Julien Bertrane, ENS ParisWorkshop on formalStatic verification analysis of avionics of software imperfectly-clocked products, Airbus France, synchronousToulouse, June 24–25, syste 2010ms using42 continuous-time abstract domains 45/49 © P Cousot et al. THÉSÉE: Verification of embedded real-time parallel C programs Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 43 © P Cousot et al. Parallel programs • Bounded number of processes with shared memory, events, semaphores, message queues, blackboards,… • Processes created at initialization only • Real time operating system (ARINC 653) with fixed priorities (highest priority runs first) • Scheduled on a single processor Verified properties • Absence of runtime errors • Absence of unprotected data races Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 44 © P Cousot et al. Semantics • No memory consistency model for C • Optimizing compilers consider sequential processes out of their execution context init: flag1 = flag2 = 0 process 1: process 2: flag1 = 1; flag2 = 1; write to flag1/2 and if (!flag2) if (!flag1) read of flag2/1 are independent so can be { { /* critical section */ /* critical section */ reordered → error! In the Java memory model, both processes can enter their critical section simultaneously. The rationale is that, due to process-wide• We program assume optimisation: without knowledge of other processes, a compiler might assume that, e.g., in process 1, thesequential write to flag1 consistencyand the read from inflag2 absenceare independent of data and canrace be reordered, and the same for process• 2, flag2 and flag1 respectively. As a consequence, each process can read the other process’ flag before forsetting data its own races, flag. Multi-processors values are with limited out-of-order by execution possible or not fully synchronized caches can also• cause similar behaviors, even in the absence of compiler optimizations. There is currently no memoryinterleavings consistency model forbetween C; however, synchronization we need to choose one inpoints order to define our concrete semantics. It is safe to assume that, as C++, C will guarantee sequential consistency 75 for programs withoutWorkshop data-race. on formal verification of Weavionics software also products, draw Airbus fromFrance, Toulouse, the June Java 24–25, 2010 model 45 to give a semantics to unprotected © P Cousot et al. accesses, so that we can analyze the behavior of a program after a data-race. More precisely, assume that a run of a process p performs a sequence of synchronisation operations at times t1 <... VI.B.2. Scheduling and synchronisation The U state component in our concrete semantics models the scheduler state, which in turns defines which process can run and which must wait. Firstly, it maintains the state of synchronisation objects, e.g., for each mutex (there are finitely many), whether it is unlocked or locked by a process (and which one). Secondly, it remembers, for each process, whether it is waiting for a resource internal to the system (e.g., trying to lock an already locked mutex), for an external event (e.g., a message from the environment or a timeout), or is runnable (i.e., either actually running or preempted by another process). As we assume that the scheduler obeys a strict real-time semantics and there is a single processor, only one process can be scheduled in a given state: the runnable process with highest priority. All higher priority processes are waiting at a system call, while lower priority processes can be either waiting at a system call, or be runnable and preempted at any program point. The execution of a synchronisation primitive by the running process updates the scheduling state U. For instance, trying to lock an already locked mutex causes the process to enter a wait state, while unlocking a locked mutex causes either the mutex to be unlocked (if no process is waiting for it), or the mutex ownership to pass to the highest priority process waiting for it (which then becomes runnable, and possibly preempts the current process). Moreover, U might change due to external events, which we assume can take place at any time. For instance, a process performing a timed wait enters a non-deterministic wait phase but can become runnable at any time (as we do not model physical time), and possible preempt a lower priority running process. VI.C. Abstraction Our prototype analyzer of parallel embedded realtime software, named Thes´ ee´ , is based on Astree´ (Sect. III). It has a similar structure, reuses most of its abstractions (e.g., general-purpose numerical ab- stractions for Di, trace partitioning with respect to Ci, etc.) and adds some more. 32 of 38 American Institute of Aeronautics and Astronautics Abstractions • Based on Astrée for the sequential processes • Takes scheduling into account • OS entry points (semaphores, logbooks, sampling and queuing ports, buffers, blackboards, …) are all stubbed (using Astrée stubbing directives) • Interference between processes: flow-insensitive abstraction of the writes to shared memory and inter-process communications Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 46 © P Cousot et al. Example of application: FWS • Degraded mode (5 processes, 100 000 LOCS): • 1h40 on 64-bit 2.66 GHz Intel server • 98 alarms • Full mode (15 processes, 1 600 000 LOCS): • 50 h • 12 000 alarms !!! more work is being done !!! (e.g. analysis of complex data structures, logs, etc) Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 47 © P Cousot et al. Conclusion Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 48 © P Cousot et al. Cost-effective verification • The rumor has it that: • Manuel validation (testing) is costly, unsafe, not a verification! • Formal proofs by theorem provers are extremely laborious and not reusable hence costly • Model-checkers do not scale up • Why not try abstract interpretation? • Domain-specific static analysis scales and can deliver no false alarm (but this requires developments of the analyzer by specialists) Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 49 © P Cousot et al. The End Workshop on formal verification of avionics software products, Airbus France, Toulouse, June 24–25, 2010 50 © P Cousot et al.