Abstract Interpretation and Static Analysis. Introductory Motivations on Software Reliability. The Software Reliability Problem

Transcription

1 Abstract Interpretation and Static Analsis Patrick COUSOT École Normale Supérieure, 45 rue d Ulm Paris cede 05, France mailto:cousot@ens.fr cousot IFIP WG 10.4, 40th Meeting on Formal Methods, Stenungsund, Sweden, Jul 4 8, 2001 The Software Reliabilit Problem The evolution of hardware b a factor of 10 6 over the past 25 ears has lead to the eplosion of the program sizes; The scope of application of ver large software is likel to widen rapidl in the net decade; These big programs will have to be modified and maintained during their lifetime (often over 20 ears); The size and efficienc of the programming and maintenance teams in charge of their design and follow-up cannot grow up in similar proportions; IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot The Software Reliabilit Problem (Cont d) Introductor Motivations on Software Reliabilit At a not so uncommon (and often optimistic) rate of one bug per thousand lines such huge programs might rapidl become hardl manageable in particular for safet critical sstems; Therefore in the net 10 ears, the software reliabilit problem is likel to become a major concern and challenge to modern highl computer-dependent societies. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

2 What Can We Do About It? The Verification/Validation Problem Use our intelligence (thinking/intellectual tools: abstract interpretation); Use our computer (mechanical tools : static program analsis/checking/testing,the earl idea of using computers to reason about computer). Computer program Programming language semantics Program semantics = model of actual program eecutions in all environments Satisfaction Formal specification Specification language semantics Specification semantics = model of required program eecutions in allowed environments IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: Model Checking Software Verification and Validation Computer program Programming language semantics Program semantics = model of actual program eecutions in all environments??? Program model Model checking Checking Satisfaction Temporal specification? Formal specification Specification language semantics Specification semantics = model of required program eecutions in allowed environments IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

3 Other Eamples of Software Verification/Validation Techniques Software testing; Simulation and prototping; Technical reviews; Requirements tracing; Formal correctness proofs; Etc. Fundamental Theoretical Limitations Undecidabilit: full automation of software verification/validation is impossible; Eamples of undecidable questions: Is m program bug-free? (i.e. correct with respect to a given specification); Can a program variable take two different values during eecution? IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Testing: Practical Limitations Testing all data on all paths is impossible; Formal methods: No formal specification perfectl reflects informal human epectations; Proofs grow eponentiall in the size of programs/specifications which is incompatible with friendl user interaction and full automation; etc. Undecidabilit and Approimation Since program verification is undecidable, computer aided program verification methods are all partial/incomplete; The all involve some form of approimation: restricted specifications or programs (e.g. finiteness), decidable questions or semi-algorithms, practical time/memor compleit limitations, require user interaction; Most of these approimations are formalized b Abstract Interpretation. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

4 Eamples of approimations Testing: coverage is partial (so errors are frequentl found until the end of the software lifetime); Proofs: specifications are often partial, debugging proofs is often harder that testing programs (so onl parts of ver large software can be formall proved correct); Model checking: the model must fit machine limitations (so some facets of program eecution must be left out) and be redesigned after program modifications; Tping: tpes are weak program properties (so tpe verification cannot be generalized to comple specifications). Semantics IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Content Introductor motivations on software reliabilit Software verification and validation...5 Semantics Abstract Interpretation Abstraction Conservative approimation & information loss Static program analsis Static program checking Static program testing Conclusion Semantics: intuition The semantics of a language defines the semantics of an program written in this language; The semantics of a program provides a formal mathematical model of all possible behaviors of a computer sstem eecuting this program (interacting with an possible environment); An semantics of a program can be defined as the solution of a fipoint equation; All semantics of a program can be organized in a hierarch b abstraction. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

5 Eample: trace semantics Initial states Intermediate states a b c d e g i k Final states of the finite traces Infinite traces l discrete time h f j Least Fipoints: intuition Behaviors = { is a final state} {... is an elementar step &... Behaviors + } { is an elementar step & Behaviors } In general, the equation has multiple solutions. Choose the least one for the partial ordering: «morefinitetraces&lessinfinitetraces». IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eamples of computation traces Finite (C1+1=): Erroneous (C ): Abstract Interpretation Infinite (C ): IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

