Motivation. Automatic Large-Scale Software Verification by Abstract Interpretation. Patrick Cousot. Content. Abstract

Size: px

Start display at page:

Download "Motivation. Automatic Large-Scale Software Verification by Abstract Interpretation. Patrick Cousot. Content. Abstract"

Madeleine Kelley
5 years ago
Views:

1 Automatic Large-Scale Software Verification b Abstract Interpretation di.ens.fr di.ens.fr/~cousot Patrick Cousot cims. nu. edu cims. nu. edu /~pcousot Tsinghua Software Da Beijing, China March 15, 2012 Content Motivation An informal introduction to abstract interpretation A touch of theor of abstract interpretation A short overview of a few applications and ongoing work on software verification For a rather complete basic introduction to abstract interpretation and applications to cber-phsical sstems, see: Julien Bertrane, Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, & Xavier Rival. Static Analsis and Verification of Aerospace Software b Abstract Interpretation. In AIAA Infotech@@Aerospace 2010, Atlanta, Georgia. American Institute of Aeronautics and Astronautics, April AIAA. 1 3 Abstract Abstract interpretation is a theor of abstraction and constructive approimation of the mathematical structures used in the formal description of programming languages and the inference or verification of undecidable program properties. Developed in the late seventies with Radhia Cousot, it has since then been considerabl applied to man aspects of programming, from snta, to semantics, and proof methods where abstractions are sound and complete but incomputable to full automatic, sound but incomplete approimate abstractions to solve undecidable problems such as static analsis of infinite state software sstems, contract inference, tpe inference, termination inference, model-checking, abstraction refinement, program transformation (including watermarking), combination of decision procedures, securit, malware detection, etc. This last decade, abstract interpretation has been ver successful in program verification for mission- and safet-critical sstems. An eample is Astrée ( which is a static analzer to verif the absence of runtime errors in structured, ver large C programs with comple memor usages, and involving comple boolean as well as floating-point computations (which are handled precisel and safel b taking all possible rounding errors into account), but without recursion or dnamic memor allocation. Astrée targets embedded applications as found in earth transportation, nuclear energ, medical instrumentation, aeronautics and space flight, in particular snchronous control/command such as electric flight control or more recentl asnchronous sstems as found in the automotive industr. Motivation Astrée is industrialized b AbsInt ( 2 4

All computer scientists have eperienced bugs Ariane 5.

Abstract interpretation Started in the 70 s and widel applied since then Based on the idea that undecidabilit and compleit of automated program analsis can be fought b sound approimations or complete

Static Determination of Dnamic Properties of Programs. In B.

2 All computer scientists have eperienced bugs Ariane 5.01 failure Patriot failure Mars orbiter loss (overflow) (float rounding) (unit error) Checking the presence of bugs is great Proving their absence is even better! Abstract interpretation Started in the 70 s and widel applied since then Based on the idea that undecidabilit and compleit of automated program analsis can be fought b sound approimations or complete abstractions Wide-spectrum theor so applications range from static analsis to verification to biolog Does scale up! 5 7 Abstract interpretation Patrick Cousot & Radhia Cousot. Static Determination of Dnamic Properties of Programs. In B. Robinet, editor, Proceedings of the second international smposium on Programming, Paris, France, pages , April , Dunod, Paris. Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Patrick Cousot. Méthodes itératives de construction et d'approimation de points fies d'opérateurs monotones sur un treillis, analse sémantique des programmes. Thèse És Sciences Mathématiques, Université Joseph Fourier, Grenoble, France, 21 March 1978 Patrick Cousot. Semantic foundations of program analsis. In S.S. Muchnick & N.D. Jones, editors, Program Flow Analsis: Theor and Applications, Ch. 10, pages , Prentice- Hall, Inc., Englewood Cliffs, New Jerse, U.S.A., Fighting undecidabilit and compleit in program verification An automatic program verification method will definitel fail on infinitel man programs (Gödel) Solutions: Ask for human help (theorem-prover/proof assistant based deductive methods) Consider (small enough) finite sstems (modelchecking) Do sound approimations or complete abstractions (abstract interpretation) 8

3 II) Define the program properties of interest Formalize what ou are interested to know about program behaviors An informal introduction to abstract interpretation P. Cousot & R. Cousot. A gentle introduction to formal verification of computer sstems b abstract interpretation. In Logics and Languages for Reliabilit and Securit, J. Esparza, O. Grumberg, & M. Bro (Eds), NATO Science Series III: Computer and Sstems Sciences, IOS Press, 2010, Pages ) Define the programming language semantics Formalize the concrete eecution of programs (e.g. transition sstem) h (,) 2 I III) Define which specification must be checked Formalize what ou are interested to prove about program behaviors t=0 t=1 t=2 t= t Trajector in state space Space/time trajector I 10 12

