Abstract interpretation The Verification Grand Challenge - Abstract interpretation is a mathematical theory of - - and Abstract Interpretation sound approximation of properties of formal sys- tems (including program specifications, semantics, Patrick Cousot . . . ) - Abstraction is central to the comprehension of com- - - École normale supérieure, Paris, France plex systems (such as software) cousot ens fr www.di.ens.fr/~cousot - Discovering new, useful, reusable abstractions can - - be a full time job Verified Software: Theories, Tools, Experiments Zürich, ETH, Oct. 10 th –14 th , 2005 — 1 — — 3 — Applications of Abstract Interpretation (Cont’d) - Static Program Analysis [POPL ’77], [POPL ’78], [POPL ’79] - - including Dataflow Analysis [POPL ’79], [POPL ’00], Set- Abstract interpretation based Analysis [FPCA ’95], Predicate Abstraction [Manna’s festschrift ’03], . . . - Syntax Analysis [TCS 290(1) 2002] - - - Hierarchies of Semantics (including Proofs) [POPL ’92], - - [TCS 277(1–2) 2002] - Typing & Type Inference [POPL ’97] - - VSTTE, ETH — 2 — ľ P. Cousot Oct. 10 th –14 th , 2005 — 4 — ľ P. Cousot
Applications of Abstract Interpretation (Cont’d) The ASTRÉE static analyzer - Verify the absence of runtime errors in C programs: - - - (Abstract) Model Checking [POPL ’00] - - - out-of-bound array accesses 1 - - integer division by zero - - Program Transformation [POPL ’02] - - - IEEE 754-1985 floating point operations overflows and in- - valid operations (producing Inf or NaN 2 ) - Software Watermarking [POPL ’04] - - - integer arithmetics or cast wrap around, . . . - - No union , malloc , recursion, library, strings, . . . - - - Bisimulations [RT-ESOP ’04] - - . . . as usual in many (automatically generated) synchronous, time-triggered, real-time, safety critical, embedded software as All these techniques involve sound approximations that found in automotive, energy and aerospace applications can be formalized by abstract interpretation — 7 — Industrial applications — 5 — - Nov. 2003: absence of any RTE in the primary flight control - - software of the fly-by-wire system of a family of existing com- mercial planes (generated from a proprietary specification lan- guage), 132.000 lines - Mar. 2005: - - absence of any RTE in the primary flight con- A successful example: trol software of the fly-by-wire system of commercial plane un- der certification (generated from a proprietary specification lan- The ASTRÉE static analyzer guage/SCADE), 500.000 lines, No false alarm (a world première) - Oct. 2005: 1.000.000 lines - - Objectives: verification of binary code (+3 months), automatic analysis of the origin of errors (+6 months), asynchronous com- munication (+1 year), asynchronous processes (+2 years), . . . 1 It is completely wrong that “we don’t need a proof but a proper compiler”: discovering the error at runtime is too late, no compiler checks these verification conditions 2 Well-written programs check for Inf/NaN inputs which must be shown statically not to propagate VSTTE, ETH — 6 — ľ P. Cousot Oct. 10 th –14 th , 2005 — 8 — ľ P. Cousot
Abstractions Filter Example typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; Abstraction of sets of traces 3 with BOOLEAN INIT; float P, X; void filter () { - Intervals abstract domain (basic domain necessary to check - - static float E[2], S[2]; the absence of RTE) if (INIT) { S[0] = X; P = X; E[0] = X; } else { P = (((((0.5 * X) - (E[0] * 0.7)) + (E[1] * 0.4)) - Octagons abstract domain - - + (S[0] * 1.5)) - (S[1] * 0.7)); } - Digital filters abstract domain - - E[1] = E[0]; E[0] = X; S[1] = S[0]; S[0] = P; /* S[0], S[1] in [-1327.02698354, 1327.02698354] */ - Decision trees abstract domain - - } - Control/data partitioning to handle disjunctions - - void main () { X = 0.2 * X + 5; INIT = TRUE; while (1) { - . . . - - X = 0.9 * X + 35; /* simulated filter input */ filter (); INIT = FALSE; } Preprocessing to handle C macros. Abstract domains are param- } eterized to tailor cost/precision, they talk/communicate symbol- ically through mutual queries to implement the reduced product Reference see http://www.astree.ens.fr/ — 9 — Ellipsoid Abstract Domain for Filters — 11 — 2 d Order Digital Filter: Arithmetic-geometric progressions ¸X n ` 1 + ˛X n ` 2 + Y n a b - Computes X n = - - - Abstract domain: ( R + ) 5 I n - - 4 - - The concrete computation is bounded, which - - - Concretization (any function bounded by the arithmetic- - - + + z -1 + z -1 must be proved in the abstract. t Unit delay Unit delay Switch geometric progression): Switch - There is no stable linear invariant - - ‚ 2 ( R + ) 5 7` x(n) j i Switch B - The simplest stable surface is an ellipsoid - - ! } ( N 7! R ) ‚ ( M; a; b; a 0 ; b 0 ) = “ –x . ax + b ‹ ( –x . a 0 x + b 0 ) k ” f f j 8 k 2 N : j f ( k ) j » ( M ) g F(X) X X F(X) X U F(X) X U F(X) Reference see http://www.astree.ens.fr/ execution trace unstable interval stable ellipsoid 3 i.e. more refined that invariants 4 here in R VSTTE, ETH — 10 — ľ P. Cousot Oct. 10 th –14 th , 2005 — 12 — ľ P. Cousot
Arithmetic-Geometric Progressions (Example 1) % cat count.c typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; volatile BOOLEAN I; int R; BOOLEAN T; void main() { Directions for application of R = 0; while (TRUE) { abstract interpretation __ASTREE_log_vars((R)); potential overflow! if (I) { R = R + 1; } to the verification grand challenge else { R = 0; } T = (R >= 100); __ASTREE_wait_for_clock(()); }} % cat count.config __ASTREE_volatile_input((I [0,1])); __ASTREE_max_clock((3600000)); % astree –exec-fn main –config-sem count.config count.c|grep ’|R|’ |R| <= 0. + clock *1. <= 3600001. — 13 — Arithmetic-geometric progressions (Example 2) — 15 — void main() Program verification % cat retro.c { FIRST = TRUE; typedef enum {FALSE=0, TRUE=1} BOOL; Following E.W.D. Dijkstra: while (TRUE) { BOOL FIRST; dev( ); volatile BOOL SWITCH; - Program testing: presence of bugs - - FIRST = FALSE; volatile float E; __ASTREE_wait_for_clock(()); float P, X, A, B; - dynamic (e.g. program monitoring, . . . ) - }} % cat retro.config void dev( ) - static (error pattern recognition, prefix (model)- - __ASTREE_volatile_input((E [-15.0, 15.0])); { X=E; __ASTREE_volatile_input((SWITCH [0,1])); checking, . . . ) if (FIRST) { P = X; } __ASTREE_max_clock((3600000)); else |P| <= (15. + 5.87747175411e-39 { P = (P - ((((2.0 * P) - A) - B) - Program verification: absence of bugs - - * 4.491048e-03)); }; / 1.19209290217e-07) * (1 B = A; + 1.19209290217e-07)ˆclock - static - if (SWITCH) {A = P;} - 5.87747175411e-39 / else {A = X;} The Verification Grand Challenge is on verification (???). 1.19209290217e-07 <= } 23.0393526881 VSTTE, ETH — 14 — ľ P. Cousot Oct. 10 th –14 th , 2005 — 16 — ľ P. Cousot
Error tracing Specifications - Bugs or false alarms are found during the verification - - - Specifications translate external requirements in terms - - process of the program semantics - Abstract slicing can extract the part of the program - - - Specifications are erroneous - - (control + data) which may be responsible for the error - Specifications must be checked with respect to specifi- - - - Parametric abstraction can be used to provide counter- - - cations of the specification examples - Static analysis by abstract interpretation could be use- - - - This can be hard (e.g. accumulation of rounding errors - - ful for specification verification in floating point computations for hours) — 19 — — 17 — Program semantics On specification satisfaction - A program is checked with respect to its semantics (in- - - - Specification satisfaction can be verified in part - - ternal specification) - Such parts are abstractions of the specification (e.g. ab- - - - Precise formal semantics (usable for program verifica- - - sence of RTE) tion, including at the implementation level) are missing - This shows the need for abstractions of specifications - - for the most common languages (e.g. C 5 ) - Abstract interpretation - - - No semantics is universal - - - unifies specifications at various levels of abstraction - - Abstract interpretation unifies semantics according to - - - can be used to prove their consistency - their level of abstraction and can be used to prove their - can be used to specify by parts (through complex - consistency combinations of abstractions) 5 The semantics of C is –P : Program texts ´ –M : Machine ´ –S : System ´ –L : Linker ´ –C : Compiler ´ S [ C; L; S; M ] � P � . . . described informally VSTTE, ETH — 18 — ľ P. Cousot Oct. 10 th –14 th , 2005 — 20 — ľ P. Cousot
Recommend
More recommend