6 Abstract Interpretation [1] Formalizes the idea of approimation of sets and set operations as considered in set (or categor) theor; A theor of approimation of the semantics of programming languages; Main application: formal method for inferring general runtime properties of programs. Usefulness of Abstract Interpretation Thinking tools: the idea of abstraction is central to reasoning (in particular on computer sstems); Mechanical tools: the idea of effective approimation leads to automatic semantics-based program manipulation tools. Reference [1] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analsis of programs b construction or approimation of fipoints. In Conf. Record of the 4th Annual ACM SIGPLAN-SIGACT Smp. on Principles of Programming Languages POPL 77,LosAngeles,CA,1977.ACMPress,pp IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot The Theor of Abstract Interpretation Abstract interpretation is a theor of conservative approimation of the semantics of computer sstems. Approimation: observation of the behavior of a computer sstem at some level of abstraction, ignoring irrelevant details; Conservative: the approimation cannot lead to an erroneous conclusion. Abstraction IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

7 Abstraction: intuition Approimations of an [in]finite set of points; Abstract interpretation formalizes the intuitive idea that a semantics is more or less precise according to the considered observation level of the program eecutions; Abstract interpretation theor formalizes this notion of approimation/abstraction in a mathematical setting which is independent of particular applications. {..., 19, 78,..., 20, 01,...} IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Approimations of an [in]finite set of points: From Below Intuition behind abstraction {..., 19, 78,...,...} IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