IV) Choose the appropriate abstraction Abstract awa all information on program behaviors irrelevant to the proof Soundness of the abstract verification Never forget an

4 IV) Choose the appropriate abstraction Abstract awa all information on program behaviors irrelevant to the proof Soundness of the abstract verification Never forget an possible case so the abstract proof is correct in the concrete V) Mechanicall verif in the abstract The proof is full automatic Tr a few cases Unsound validation: testing 14 16

Unsound validation: bounded model-checking Simulate the beginning of all eecutions Incompleteness When abstract proofs ma fail while concrete proofs would succeed Forbidden zone Possible trajectories

5 Unsound validation: bounded model-checking Simulate the beginning of all eecutions Incompleteness When abstract proofs ma fail while concrete proofs would succeed Forbidden zone Possible trajectories Bounded model-checking B soundness an alarm must be raised for this overapproimation! Unsound validation: static analsis Man static analsis tools are unsound (e.g. Coverit, etc.) so inconclusive True error The abstract alarm ma correspond to a concrete error 18 20

6 False alarm The abstract alarm ma correspond to no concrete error (false negative) A Touch of Abstract Interpretation Theor What to do about false alarms? Automatic refinement: inefficient and ma not terminate (Gödel) Domain-specific abstraction: Adapt the abstraction to the programming paradigms tpicall used in given domain-specific applications e.g. snchronous control/command: no recursion, no dnamic memor allocation, maimum eecution time, etc. Fipoint Set P P Transformer 2 P Fipoint 2 P! P F 2 P! P 2 P 2 P is a fipoint of F () F() () = Poset hp 6i hp, 6i Least hp 6i fipoint 2 P 2 P is the least fipoint of F (written = lfp 6 F) () F() = ^8 2 P :(F() = ) ) ( 6 ) 22 24

