DOCSLIB.ORG

Calculational Design of a Static Dependency Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Calculational Design of a Static Dependency Analysis 2019 Mooly Fest April 6th, 2019 — ETAPS, Prague, Czech Republic Calculational design of a static dependency analysis Patrick Cousot New York University, Courant Institute of Mathematics, Computer Science [email protected] cs.nyu.edu/~pcousot “Calculational design of, a static dependency analysis” – 1/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 . Motivation . “Calculational design of, a static dependency analysis” – 2/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Dependency Dependency is prevalent in computer science: • Non-interference (confidentiality, integrity) • Security, privacy • Slicing • Temporal dependencies in synchronous languages (Lustre, Signal, etc.) • etc. The existing definitions • are postulated a priori (par exemple Cheney, Ahmed, and Acar, 2011; D. E. Denning and P. J. Denning, 1977), • without semantics justifications (except Assaf, Naumann, Signoles, Totel, and Tronel, 2017 (“hyper-collecting semantics”), Urban and Müller, 2018 on program exit uniquely) We are interested in principles, in soundness proofs, not so much in a new more powerful dependency analysis. “Calculational design of, a static dependency analysis” – 3/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Structural fixpoint trace semantics . “Calculational design of, a static dependency analysis” – 4/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Program syntax • C statements limited to integers, assignments, statement lits, conditionals, iterations • Programs are labelled to designate program points • atJSK: entry program point of S starts; • afterJSK: normal exit program point of S; • inJSK: reachable program points of S (excluding afterJSK); • break-toJSK: breaking point when S contains a break ; to exit a loop (then escapeJSK = tt); . “Calculational design of, a static dependency analysis” – 5/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Execution traces • Program: ℓ1 x = 0 ; while ℓ2 (tt) { ℓ3 x = x+1 ;} ℓ4 x = 0 = 0 tt x = x + 1 = 1 tt • Infinite execution trace: ℓ1 −−−−−−−−−−−−−−−→ ℓ2 −−−−→ ℓ3 −−−−−−−−−−−−−−−−−−−−−→ ℓ2 −−−−→ ℓ3 x = x + 1 = 2 tt x = x + 1 = 푛 tt x = x + 1 = 푛 + 1 −−−−−−−−−−−−−−−−−−−−−→ ℓ2 …ℓ2 −−−−→ ℓ3 −−−−−−−−−−−−−−−−−−−−−→ ℓ2 −−−−→ ℓ3 −−−−−−−−−−−−−−−−−−−−−−−−−−→ ℓ2 … • Trace: finite or infinite sequence of program points separated by action (x = A = value, B, ¬B, et break ;) . “Calculational design of, a static dependency analysis” – 6/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Value of a variable (and an expression) • The value of a variable x along a trace 휋 is the last assigned value (or 0 at initialization). x = E = 푣 흔(휋ℓ −−−−−−−−−−−−−−−→ ℓ′)x ≜ 푣 … 흔(휋ℓ −−−−−−→ ℓ′)x ≜ 흔(휋ℓ) otherwise 흔(ℓ)x ≜ 0 • Value of an arithmetic expression 퓐J1K휌 ≜ 1 퓐JxK휌 ≜ 휌(x) J K J K J K 퓐 A1 - A2 휌 ≜ 퓐 A1 휌 − 퓐 A2 휌 • Same for boolean expressions. “Calculational design of, a static dependency analysis” – 7/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Structural fixpoint prefix/maximal trace semantics 퓢̂ ∗JSK • The prefix trace semantics 퓢̂ ∗JSK is a relation between J K J K • an initialization trace 휋0at S arriving at S , and • the prefix execution traces atJSK휋 continuing this initialization by zero or more execution steps • The maximal trace semantics 퓢̂ +∞JSK collects the maximal finite traces and the infinite traces obtained as limits of their prefixes. “Calculational design of, a static dependency analysis” – 8/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Structural fixpoint definition of the prefix trace semantics (I) • Assignment S ∶∶= ℓ x = A ; (where atJSK = ℓ) 퓢∗JSK ≜ {⟨휋ℓ, ℓ⟩ ∣ 휋ℓ ∈ 핋+} ∪ x = A = 휈 {⟨휋ℓ, ℓ −−−−−−−−−−−−−−−−→ afterJSK⟩ ∣ 휋ℓ ∈ 핋+ ∧ 휈 = 퓐JAK흔(휋ℓ)} . “Calculational design of, a static dependency analysis” – 9/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Structural fixpoint definition of the prefix trace semantics (II) ℓ J K ℓ • Iteration S ∶∶= while (B) S푏 (where at S = ): 퓢∗JSK = lfp⊆ 퓕∗JSK ∗J ℓ K ℓ′ ℓ′ ℓ′ + ℓ′ ℓ 퓕 while (B) S푏 (푋) ≜ {⟨휋1 , ⟩ | 휋1 ∈ 핋 ∧ = } (a) ¬(B) ℓ′ ℓ′ ℓ′ J K ℓ′ ℓ′ ℓ′ ∪ {⟨휋1 , 휋2 −−−−−−−−−→ after S ⟩ | ⟨휋1 , 휋2 ⟩ ∈ 푋 ∧ J K ℓ′ ℓ′ ℓ′ ℓ 퓑 B 흔(휋1 휋2 ) = ff ∧ = } (b) B ℓ′ ℓ′ ℓ′ J K ⌢ ℓ′ ℓ′ ℓ′ ∪ {⟨휋1 , 휋2 −−−−→ at S푏 ⋅ 휋3⟩ | ⟨휋1 , 휋2 ⟩ ∈ 푋 ∧ B J K ℓ′ ℓ′ ℓ′ ℓ′ J K ∗J K ℓ′ ℓ 퓑 B 흔(휋1 휋2 ) = tt ∧ ⟨휋1 휋2 −−−−→at S푏 , 휋3⟩ ∈ 퓢 S푏 ∧ = } (c) A definition of the form 푑(푥)⃗ ≜ {푓(푥′)⃗ ∣ 푃(푥′,⃗ 푥)}⃗ has the variables 푥′⃗ in 푃(푥′,⃗ 푥)⃗ bound to those of 푓(푥′)⃗ whereas 푥⃗ is free in 푃(푥′,⃗ 푥)⃗ since it appears neither in 푓(푥′)⃗ nor (by assumption) under quantifiers in 푃(푥′,⃗ 푥)⃗ . The 푥⃗ of 푃(푥′,⃗ 푥)⃗ is therefore bound to the 푥⃗ of 푑(푥)⃗ . “Calculational design of, a static dependency analysis” – 10/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Properties . “Calculational design of, a static dependency analysis” – 11/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Property • A property is represented by a set of elements (those elements which have the property) • Even intergers: 2Z ≜ {2푘 ∣ 푘 ∈ Z} • 푥 has property 푃 is 푥 ∈ 푃 • Implication is 푃1 ⊆ 푃2 . “Calculational design of, a static dependency analysis” – 12/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Semantic property • The prefix trace semantics belongs to ℘(핋+ × 핋+∞) • A semantics property belongs to ℘(℘(핋+ × 핋+∞)) • The abstraction 휆 푄 . ℘(푄) + +∞ + +∞ ⟨℘(℘(핋 × 핋 )), ⊆⟩ −−−−−−−−−−−−→⟶←−−−−−−−−−−−−−− ⟨℘(핋 × 핋 ), ⊆⟩ 휆 푃 . ∪푃 provides trace properties (e.g.safety, liveness, etc.) . “Calculational design of, a static dependency analysis” – 13/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Dependency, informally . “Calculational design of, a static dependency analysis” – 14/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Dependency, informally ℓ • At program point , the variable y depends upon the initial value 푥0 of variable x iff changing only 푥0 will change the non-empty sequences of values 푦0, 푦1,… of y observed at ℓ whenever control reaches ℓ • Example: ℓ0 if (x=0) { y=x; ℓ1} ℓ2 • y does not depend on x neither at ℓ0 nor at ℓ1 • y depends on x at ℓ2 • No need to distinguish between explicit and implicit dependencies • Absence of observation is not an observation • No timing channels . “Calculational design of, a static dependency analysis” – 15/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Dependency, formally . “Calculational design of, a static dependency analysis” – 16/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Observation of the sequence of values of a variable at a program point + • non-empty initialization trace 휋0 ∈ 핋 • non-empty continuation trace 휋 ∈ 핋+∞ J Kℓ ℓ • seqval y (휋0, 휋) is the sequence of values of the variable y at program point along the trace 휋 continuing 휋0 J Kℓ ℓ seqval y (휋0, ) ≜ 흔(휋0)y J Kℓ ℓ′ seqval y (휋0, ) ≜ ϶ 푎 푎 J Kℓ ℓ ℓ″ J Kℓ ⌢ ℓ ℓ″ ℓ″ seqval y (휋0, −−−−→ 휋) ≜ 흔(휋0)y ⋅ seqval y (휋0 ⋅ −−−−→ , 휋) 푎 푎 J Kℓ ℓ′ ℓ″ J Kℓ ⌢ ℓ′ ℓ″ ℓ″ seqval y (휋0, −−−−→ 휋) ≜ seqval y (휋0 ⋅ −−−−→ , 휋) J Kℓ ℓ • seqval y (휋0, 휋) is the empty sequence ϶ if never appears in 휋 (co-inductive definition for infinite traces). “Calculational design of, a static dependency analysis” – 17/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Difference between sequences of values 휔 and 휔′ • Sequences that differ may have a common prefix but must eventually havea different value at some position in the sequences. diff(휔, 휔′) ≜ ∃휔0, 휔1, 휔′1, 휈, 휈′ . 휔 = 휔0 ⋅ 휈 ⋅ 휔1 ∧ 휔′ = 휔0 ⋅ 휈′ ⋅ 휔′1 ∧ 휈 ≠ 휈′ . “Calculational design of, a static dependency analysis” – 18/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Dependency, formally • Dependency property: ℓ + +∞ 풟diff ⟨x, y⟩ ≜ {Π ∈ ℘(핋 × 핋 ) ∣ ∃⟨휋0, 휋1⟩, ⟨휋′0, 휋′1⟩ ∈ Π . (∀z ∈ V ⧵ {x}. 흔(휋0)z = 흔(휋′0)z) ∧ J Kℓ J Kℓ diff(seqval y (휋0, 휋1), seqval y (휋′0, 휋′1))} • y depends on the initial value of x at program point ℓ in program P is: ̂ +∞J K 퓢 P ∈ 풟diff ℓ⟨x, y⟩ • Lemma ̂ +∞J K ̂ ∗J K 퓢 P ∈ 풟diff ℓ⟨x, y⟩ ⇔ 퓢 P ∈ 풟diff ℓ⟨x, y⟩ . “Calculational design of, a static dependency analysis” – 19/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Value dependency abstraction . “Calculational design of, a static dependency analysis” – 20/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Abstraction en dépendance de données • The abstraction of a semantic property S ∈ ℘(℘(핋+ × 핋+∞)) into a value dependency property 훼ᶁ(S) ∈ L → ℘(V × V ) is: ᶁ 훼 (S)ℓ ≜ {⟨x, y⟩ ∣ S ∈ 풟diff ℓ⟨x, y⟩} • This is a Galois connection: 훾ᶁ + +∞ ᶁ Lemma 1 ⟨℘(℘(핋 × 핋 )), ⊆⟩ −−−−−→←−−−−− ⟨L → ℘(V × V ), ⊇ ⟩ where the concretization 훼ᶁ of a dependency property 퐃 ∈ L → ℘(V × V ) is: ᶁ 훾 (퐃) ≜ ⋂ ⋂ 풟diff ℓ⟨x, y⟩ ℓ∈L ⟨x, y⟩∈퐃(ℓ) (the more semantics, the less common dependencies) . “Calculational design of, a static dependency analysis” – 21/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Static dependency analysis . “Calculational design of, a static dependency analysis” – 22/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Potential dependency • 훼ᶁ({퓢∗JSK}) is not computable (Rice theorem) • We design an over-approximation: ̂ diff Abstract potential dependency semantics 퓢 ∃ : ᶁ +∞J K ̂ diffJ K 훼 ({퓢 S }) ⊆̇ 퓢 ∃ S • The abstraction in D. E. Denning and P. J. Denning, 1977 is purely syntactic; • We do a little better by taking the semantics is a simple way. “Calculational design of, a static dependency analysis” – 23/39 – © P. Cousot, NYU, CIMS, CS, April 6th, 2019 Calculation design ̂ diffJ K • 퓢 ∃ S is designed by calculus (in principle can be checked in Coq as Jourdan, Laporte, Blazy, Leroy, and Pichardie, 2015); • By structural induction on the program syntax; • By fixpoint approximation for iteration: Theorem (fixpoint over-approximation) If ⟨C, ⊑, ⊥, ⊤, ⊔, ⊓⟩ and ⟨A, ≼, 0, 1, ⋎, 훾 ⋏⟩ are complete lattices, ⟨C, ⊑⟩ ←−−−− ⟨A, ≼⟩ is a Galois connection, 푓 ∈ C ⟶↗ C and −−−−→훼 푓 ∈ A ⟶↗ A are monotonally increasing and 훼 ∘ 푓 ≼̇ 푓 ∘ 훼 (semi-commutation) then lfp⊑ 푓 ⊑ 훾(lfp≼ 푓).
Load more