8 Approimations of an [in]finite set of points: From Above Effective computable approimations of an [in]finite set of points; Signs [2]?????????? {..., 19, 78,..., 20, 01,?,?,...} Reference { 0 0 [2] P. Cousot and R. Cousot. Sstematic design of program analsis frameworks. In 6 th POPL,pages , San Antonio, T, ACM Press. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Effective computable approimations of an [in]finite set of points; Intervals [3] Intuition Behind Effective Computable Abstraction { [19, 78] [20, 01] Reference [3] P. Cousot and R. Cousot. Static determination of dnamic properties of programs. In 2 nd Int. Smp. on Programming,pages Dunod,1976. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

9 Effective computable approimations of an [in]finite set of points; Octagons [4] Effective computable approimations of an [in]finite set of points; Simple congruences [6] { =19mod78 =20mod99 Reference [4] A. Miné. A New Numerical Abstract Domain Based on Difference-Bound Matrices. Proc. 2 nd Smp. on Programs as Data Objects PADO 2001,0.Danv&A.Filinski(Eds.),LNCS2053,Springer,2001,pp Reference [6] P. Granger. Static analsis of arithmetical congruences. Int. J. Comput. Math., 30: , IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Effective computable approimations of an [in]finite set of points; Polhedra [5] Effective computable approimations of an [in]finite set of points; Linear congruences [7] { { 1 +9 =7mod8 2 1 =9mod9 Reference [5] P. Cousot and N. Halbwachs. Automatic discover of linear restraints among variables of a program. In 5 th POPL,pages84 97,Tucson,AZ,1978.ACMPress. Reference [7] P. Granger. Static analsis of linear congruence equalities among variables of a program. CAAP 91,LNCS 493, pp Springer, IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

10 Effective computable approimations of an [in]finite set of points; Trapezoidal linear congruences [8] { 1 +9 [0, 78] mod [0, 99] mod 11 Intuition Behind Sound/Conservative Approimation Reference [8] F. Masdupu. Arra operations abstraction using semantic analsis of trapezoid congruences. In ACM Int. Conf. on Supercomputing, ICS 92,pages ,1992. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Conservative Approimation Conservative Approimation and Information Loss Is the operation 1/(+1-) well defined at run-time? Concrete semantics: es 1 IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

11 Conservative Approimation Is the operation 1/(+1-) well defined at run-time? Testing : You never know! Conservative Approimation Is the operation 1/(+1-) well defined at run-time? Abstract semantics es? 1 1 IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Conservative Approimation Is the operation 1/(+1-) well defined at run-time? Abstract semantics Idon tknow Intuition Behind Information Loss 1 IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

12 Information Loss Abstraction α Allanswers given b the abstract semantics are alwas correct with respect to the concrete semantics; Because of the information loss, not all questions can be definitel answered with the abstract semantics; The more concrete semantics can answer more questions; The more abstract semantics are more simple α {:[1,99], :[2,77]} 1 99 IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Basic Elements of Abstract Interpretation Theor 77 Concretization γ {:[2,77], :[2,99]} IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

13 The Abstraction α is Monotone The γ α Composition α α {:[33,89], :[48,61]} {:[1,99], :[2,99]} 77 2 α {:[1,99], :[2,77]} Y α() α(y ) 1 99 γ α() IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot The Concretization γ is Monotone The α γ Composition {:[33,89], :[48,61]} {:[1,99], :[2,99]} 77 2 α {:[1,99], :[2,77]} = {:[1,99], :[2,77]} Y γ() γ(y ) 1 99 α γ(y )=Y IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

14 Galois Connection 1 γ P, Q, α iff α is monotone γ is monotone γ α() α γ(y ) Y 1 formalizations using closure operators, ideals, etc. are equivalent. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eact/Approimate Fipoint Abstraction Abstract domain F F F F F F F F F F F F Concrete domain Approimation relation F = α F γ lfp F γ(lfp F ) IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Abstract domain F F α Concrete domain γ P, Q, α P mon Function Abstraction F = α F γ λf. γ F α P, λf. α F γ Q mon Q, Eact/Approimate Fipoint Abstraction Abstract domain F F F F F α α α α α Approimation relation F F F F F F F F F F F Concrete domain F = α F γ lfp F γ(lfp F ) IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

15 Eact/Approimate Fipoint Abstraction Eact Abstraction: α(lfp F ) = lfp F Approimate Abstraction: α(lfp F ) lfp F AFewReferencesonFoundations [9] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analsis of programs b construction or approimation of fipoints. In 4 th POPL, pages , Los Angeles, CA, ACM Press. [10] P. Cousot and R. Cousot. Sstematic design of program analsis frameworks. In 6 th POPL, pages , San Antonio, T, ACM Press. [11] P. Cousot and R. Cousot. Abstract interpretation frameworks. J. Logic and Comp., 2(4): , IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot α Eact/Approimate Fipoint Abstraction Abstract domain F F F F F α α α α α α Approimation relation Applications of Abstract Interpretation F F F F F F F Concrete domain α F = F α α(lfp F ) = lfp F IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

16 Trace Semantics (Once Again) (1) Eact Abstractions Initial states Intermediate states a b c d e g i k Final states of the finite traces Infinite traces l discrete time h f j IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample 1 of Semantics Abstraction Abstractions of Semantics [12] Reference [12] P. Cousot. Constructive design of a hierarch of semantics of a transition sstem b abstract interpretation. To appear in Theoretical Computer Science,(2001). Initial states Intermediate states a b c d e g i k l discrete time h Trace semantics Final states of finite traces f j Infinite traces Initial states Final states a d α e g i k l f h j α a d e g i f h j Denotational semantics Natural semantics IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

17 Eample 2 of Semantics Abstraction Initial states Transitions a a b b c d e e f g g h i k l i j k l (Small-Step) Operational Semantics Final states d f h j Hoare logics Weakest precondition semantics Denotational semantics Relational semantics Trace semantics angelic natural demoniac determinist infinite Lattice of Semantics τ ph τ th τ gh τ wlp τ wp τ gwp τ τ D τ τ τ S τ τ τ EM τ τ + τ? τ τ τ ω! τ τ ω τ + τ τ abstraction equivalence restriction IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample 3 of Semantics Abstraction Initial states Reachable states a a b c d e e f g g h i i k k l l j Final states d f h j (2) Effective Approimate Abstractions Partial Correctness / Invariance Semantics Reference [13] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analsis of programs b construction or approimation of fipoints. POPL 77,ACMPress,pp IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

18 Effective Abstractions of Semantics If the approimation is rough enough, the abstraction of a semantics can lead to a version which is less precise but is effectivel computable b a computer; The computation of this abstract semantics amounts to the effective iterative resolution of fipoint equations; B effective computation of the abstract semantics,thecomputer is able to analze the behavior of programs and of software before and without eecuting them. Objective of Static Program Analsis Program analsis is the automatic static determination of dnamic run-time properties of programs; The principle is to compute an approimate semantics of the program to check a given specification; Abstract interpretation is used to derive, from a standard semantics, the approimate and computable abstract semantics; This derivation is itself not (full) mechanizable. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Basic Idea of Static Program Analsis Static Program Analsis Basic idea: use effective computable approimations of the program semantics; Advantage: full automatic, no need for error-prone user designed model or costl user interaction; Drawback: can onl handle properties captured b the approimation; Remed: ask the user to choose among a variet of possible approimations (abstract algebras) at various cost/precision ratio. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

19 Principle of a Static Program Analzer Program Generator Solver (Approimate) solution Diagnoser Diagnosis Specification Sstem of fipoint equations/constraints Program analzer Design of a Static Program Analzer b Abstract Interpretation Computer program Programming language semantics Program semantics = model of actual program eecutions in all environments Abstract program semantics Abstract Static Program Analsis ABSTRACTION Information about actual program eecutions in all environments Abstract Interpretation IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Generic Static Program Analzer Program Abstract algebra Generator Sstem of fipoint equations/constraints Solver (Approimate) solution Interfacor Information on program eecutions Program analzer Effective Smbolic Abstractions IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

20 Effective Abstractions of Smbolic Structures Most structures manipulated b programs are smbolic structures such as control structures (call graphs), data structures (search trees), communication structures (distributed & mobile programs), etc; It is ver difficult to find compact and epressive abstractions of such sets of objects (languages, automata, trees, graphs, etc.). Eample of Abstractions of Infinite Sets of Infinite Trees Binar Decision Graphs: [15] Reference [15] L. Mauborgne. Binar decision graphs. SAS 99,LNCS1694,pp Springer,1999. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample of Abstractions of Infinite Sets of Finite Trees Program : Eample of Abstractions of Infinite Sets of Infinite Trees (Cont d) Tree Schemata: [16, 17] Y := cop() Alias analsis: Eample of impossible configuration: Y := cop() {( (tl ) i hd, Y (tl ) j hd) i = j} Reference [14] A. Deutsch. Interprocedural ma-alias analsis for pointers: beond k-limiting. In PLDI 94,pp ,1994. Reference [16] L. Mauborgne. Improving the representation of infinite trees to deal with sets of trees. ESOP 2000,LNCS 1782, pp Springer, [17] L. Mauborgne. Tree schemata and fair termination. SAS 2000,LNCS1824,pp Springer,2000. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

21 AClassicalEample: Interval Analsis Eample: interval analsis (1975) 2 Equations (abstract interpretation of the semantics): 1 = [1, 1] 2 = ( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 = ( 1 3 ) [10000, + ] 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] 4 =( 1 3 ) [10000, + ] IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Program to be analzed: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] 4 =( 1 3 ) [10000, + ] IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Constraints (abstract interpretation of the semantics): 1 [1, 1] 2 ( 1 3 ) [, 9999] 3 2 [1, 1] while < do 4 ( 1 3 ) [10000, + ] 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] 4 =( 1 3 ) [10000, + ] IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

22 Eample: interval analsis (1975) 2 Increasing chaotic iteration, initialization: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 1 = 2 = 3 = 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 1] 3 = 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 = 3 = 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 1] 3 =[2, 2] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

23 Eample: interval analsis (1975) 2 Increasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 2] 3 =[2, 2] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence?? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 3] 3 =[2, 3] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 2] 3 =[2, 3] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence??? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 3] 3 =[2, 4] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