7 Program properties as fipoints Program semantics and program properties can be formalized as least/greatest fipoints of increasing transformers on complete lattices (1) Complete lattice / cpo of properties (1) _ hp, 6, 0, 1, _, ^i hp _ ^ Properties of programjp 6 F J _ K S JPK = lfp 6 FJPK F Transformer of program F JP 2 FJPK 2 P! P, increasing (or continuous) Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Proof Jmethods K Proof methods 2 directl! follow from the fipoint definition S JPK 6 P, lfp 6 FJPK 6 P,9I : FJPK(I) 6 I ^ I 6 P (proof b ) Tarski s fipoint ^8theorem 2 P for increasing transformers on complete lattice or Pataria for cpos) lfp 6 F = V { F() 6 } Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Eample: F reachable states Transition sstem (set of states h, initial states I, transition relation i) h, I, i. I Right-image of a I set [ of states b transitions post[ ]X, {s 0 9s 2 X : (s, s 0 )} Reachable h Istates i from initial states I, post[? ]I = lfp X. I [ post[ ]X, { } (I) Patrick Cousot. Méthodes itératives de construction et d'approimation de points fies d'opérateurs monotones sur un treillis, analse sémantique des programmes. Thèse És Sciences Mathématiques, Université Joseph Fourier, Grenoble, France, 21 March 1978 Patrick Cousot. Semantic foundations of program analsis. In S.S. Muchnick & N.D. Jones, editors, Program Flow Analsis: Theor and Applications, Ch. 10, pages , Prentice- Hall, Inc., Englewood Cliffs, New Jerse, U.S.A., h I Eample: Turing/Flod Invariance Proof Bad states B Prove B that no bad state is reachable post[? ]I B 9 2 I Turing/Flod proof method I B 9I 2 }( ) :I I ^ post[ ]I I ^ I B Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979:

8 Abstraction Abstract the concrete properties J into abstract,9 properties K J ^ K J K ha, v,?, >, t, ha ui v? > t J u K If an concrete propert P 2 P has a best abstraction (P) 2 A, then the correspondence is given b a Galois haconnection v? > t ui i.e. hp, 6i! ha, vi hp i! ha vi 8P 2 P : 8Q 2 A : (P) v Q, P 6 (Q) 8 2 P 8 Abstract transformer An abstract transformer 2 A! A Sound iff Complete iff F 2 A! A 8P 2 P : F(P) v F (P) 8 2 P v 8P 2 P : F(P) = F (P) Eample (rule 6 of sign) Addition: sound, v incomplete Multiplication: sound, complete is Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Eample: elementwise! abstraction Morphism h 2 P 7! A, { 2 P 7! A (X), {h() 2 X}, { 2 } h P i h A h}(p), i! h}(a), i h : P! i { 1! 0 1} h h : Z! { 1, 0, 1} Abstraction Galois connection Eample: rule of signs h(z), z/ z { 1 { 1, 0} {0 { 1} } { { 1} {0} ), { 1, 0, 1} 1 0} { } {0 1} { 1, 1} { 1} { { 1} {0} {1} { {1 ; { { 1 0 {0, 1} { 1 1 {0} {1} ; Eample: rule of signs {-1, -2, -7} * {0, -2, -5} = {0, 2, 4, 14, 5, 10, 35} i { n n > 0 }!! {-1} * {-1,0} = {1,0}! Negative Negative Positive or zero or zero Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979:

9 Fipoint abstraction For an 8increasing 2 P and sound abstract transformer, we have a fipoint approimation (lfp 6 F) v lfp v F For an increasing, sound, v and complete abstract transformer, we have an eact fipoint abstraction (lfp 6 F) = lfp v F Widening Definition 2 A (widening O 2 A A! A ) ha, vi poset Over-approimation ha vi 8, 2 A : v O ^ v O 8 Termination 2 A v O ^ v O Given an sequence h n, n 2 Ni, the widened sequence h n, n 2 Ni 0, 0,..., n+1, n O n,... converges to a limit ` (such that 8m > ` : m = `) Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Iterative fipoint computation Fipoint of increasing transformers on cpos can be computed iterativel as limits of (transfinite) iterates F 0,? F +1 F, F(F ), + 1 successor ordinal F, F F < F, limit ordinal F Ultimatel stationar at rank Converges to F = lfp v F =! when F is continuous Finite iterates when F operates on a cpo satisfing the ascending chain condition Eample: (simple) widening for polhedra Iterates Widening Patrick Cousot & Radhia Cousot. Constructive versions of Tarski's fied point theorems. In Pacific Journal of Mathematics, Vol. 82, No. 1, 1979, pp Patrick Cousot, Nicolas Halbwachs: Automatic Discover of Linear Restraints Among Variables of a Program. POPL 1978:

10 Iterates with widening for transformer F 0,? The widening speeds up convergence (at the cost of imprecision) Can be improved b a narrowing. Iteration with widening F n+1, F n when F(F n ) v F n F n+1, F n OF(F n ) otherwise 37 F 2 A! A Theorem (Limit of iterates with widening) The iterates of F with widening O from? on a poset ha, v,?i converge to a limit F` such that F(F` ) v F` (and so lfp v F v F` when F is increasing). Patrick Cousot, Radhia Cousot: Abstract Interpretation: A Unified Lattice Model for Static Analsis of Programs b Construction or Approimation of Fipoints. POPL 1977: Reduced product The reduced product combines abstractions b performing 9 2 I their ^ conjunction ^ in B the abstract 1 hp, 6i 1! 2 hp, 6i 2! ha 1, v 1 i ha 2, v 2 i A 1 A 2, {h 1 ( 1 (P 1 )^ 2(P 2 )), 2 ( 1 (P 1 )^ 2(P 2 ))i P 1 2 A 1 ^ P 2 2 A 2 } 1 2 hp, 6i 1 2! ha 1 A 2, v 1 v 2 i Eample: (positive or zero) odd = <positive,odd> h Patrick Cousot, Radhia Cousot: Sstematic Design of Program Analsis Frameworks. POPL 1979: Patrick Cousot, Radhia Cousot, Laurent Mauborgne: The Reduced Product of Abstract Domains and the Combination of Decision Procedures. FOSSACS 2011: Intuition for iteration with widening F F F()6 Recent advances The same principles appl to termination Patrick Cousot, Radhia Cousot: An abstract interpretation framework for termination. POPL 2012: and to probabilistic programs Iteration l fp F l fp F Iteration with widening (using the derivative as in Newton-Raphson method) Patrick Cousot and Michaël Monerau. Probabilistic Abstract Interpretation. In H. Seidel (Ed), 22nd European Smposium on Programming (ESOP 2012), Tallinn, Estonia, 24 March 1 April Lecture Notes in Computer Science, vol. 7211, pp , Springer,

11 The semantics of C implementations is ver hard to define ASTRÉE Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, Xavier Rival: Wh does Astrée scale up? Formal Methods in Sstem Design 35(3): (2009) Patrick Cousot, Radhia Cousot, Jérôme Feret, Antoine Miné, Laurent Mauborgne, David Monniau, Xavier Rival: Varieties of Static Analzers: A Comparison with ASTREE. TASE 2007: 3-20 Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, David Monniau, Xavier Rival: Combination of Abstractions in the ASTRÉE Static Analzer. ASIAN 2006: Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, David Monniau, Xavier Rival: The ASTREÉ Analzer. ESOP 2005: Bruno Blanchet, Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, David Monniau, Xavier Rival: A static analzer for large safet-critical software. PLDI 2003: Bruno Blanchet, Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, David Monniau, Xavier Rival: Design and Implementation of a Special-Purpose Static Program Analzer for Safet-Critical Real-Time Embedded Software. The Essence of Computation 2002: What is the e ect of out-of-bounds arra indeing? %catunpredictable.c #include <stdio.h> int main () { int n, T[1]; n= ; printf("n = %i, T[n] = %i\n", n, T[n]); } Yields di erent results on di erent machines: n= ,t[n]= n= ,t[n]= n= ,t[n]= Bus error Macintosh PPC Macintosh Intel PC Intel 32 bits PC Intel 64 bits Target language and applications C programming language Without recursion, longjump, dnamic memor allocation, conflicting side effects, backward jumps, sstem calls (stubs) With all its horrors (union, pointer arithmetics, etc) Reasonabl etending the standard (e.g. size & endianess of integers, IEEE floats, etc) Originall for snchronous control/command e.g. generated from Scade 42 Implicit specification Absence of runtime errors: overflows, division b zero, buffer overflow, null & dangling pointers, alignment errors, Semantics of runtime errors: Terminating eecution: stop (e.g. floating-point eceptions 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. memor corruption) 44

12 Abstractions Collecting semantics: 1, 5 Intervals: 20 Simple congruences: 24 partial traces [a, b] a[b] Octagons: 25 Ellipses: 26 Eponentials: 27 ± ± a 2 + b 2 a d a bt (t) a bt domains (and more) are described in more details in Sects. III.H III.I. 45 t Eample of general purpose abstraction: decision trees Code Sample: /* boolean.c */ tpedef enum {F=0,T=1} BOOL; BOOL B; void main () { unsigned int X, Y; while (1) {... B=(X==0);... if (!B) { Y=1/X; }... } } The boolean relation abstract The boolean relation abstract domain is parameterized b the height domain is parameterized b the height of the of decision the decision tree (an tree analzer (an analzer option) and the option) abstract and domainthe at the leafs abstract domain at the leaves 47 Eample of general purpose abstraction: octagons Eample: Invariants of the form ± ± c, with O(N 2 ) memor and O(N 3 ) time cost. while (1) { R = A-Z; L = A; if (R>V) { L = Z+V; } } At, the interval domain gives L ma(ma A, (ma Z)+(ma V)). In fact, we have L A. To discover this, we must know at that R = A-Z and R > V. Here, R = A-Z cannot be discovered, but we get L-Z ma R which is sufficient. We use man octagons on small packs of variables instead of a large one using all variables to cut costs. Antoine Miné: The octagon abstract domain. Higher-Order and Smbolic Computation 19(1): (2006) 46 Eample of domain-specific abstraction: ellipses tpedef 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 [ , ] */ } void main () { X = 0.2 * X + 5; INIT = TRUE; while (1) { X = 0.9 * X + 35; /* simulated filter input */ filter (); INIT = FALSE; } } 48

13 Eample of domain-specific Arithmetic-geometric abstraction: progressions eponentials (E % cat count.c tpedef enum {FALSE = 0, TRUE = 1} BOOLEAN; volatile BOOLEAN I; int R; BOOLEAN T; void main() { R = 0; while (TRUE) { ASTREE_log_vars((R)); if (I) { R = R + 1; } else { R = 0; } T = (R >= 100); ASTREE_wait_for_clock(()); }} % cat count.config ASTREE_volatile_input((I [0,1])); ASTREE_ma_clock(( )); % astree eec-fn main config-sem count.config count.c grep R R <= 0. + clock *1. <= potential overflow! t An erroneous common belief on static analzers A common believe on static analzers The properties that can be proved b static analzers are often simple [2] Like in mathematics: Ma be simple to state (no overflow) But harder to discover ((P S[0], 2 S[1] [`1325:4522; in [ , 1325:4522]) ] ) And di cult to prove (since it requires finding a non trivial non-linear invariant for second order filters with comple roots [Fer04], which can hardl be found b ehaustive enumeration) Reference [2] Vija D Silva, Daniel Kroening, and Georg Weissenbacher. A Surve of Automated Techniques for Formal Software Verification. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Sstems, Vol. 27, No. 7, Jul [Fer04] Jérôme Feret: Static Analsis of Digital Filters. ESOP 2004: J I Eample of domain-specific abstraction: eponentials % cat retro.c tpedef enum {FALSE=0, TRUE=1} BOOL; BOOL FIRST; volatile BOOL SWITCH; volatile float E; float P, X, A, B; void dev( ) { X=E; if (FIRST) { P = X; } else { P = (P - ((((2.0 * P) - A) - B) * e-03)); }; B = A; if (SWITCH) {A = P;} else {A = X;} } void main() { FIRST = TRUE; while (TRUE) { dev( ); FIRST = FALSE; ASTREE_wait_for_clock(()); }} % cat retro.config ASTREE_volatile_input((E [-15.0, 15.0])); ASTREE_volatile_input((SWITCH [0,1])); ASTREE_ma_clock(( )); P <= ( e-39 / e-07) * ( e-07)ˆclock e-39 / e-07 <= Industrial applications Daniel Kästner, Christian Ferdinand, Stephan Wilhelm, Stefana Nevona, Olha Honcharova, Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné, Xavier Rival, and Élodie-Jane Sims. Astrée: Nachweis der Abwesenheit von Laufzeitfehlern. In Workshop ``Entwicklung zuverlässiger Software-Ssteme'', Regensburg, German, June 18th, Olivier Bouissou, Éric Conquet, Patrick Cousot, Radhia Cousot, Jérôme Feret, Khalil Ghorbal, Éric Goubault, David Lesens, Laurent Mauborgne, Antoine Miné, Slvie Putot, Xavier Rival, & Michel Turin. Space Software Validation using Abstract Interpretation. In Proc. of the Int. Space Sstem Engineering Conf., Data Sstems in Aerospace (DASIA 2009). Istambul, Turke, Ma 2009, 7 pages. ESA. Jean Souris, David Delmas: Eperimental Assessment of Astrée on Safet-Critical Avionics Software. SAFECOMP 2007: Jérôme Feret: The Arithmetic-Geometric Progression Abstract Domain. VMCAI 2005: t David Delmas, Jean Souris: Astrée: From Research to Industr. SAS 2007: Jean Souris: Industrial eperience of abstract interpretation-based static analzers. IFIP Congress Topical Sessions 2004: Stephan Thesing, Jean Souris, Reinhold Heckmann, Famantanantsoa Randimbivololona, Marc Langenbach, Reinhard Wilhelm, Christian Ferdinand: An Abstract Interpretation-Based Timing Validation of Hard Real-Time Avionics Software. DSN 2003:

Eamples of applications Verification of the absence

sstems ATV docking sstem (*) On-going work Flight

all! 53 55 Industrialization 8 ears of research

fr Industrialization b AbsInt (since Jan. 2010): www.

com/astree/ ASTRÉEA: Verification of embedded

14 Eamples of applications Verification of the absence of runtime-errors in (*) Fl-b-wire flight control sstems ATV docking sstem (*) On-going work Flight warning sstem (on-going work) (*) No false alarm a all! Industrialization 8 ears of research (CNRS/ENS/INRIA): Industrialization b AbsInt (since Jan. 2010): ASTRÉEA: Verification of embedded real-time parallel C programs Antoine Miné: Static Analsis of Run-Time Errors in Embedded Critical Parallel C Programs. ESOP 2011:

15 Parallel programs Bounded number of processes with shared memor, events, semaphores, message queues, blackboards, Processes created at initialization onl Real time operating sstem (ARINC 653) with fied priorities (highest priorit runs first) Scheduled on a single processor Verified properties Absence of runtime errors Absence of unprotected data races 57 Abstractions Based on Astrée for the sequential processes Takes scheduling into account OS entr 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 memor and inter-process communications 59 Semantics No memor consistenc model for C Optimizing compilers consider sequential processes out of their eecution contet init: flag1 = flag2 = 0 process 1: process 2: flag1 = 1; flag2 = 1; if (!flag2) if (!flag1) { { /* critical section */ /* critical section */ We assume: sequential consistenc in absence of data race for data races, values are limited b possible interleavings between snchronization points 58 write to flag1/2 and read of flag2/1 are independent so can be reordered error! Eample of application: FWS Degraded mode (5 processes, LOCS) 1h40 on 64-bit 2.66 GHz Intel server A few dozens of alarms Full mode (15 processes, LOCS) 24 h a few hundreds of alarms!!! work going on!!! (e.g. analsis of comple data structures, logs, etc) 60

16 Conclusion Cost-effective verification Wh not tr abstract interpretation? Domain-specific static analsis scales and can deliver no or few false alarms on large industrial code! Conceptual bugs are discovered through their consequences on runtime errors Ver cost effective Compliant with DO178C formal methods! Cost-effective verification The rumor has it that: Manuel validation (testing/debugging/bug finding) is costl, unsafe, not a verification! Formal proofs b theorem provers are etremel laborious hence costl to create and maintain for program/specifications changing over time (15/20 ears for planes) Model-checkers are unsound or do not scale up for comple software (which is unbounded) The End, Thank You 62 64

Static Analysis and Verification of Aerospace Software

Static Analysis and Verification of Aerospace Software by Abstract Interpretation joint work with: Patrick Cousot Julien Bertrane and Radhia Cousot École normale supérieure, Paris Patrick Cousot, Courant