Recommended publications
  • Project-Team Abstraction Abstract Interpretation
    INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE Project-Team Abstraction Abstract Interpretation Paris - Rocquencourt THEME SYM c t i v it y ep o r t 2007 Table of contents 1. Team .................................................................................... 1 2. Overall Objectives ........................................................................ 1 2.1. Overall Objectives 1 2.2. Highlights of the Year 1 3. Scientific Foundations .....................................................................2 3.1. Abstract Interpretation Theory 2 3.2. Formal Verification by Abstract Interpretation 2 3.3. Advanced Introductions to Abstract Interpretation 3 4. Application Domains ......................................................................3 4.1. Certification of Safety Critical Software 3 4.2. Security Protocols 4 4.3. Abstraction of Biological Cell Signalling Networks 4 5. Software ................................................................................. 4 5.1. The Astrée Static Analyzer 4 5.2. The Apron Numerical Abstract Domain Library 5 5.3. Translation Validation 6 5.4. ProVerif 6 5.5. CryptoVerif 7 6. New Results .............................................................................. 7 6.1. Abstract Semantics of Grammars 7 6.2. Bi-inductive Definitions and Bifinitary Semantics of the Eager Lambda-Calculus 8 6.3. Verification of Security Protocols in the Formal Model 8 6.3.1. Automatic Verification of Correspondences for Security Protocols 8 6.3.2. Case Study: the Protocol Just Fast Keying (JFK) 8 6.3.3. Case Study: the Secure Storage System Plutus 9 6.4. Verification of Security Protocols in the Computational Model 9 6.4.1. Computationally Sound Mechanized Proofs of Correspondence Assertions 9 6.4.2. Computationally Sound Mechanized Proofs for Basic and Public-key Kerberos 9 6.5. Analysis of Biological Pathways 10 6.5.1. Reachability Analysis of Biological Signalling Pathways by Abstract Interpretation 10 6.5.2.
    [Show full text]
  • Static Analysis and Verification of Aerospace
    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
    [Show full text]
  • Team ANTIQUE
    IN PARTNERSHIP WITH: CNRS Ecole normale supérieure de Paris Activity Report 2014 Team ANTIQUE Analyse Statique par Interprétation Abstraite RESEARCH CENTER Paris - Rocquencourt THEME Proofs and Verification Table of contents 1. Members :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 2. Overall Objectives :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 3. Research Program :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 3.1. Semantics 3 3.2. Abstract interpretation and static analysis3 3.3. Applications of the notion of abstraction in semantics4 3.4. The analysis of biological models4 4. Application Domains ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::4 4.1. Verification of safety critical embedded software4 4.2. Static analysis of software components and libraries5 4.3. Biological systems6 5. New Software and Platforms :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 6 5.1. The Apron Numerical Abstract Domain Library6 5.2. The Astrée Static Analyzer of Synchronous Software7 5.3. The AstréeA Static Analyzer of Asynchronous Software8 5.4. ClangML: A binding with the CLANG C-frontend8 5.5. FuncTion: An Abstract Domain Functor for Termination9 5.6. HOO: Heap Abstraction for Open Objects9 5.7. The MemCADstatic analyzer9 5.8. The OpenKappa Modeling Plateform 10 5.9. QUICr set abstract domain 10 5.10. Translation Validation 10 5.11. Zarith 10 6. New Results ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 6.1. Highlights of the Year 11 6.2. Memory Abstraction 11 6.2.1. Modular Construction of Shape-Numeric Analyzers 11 6.2.2. An abstract domain combinator for separately conjoining memory abstractions 11 6.2.3. Abstraction of Arrays Based on Non Contiguous Partitions 12 6.3. Static analysis of JavaScript applications 12 6.3.1. Automatic Analysis of Open Objects in Dynamic Language Programs 12 6.3.2. Desynchronized Multi-State Abstractions for Open Programs in Dynamic Languages 12 6.4.
    [Show full text]
  • Project-Team Abstraction Abstract Interpretation
    INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE Project-Team Abstraction Abstract Interpretation Paris - Rocquencourt THEME ALGORITHMICS, PROGRAMMING, SOFTWARE AND ARCHITECTURE c t i v it y ep o r t 2008 Table of contents 1. Team .................................................................................... 1 2. Overall Objectives ........................................................................ 1 2.1. Overall Objectives 1 2.2. Highlights of the Year 2 3. Scientific Foundations .....................................................................2 3.1. Abstract Interpretation Theory 2 3.2. Formal Verification by Abstract Interpretation 3 3.3. Advanced Introductions to Abstract Interpretation 4 4. Application Domains ......................................................................4 4.1. Certification of Safety Critical Software 4 4.2. Security Protocols 5 4.3. Abstraction of Biological Cell Signalling Networks 5 5. Software ................................................................................. 5 5.1. The Astrée Static Analyzer 5 5.2. The Apron Numerical Abstract Domain Library 6 5.3. Translation Validation 7 5.4. ProVerif 7 5.5. CryptoVerif 8 6. New Results .............................................................................. 9 6.1. Abstract Semantics of Grammars 9 6.2. Abstract Semantics of Resolution-Based Logic Languages 9 6.3. Bi-inductive Definitions and Bifinitary Semantics of the Eager Lambda-Calculus 9 6.4. Verification of Security Protocols in the Formal Model 10 6.4.1. Case Study: the Secure Storage System Plutus 10 6.4.2. Extensions of ProVerif 10 6.5. Verification of Security Protocols in the Computational Model 10 6.5.1. Computationally Sound Mechanized Proofs for Basic and Public-key Kerberos 10 6.5.2. Extensions of CryptoVerif 11 6.6. Verification of Security Protocols: Formal Model and Computational Model 11 6.7. Analysis of Biological Pathways 11 6.7.1. Reachable Species Analysis 11 6.7.2.
    [Show full text]
  • Abstract Interpretation”
    ‟Next 40 years of Abstract Interpretation” Abstract Interpretation – 40 years back + some years ahead Abstract interpretation: origin (abridged) N40AI 2017 January 21st, 2017 Paris, France Patrick Cousot [email protected]@yu.e1du cs.nyu.edu/~pcousot N40AI, 2017/01/21, Paris, France 1 © P. Cousot N40AI, 2017/01/21, Paris, France 2 © P. Cousot Before starting (1972-73): formal syntax Before starting (1972-73): formal semantics • Radhia Rezig: works on precedence parsing (R.W. • Patrick Cousot: works on the operational semantics of Floyd, N. Wirth and H. Weber, etc.) for Algol 68 programming languages and the derivation of ➡ P r e - p r o c e s s i n g ( by s t a t i c a n a l y s i s a n d implementations from the formal definition transformation) of the grammar before building the ➡ Static analysis of the formal definition and bottom-up parser transformation to get the implementation by “pre- • Patrick Cousot: works on context-free grammar evaluation” (similar to the more recent “partial parsing (J. Earley and F. De Remer) evaluation”) ➡ P r e - p r o c e s s i n g ( by s t a t i c a n a l y s i s a n d transformation) of the grammar before building the top-down parser • Radhia Rezig. Application de la méthode de précédence totale à l’analyse d’Algol 68, Master thesis, Université Joseph Fourier, Grenoble, France, September 1972. • Patrick Cousot. Définition interprétative et implantation de languages de programmation. Thèse de Docteur Ingénieur en Informatique, Université Joseph Fourier, Grenoble, France, 14 Décembre 1974 (submitted in 1973 • Patrick Cousot.
    [Show full text]
  • Introduction to Abstract Interpretation
    Introduction to Abstract Interpretation Bruno Blanchet D´epartement d'Informatique Ecole´ Normale Sup´erieure, Paris and Max-Planck-Institut fur¨ Informatik [email protected] November 29, 2002 Abstract We present the basic theory of abstract interpretation, and its application to static program analysis. The goal is not to give an exhaustive view of abstract interpretation, but to give enough background to make papers on abstract interpretation more under- standable. Notations: λx.M denotes the function that maps x to M. f[x 7! M] denotes the function f extended so that x is mapped to M. If f was already defined at x, the new binding replaces the old one. 1 Introduction The goal of static analysis is to determine runtime properties of programs without executing them. (Scheme of an analyzer: Program ! Analyzer ! Properties.) Here are some examples of properties can be proved by static analysis: • For optimization: { Dead code elimination { Constant propagation { Live variables { Stack allocation (more complex) • For verification: { Absence of runtime errors: division by zero, square root of negative numbers, overflows, array index out of bounds, pointer dereference outside objects, . { Worst-case execution time (see Wilhelm's work with his team and AbsInt) { Security properties (secrecy, authenticity of protocols, . ) 1 However, most interesting program properties are undecidable. The basic result to show undecidability is the undecidability of the halting problem. Proof By contradiction. Assume that there exists Halt(P,E) returning Yes when P termi- nates on entry E, No otherwise. Consider P'(P) = if Halt(P,P) then loop else stop. • If P'(P') loops, Halt(P',P') = true, so P'(P') stops: contradiction.
    [Show full text]
  • Presentation of the Abstraction Project Proposal »
    « Presentation of the Abstraction project proposal » Patrick Cousot École normale supérieure 45 rue d’Ulm, 75230 Paris cedex 05, France [email protected] www.di.ens.fr/~cousot Projects’ committee — INRIA Rocquencourt Thursday March 8th, 2007 Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 1 — ľ P. Cousot 1. Project Members Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 2 — ľ P. Cousot Project Members Julien Bertrane, PhD student Bruno Blanchet, CR1 CNRS Patrick Cousot,Prof. Jérôme Feret, CDD Laurent Mauborgne, MdC Antoine Miné, ATER David Monniaux,CR1CNRS Xavier Rival, CDD Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 3 — ľ P. Cousot 2. The Problem: The Design of Safe and Secure Computer- Based Systems Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 4 — ľ P. Cousot Software is Everywhere – exponential growth of hardware since 1975 – ) exponential growth of software (favored by software engineering methods) – mainly manual activity ) bugs are everywhere l Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 5 — ľ P. Cousot Guaranteeing the Reliability and Security of Software-Intensive Systems – an objective of the INRIA strategic plan – an industrial categorical imperative, in particular for safety and security critical software (validation can ac- count for up to 60% of software development costs) Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 6 — ľ P. Cousot Validation/Formal Methods – bug-finding methods : unit, integration, and system testing, dynamic verification, bounded model-checking, . – absence of bug proving methods : formally prove that the semantics of a program satisfies a specification - theorem-proving & proof checking - model-checking - abstract interpretation – in practice : complementary methods are used, very difficult to scale up Projects’ committee, INRIA Rocquencourt, 8/3/2007 — 7 — ľ P.
    [Show full text]
  • On Various Abstract Understandings of Abstract Interpretation
    1 On Various Abstract Understandings of Abstract Interpretation Patrick COUSOT Courant Institute of Mathematical Sciences New York University cp ousot@ ci ms. n u.ey ud , cimn.s u . e dy/u ˜ o spcu ot Abstract—We discuss several possible understandings and is correct/sound for all programs of a programming language, misunderstandings of Abstract Interpretation theory and practice it is necessary to compare the results of the static analysis at various levels of abstraction. with a formal definition of the program semantics (sometimes Keywords-Abstract Interpretation, Abstraction, Completeness, called a model) [7]. Formal methods, Semantics, Semantics, Soundness, Static anal- Abstract Interpretation goes much further by showing how ysis, Verification. to formally construct the static analyzer from the definition of program properties as specified by the semantics [8]. ABSTRACT INTERPRETATION FOR STATIC ANALYSIS These ideas lead to mechanically checked static analyzers Abstract Interpretation (see [10], [11] for gentle introduc- [19], and hopefully in the future, to mechanically constructed tions) can be, and is often, understood in a very narrow sense: static analyzers (as has been done by hand, e.g. in [3] for type an algorithm for static analysis of sequential programs with systems). widening and narrowing, even maybe restricted to interval analysis only. HIERARCHIES OF ABSTRACTIONS This was indeed the origin of the concept [6] and the very first fully automatic infinitary static analysis, rapidly followed A more profound understanding of Abstract Interpretation by more expressive and costly relational analyzes [15]. leads to a much broader scope of application. To cope with For programming languages, i.e. infinitely many pro- complex problems, e.g.
    [Show full text]
  • Automotive Embedded Software Design Using Formal Methods Vassil Todorov
    Automotive embedded software design using formal methods Vassil Todorov To cite this version: Vassil Todorov. Automotive embedded software design using formal methods. Modeling and Simula- tion. Université Paris-Saclay, 2020. English. NNT : 2020UPASG026. tel-03082647 HAL Id: tel-03082647 https://tel.archives-ouvertes.fr/tel-03082647 Submitted on 18 Dec 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Automotive embedded software design using formal methods Thèse de doctorat de l’Université Paris-Saclay École doctorale n◦ 580, Sciences et Technologies de l’Information et de la Communication Spécialité de doctorat: Informatique Unité de recherche: Université Paris-Saclay, CNRS, Laboratoire de recherche en informatique, 91405, Orsay, France Référent: CentraleSupélec Thèse présentée et soutenue à Gif-sur-Yvette, le 9 décembre 2020, par Vassil TODOROV Composition du jury: Pascale Le Gall Présidente et examinatrice Professeur, CentraleSupélec Gérard Berry Rapporteur et examinateur Professeur émérite, Collège de France Cesare Tinelli Rapporteur et examinateur
    [Show full text]
  • Astrée: Proving the Absence of Runtime Errors
    Astrée: Proving the Absence of Runtime Errors Daniel Kästner,1 Stephan Wilhelm,1 Stefana Nenova,1 Patrick Cousot,† Radhia Cousot,† Jérôme Feret,† Laurent Mauborgne,† Antoine Miné,† Xavier Rival,† 1: AbsInt Angewandte Informatik GmbH. Science Park 1, D-66123 Saarbrücken, Germany 2: École Normale Supérieure. 45, rue d’Ulm, F-75230 Paris, France Abstract: Safety-critical embedded software has without actually running the software under analy- to satisfy stringent quality requirements. Testing sis. The results thus obtained hold for any possi- and validation consumes a large – and growing – ble input scenario and any possible program execu- fraction of development cost. The last years have tion. Examples are tools for computing the worst- seen the emergence of semantics-based static anal- case execution time [28, 13] or the maximal stack ysis tools in various application areas, from runtime usage of tasks [12], the accuracy of floating-point error analysis to worst-case execution time predic- computations [20], and the absence of run-time er- tion. Their appeal is that they have the poten- rors [2,6,8]. Modern semantics-based static ana- tial to reduce testing effort while providing 100% lyzers scale well and support the analysis of large coverage, thus enhancing safety. Static runtime industrial software projects. error analysis is applicable to large industry-scale This article focuses on a certain class of errors, the projects and produces a list of definite runtime er- so-called runtime errors. Examples for runtime er- rors and of potential runtime errors which might be rors are floating-point overflows, array bound vio- true errors or false alarms.
    [Show full text]
  • 2017-01-21-N40AI-1-1.Pdf
    ‟Next 40 years of Abstract Interpretation” Abstract Interpretation – 40 years back + some years ahead N40AI 2017 January 21st, 2017 Paris, France Patrick Cousot [email protected]@yu.e1du cs.nyu.edu/~pcousot N40AI, 2017/01/21, Paris, France 1 © P. Cousot Abstract interpretation: origin (abridged) N40AI, 2017/01/21, Paris, France 2 © P. Cousot Before starting (1972-73): formal syntax • Radhia Rezig: works on precedence parsing (R.W. Floyd, N. Wirth and H. Weber, etc.) for Algol 68 ➡ P r e - p r o c e s s i n g ( by s t a t i c a n a l y s i s a n d transformation) of the grammar before building the bottom-up parser • Patrick Cousot: works on context-free grammar parsing (J. Earley and F. De Remer) ➡ P r e - p r o c e s s i n g ( by s t a t i c a n a l y s i s a n d transformation) of the grammar before building the top-down parser • Radhia Rezig. Application de la méthode de précédence totale à l’analyse d’Algol 68, Master thesis, Université Joseph Fourier, Grenoble, France, September 1972. • Patrick Cousot. Un analyseur syntaxique pour grammaires hors contexte ascendant sélectif et général. In Congrès AFCET 72, Brochure 1, pages 106-130, Grenoble, France, 6-9 November 1972. N40AI, 2017/01/21, Paris, France 3 © P. Cousot Before starting (1972-73): formal semantics • Patrick Cousot: works on the operational semantics of programming languages and the derivation of implementations from the formal definition ➡ Static analysis of the formal definition and transformation to get the implementation by “pre- evaluation” (similar to the more recent “partial evaluation”) • Patrick Cousot.
    [Show full text]
  • Lipics-ECOOP-2021-14.Pdf (1
    Lifted Static Analysis of Dynamic Program Families by Abstract Interpretation Aleksandar S. Dimovski # Mother Teresa University, Skopje, North Macedonia Sven Apel # Saarland University, Saarland Informatics Campus, 66123 Saarbrücken, Germany Abstract Program families (software product lines) are increasingly adopted by industry for building families of related software systems. A program family offers a set of features (configured options) to control the presence and absence of software functionality. Features in program families are often assigned at compile-time, so their values can only be read at run-time. However, today many program families and application domains demand run-time adaptation, reconfiguration, and post-deployment tuning. Dynamic program families (dynamic software product lines) have emerged as an attempt to handle variability at run-time. Features in dynamic program families can be controlled by ordinary program variables, so reads and writes to them may happen at run-time. Recently, a decision tree lifted domain for analyzing traditional program families with numerical features has been proposed, in which decision nodes contain linear constraints defined over numerical features and leaf nodes contain analysis properties defined over program variables. Decision nodes partition the configuration space of possible feature values, while leaf nodes provide analysis information corresponding to each partition of the configuration space. As features are statically assigned at compile-time, decision nodes can be added, modified, and deleted only when analyzing read accesses of features. In this work, we extend the decision tree lifted domain so that it can be used to efficiently analyze dynamic program families with numerical features. Since features cannowbe changed at run-time, decision nodes can be modified when handling read and write accesses of feature variables.
    [Show full text]