24 Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence???? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 4] 3 =[2, 4] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence?????? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 5] 3 =[2, 5] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence????? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 4] 3 =[2, 5] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Increasing chaotic iteration: convergence??????? 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 5] 3 =[2, 6] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

25 Eample: interval analsis (1975) 2 Convergence speed-up b etrapolation: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, + ] widening 3 =[2, 6] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Decreasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, + ] 3 =[2, + ] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot [,0] [,-1] [,-2] Widening [,+ ] [0,+ ] [-3,0] [-2,1] [-1,2] [0,3] [1,+ ] [-3,-1] [-2,0] [-1,1] [0,2] [1,3] [2,+ ] [-2,-1] [-1,0] [0,1] [1,2] [-2,-2] [-1,-1] [0,0] [1,1] [2,2] Ø Eample: interval analsis (1975) 2 Decreasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 9999] 3 =[2, + ] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

26 Eample: interval analsis (1975) 2 Decreasing chaotic iteration: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 9999] 3 =[2, 10000] 4 = IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Result of the interval analsis: 2 =( 1 3 ) [, 9999] { =1} 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] { [1, 9999]} { [2, 10000]} 2 =[1, 9999] { =10000} 3 =[2, 10000] 4 =[10000, 10000] IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Final solution: 2 =( 1 3 ) [, 9999] 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] 2 =[1, 9999] 3 =[2, 10000] 4 =[10000, 10000] IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot AMoreIntriguingEample program Variant_of_McCarth_91_function; var, Y : integer; function F( : integer) :integer; begin if > 100 then F := 10 else F := F(F(F(F(F(F(F(F(F(F( + 90)))))))))); end; begin readln(); Y := F(); { Y [91, + ] } end. Reference [18] F. Bourdoncle. Efficient chaotic iteration strategies with widenings. In Proc. FMPA, LNCS 735, pages Springer, IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

27 Probabilistic Program Analsis 4 double, i; assume (-1.0 < < 0.0); i = 0.0; while (i < 3.0) { += uniform(); i += 1.0; }; assert ( < 1.0); With 99% safet: the probabilit of the outcome ( <1) is less than 0.859, assuming: worst-case nondeterministic choices of the precondition ( 1.0 <<0.0), random choices uniform() chosen in [0, 1] with the Lebesgue uniform distribution. Static Program Checking 2 D. Monniau, SAS 00, POPL 01 IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Communication Topolog of Mobile Processes 3 Request A S B A A A Q2... Request Q2 Data echange Q1 S B P1 S P1 P2 S P1 P2... B Data echange Q1 Data echange B Q J. Feret, SAS 00, ENTCS Vol. 39 IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Objective of Static Program Checking Program Specification Program checker Diagnosis IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

28 Principle of a Static Program Checker Program Generator Solver (Approimate) solution Diagnoser Diagnosis Specification Sstem of fipoint equations/constraints Program checker IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample: interval analsis (1975) 2 Eploitation of the result of the interval analsis: 2 =( 1 3 ) [, 9999] { =1} 3 = 2 [1, 1] while < do 4 =( 1 3 ) [10000, + ] { [1, 9999]} { [2, 10000]} no overflow 2 =[1, 9999] { =10000} 3 =[2, 10000] 4 =[10000, 10000] IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Design of a Static Program Checker b Abstract Interpretation Computer program Programming language semantics Program semantics = model of actual program eecutions in all environments Abstract Static Program Checking Checking Abstract program semantics Satisfaction Abstract semantics specification ABSTRACTION Formal specification Specification language semantics Specification semantics = model of required program eecutions in allowed environments IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Other Eamples of Faultless Eecution Checks Absence of runtime errors (arra bounds violations, arithmetic overflow, erroneous data accesses, etc.), Absence of memor leaks (dangling pointers, uninitialized variables, etc.), Handling of all possible runtime eceptions (failures of I/O and sstem calls, etc.), No resource contention and race conditions in concurrent programs (deadlocks & livelocks), Termination / non termination conditions, Etc. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

29 Combining Empirical and Formal Methods Static Program Testing The user provides local formal abstractions of the program specifications using predefined abstractions 4 ; The program is evaluated b abstract interpretation of the formal semantics of the program 5 ; If the local abstract specification cannot be proved correct, a more precise abstract domain must be considered 6 ; The process is repeated until appropriate coverage of the specification. 4 thus replacing infinitel man test data. 5 thus replacing program eecution on the test data. 6 similarl to different test data. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Abstract checking versus Abstract Testing Abstract Program Testing Abstract checking: specification derived automaticall from the program (e.g. using the language specification for run-time errors); Abstract testing: specification provided b the programmer. Debugging Run the program On test data Checking if all right Providing more tests Until coverage Abstract testing Compute the abstract semantics Choosing a predefined abstraction Checking user-provided abstract assertions With more refined abstractions Until enough assertions proved or no predefined abstraction can do. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

30 Eample of predefined abstraction f n ATinEample 0: { n:[,+ ]?; f:[,+ ]? } static analzer inference read(n); diagnosis: definite error { n:[0,+ ]; f:[,+ ]? } f:=1; { n:[0,+ ]; f:[1,+ ] } while (n <> 0) do no error { n:[1,+ ]; f:[1,+ ] } f:=(f* n); { n:[1,+ ]; f:[1,+ ] } n:=(n-1) 5: { n:[0,+ ]; f:[1,+ ] } 6: { n:[0,0]; f:[1,+ ] } user program sometime true;; user specification potential error IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Eample of predefined abstraction: intervals f n ATinEample(Cont d) 0: { n: ; f: } static analzer inference initial (n < 0); user specification { n:[,-1]; f:[,+ ]? } f:= 1; user program { n:[,-1]; f:[,+ ] } while (n <> 0) do diagnosis: no error { n:[,-1]; f:[,+ ] } f:=(f* n); potential error { n:[,-1]; f:[,+ ] } n:=(n- 1) potential error 5: { n:[,-2]; f:[,+ ] } od 6: { n: ; f: } unreachable code IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

31 AMoreIntriguingEample program Variant_of_McCarth_91_function; var, Y : integer; function F( : integer) :integer; begin if > 100 then F := 10 else F := F(F(F(F(F(F(F(F(F(F( + end; begin readln(); {% > 100 %} Y := F(); {% sometime true %} end )))))))))); Eample of ccle: F(100) F(190) F(180) F(170) F(160) F(150) F(140) F(130) F(120) F(110) F(100) Eamples of Functional Specifications for Abstract Testing Worst-case eecution/response time in real-time sstems running on a computer with pipelines and caches; Periodicit of some action over time/with respect to some clock; Possible reactions to real-time event/message sequences; Compatibilit with state/transition/sequence diagrams/charts; Absence of deadlock/livelock with different scheduling policies; IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Comparing with program debugging Similarit: user interaction, on the source code; Essential differences: user provided test data are replaced b abstract specifications; evaluation of an abstract semantics instead of program eecution/simulation; one can prove the absence of (some categories of) bugs, not onl their presence; abstract evaluation can be forward and/or backward (reverse eecution). Conclusion IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

32 Concluding Remarks Program debugging is still the prominent industrial program verification method. Complementar program verification methods are needed; Full mechanized program verification b formal methods is either impossible (e.g. tping/program analsis) or etremel costl since it ultimatel requires user interaction (e.g. abstract model checking/deductive methods for large programs); For program verification, semantic abstraction is mandator but difficult whence hardl automatizable,evenwiththehelp of programmers; IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Does appl to an computer-related language with a wellspecified semantics describing computations (e.g. specification languages, data base languages, sequential, concurrent, distributed, mobile, logical, functional, object oriented, programming languages, etc.); Does appl to an propert and combinations of properties (such as safet, liveness, timing, event preconditions, ); Can follow up program modifications over time; Ver cost effective,especiallinearlphasesofprogramdevelopment. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Concluding Suggestions Abstract interpretation introduces the idea of safe approimation within formal methods; So ou might think to use it for partial verification of the source specification/program code: Abstract checking (full automatic and ehaustive diagnosis on run-time safet properties), Abstract testing (interactive/planned diagnosis on functional, behavioural and resources-usage requirements), using tools providing predefined abstractions. / Industrialization of Static Analsis/Checking b Abstract Interpretation Connected Components Corporation (U.S.A.), L. Harrison, ; AbsInt Angewandte Informatik GmbH (German), R. Wilhelm & C. Ferdinand, 1998; Polspace Technologies (France), A. Deutsch & D. Pilaud, Internal use for compiler design. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot

33 DA D LUS European project on the verification of critical real-time avionic software (oct sep. 2002): A E P. Cousot (ENS, France), scientific coordinator; R. Cousot (École poltechnique, France); A. Deutsch & D. Pilaud (Polspace Technologies, France); C. Ferdinand (AbsInt,German); É. Goubault (CEA, France); N. Jones (DIKU, Denmark); F. Randimbivololona & J. Souris (EADS Airbus, France), coord.; M. Sagiv (Univ. Tel Aviv, Israel); H. Seidel (Univ. Trier, German); R. Wilhelm (Univ. Sarrebrücken, German); IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot Areference(withalargebibliograph) P. Cousot. Abstract interpretation based formal methods and future challenges. In R. Wilhelm (editor), «Informatics 10YearsBack, 10 Years Ahead». Volume 2000 of Lecture Notes in Computer Science, pages Springer-Verlag, An etended electroning version is also available on Springer-Verlag web site together with a ver long electroning version with a complete bibliograph. IFIP WG 10.4, 40th Meeting,Jul4 8, P.Cousot