static analysis of software

Static Analysis of Software www.it-ebooks.info Static Analysis of Software The Abstract Interpretation Edited by Jean-Louis Boulanger www.it-ebooks.info First published 2012 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.Adapted and updated from Utilisationsindustrielles des techniques formelles : interprétationabstraite published 2011 in France by Hermes Science/Lavoisier © LAVOISIER 2011 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address: ISTE Ltd John Wiley & Sons, Inc. 27-37 St George’s Road 111 River Street London SW19 4EU Hoboken, NJ 07030 UK USA www.iste.co.uk www.wiley.com © ISTE Ltd 2012 The rights of Jean-Louis Boulanger to be identified as the author of this work have been asserted by him in accordance with the Copyright, Designs and Patents Act 1988. ____________________________________________________________________________________ Library of Congress Cataloging-in-Publication Data Static analysis of software : the abstract interpretation / edited by Jean-Louis Boulanger. p. cm. Includes bibliographical references and index. ISBN 978-1-84821-320-3 1. Computer software Testing. 2. Debugging in computer science. 3. Computer software Quality control. I. Boulanger, Jean-Louis. QA76.76.T48S75 2011 005.1'4 dc23 2011039611 British Library Cataloguing-in-Publication Data A CIP record for this book is available from the British Library ISBN: 978-1-84821-320-3 Printed and bound in Great Britain by CPI Group (UK) Ltd., Croydon, Surrey CR0 4YY www.it-ebooks.info Table of Contents Introduction xi Jean-Louis Boulanger Chapter 1. Formal Techniques for Verification and Validation 1 Jean-Louis B OULANGER 1.1. Introduction 1 1.2.Realizationofasoftwareapplication 1 1.3.Characteristicsofasoftwareapplication 3 1.4.Realizationcycle 4 1.4.1.CycleinVandotherrealizationcycles 4 1.4.2.Quality control (the impact of ISO standard 9001) 7 1.4.3.Verificationandvalidation 9 1.5. Techniques, methods and practices 13 1.5.1.Staticverification 13 1.5.2.Dynamicverification 35 1.5.3.Validation 39 1.6.Newissueswithverificationandvalidation 39 1.7.Conclusion 41 1.8.Bibliography 42 Chapter 2. Airbus: Formal Verification in Avionics 45 Jean Souyris, David D ELMAS and Stéphane DUPRAT 2.1. Industrial context 45 2.1.1.Avionicsystems 45 2.1.2.Afewexamples 46 2.1.3.Regulatoryframework 47 2.1.4.Avionicfunctions 47 2.1.5.Developmentofavionicslevels 50 www.it-ebooks.info vi Static Analysis of Software 2.2. Two methods for formal verification 52 2.2.1.Generalprincipleofprogramproof 53 2.2.2.Staticanalysisbyabstractinterpretation 54 2.2.3.Programproofbycalculationoftheweakestprecondition 61 2.3.Fourformalverificationtools 66 2.3.1.Caveat 66 2.3.2.Proofoftheabsenceofrun-timeerrors:Astrée 68 2.3.3.Stability and numerical precision: Fluctuat 73 2.3.4. Calculation of the worst case execution time: aiT (AbsInt GmbH) 78 2.4.Examplesofindustrialuse 80 2.4.1.UnitaryProof(verificationoflowlevelrequirements) 80 2.4.2.Thecalculationofworstcaseexecutiontime 97 2.4.3.Proofoftheabsenceofrun-timeerrors 103 2.6.Bibliography 109 Chapter 3. Polyspace 113 Patrick M UNIER 3.1. Overview 113 3.2.Introduction to software quality and verification procedures 114 3.3.Staticanalysis 116 3.4.Dynamictests 116 3.5.Abstractinterpretation 117 3.6.Codeverification 118 3.7.Robustnessverificationorcontextualverification 121 3.7.1.Robustnessverifications 122 3.7.2.Contextualverification 122 3.8. Examples of Polyspace ® results 123 3.8.1.Exampleofsafecode 123 3.8.2.Example: dereferencing of a pointer outside its bounds 125 3.8.3.Example:inter-proceduralcalls 126 3.9.CarryingoutacodeverificationwithPolyspace 128 3.10. Use of Polyspace ® can improve the quality of embedded software . . 130 3.10.1. Begin by establishing models and objectives for software quality 130 3.10.2. Example of a software quality model with objectives 130 3.10.3.Useofasubsetoflanguagestosatisfycodingrules 132 3.10.4. Use of Polyspace ® to reach software quality objectives 133 3.11. Carrying out certification with Polyspace ® 135 3.12.Thecreationofcriticalonboardsoftware 135 3.13. Concrete uses of Polyspace ® 135 www.it-ebooks.info Table of Contents vii 3.13.1. Automobile: Cummins engines improves the reliability of its motor’s controllers 136 3.13.2. Aerospace: EADS guarantees the reliability of satellite launches 137 3.13.3. Medical devices: a code analysis leads to a recall of the device 138 3.13.4. Other examples of the use of Polyspace ® 139 3.14.Conclusion 141 3.15.Bibliography 141 Chapter 4. Software Robustness with Regards to Dysfunctional Values from Static Analysis 143 Christèle FAURE, Jean-Louis BOULANGER and Samy AÏT KACI 4.1. Introduction 143 4.2.Normativecontext 144 4.3.Elaborationoftheproofoftherobustnessmethod 146 4.4.Generaldescriptionofthemethod 151 4.4.1.Requiredoreffectivevaluecontrol 151 4.4.2.Computationoftherequiredcontrol 154 4.4.3.Verificationofeffectivecontrol 155 4.5.Computationofthecontrolrequired 157 4.5.1.Identificationofproduction/consumptionofinputs 159 4.5.2.Computationofvaluedomains 160 4.6.Verificationoftheeffectivecontrolofanindustrialapplication 161 4.6.1.Targetsoftware 161 4.6.2.Implementation 163 4.6.3.Results 169 4.7.Discussionandviewpoints 172 4.8.Conclusion 173 4.9.Bibliography 174 Chapter 5. CodePeer – Beyond Bug-finding with Static Analysis 177 Steve B AIRD, Arnaud CHARLET, Yannick MOY and Tucker TAFT 5.1. Positioning of CodePeer 177 5.1.1.Mixingstaticcheckingandcodeunderstanding 177 5.1.2.Generatingcontractsbyabstractinterpretation 179 5.2.A tour of CodePeer capabilities 182 5.2.1.Finddefectsincode 182 5.2.2.Usingannotationsforcodereviews 184 5.2.3.Categorizationofmessages 186 5.2.4.Helpwritingrun-timetests 187 5.2.5.Differentkindsofoutput 188 www.it-ebooks.info viii Static Analysis of Software 5.3. CodePeer’s inner working 188 5.3.1.Overview 188 5.3.2.FromAdatoSCIL 191 5.3.3.Objectidentification 193 5.3.4.Staticsingleassignmentandglobalvaluenumbering 195 5.3.5.Possiblevaluepropagation 200 5.4.Conclusions 204 5.5.Bibiliography 205 Chapter 6. Formal Methods and Compliance to the DO-178C/ED-12C Standard in Aeronautics 207 Emmanuel LEDINOT and Dillon PARIENTE 6.1. Introduction 207 6.2.PrinciplesoftheDO-178/ED-12standard 208 6.2.1.Inputsofthesoftwaredevelopmentprocess 208 6.2.2.Prescriptionofobjectives 209 6.3.Verificationprocess 212 6.4. The formal methods technical supplement 218 6.4.1.Classesofformalmethods 219 6.4.2. Benefits of formal methods to meet DO-178C/ED-12C objectives 221 6.4.3.Verificationoftheexecutablecodeatthesourcelevel 223 6.4.4.Revisionoftheroleofstructuralcoverage 225 6.4.5. Verification of the completeness of requirements and detection of unintended functions 227 6.5.LLRverificationbymodel-checking 229 6.6. Contribution to the verification of robustness properties with Frama-C 234 6.6.1.IntroductiontoFrama-C 234 6.6.2.Presentationofthecasestudy 241 6.6.3.Analysisprocessofthecasestudy 243 6.6.4.Conclusiononthecasestudy 252 6.7.Staticanalysisandpreservationofproperties 252 6.8.Conclusionandperspectives 256 6.9.Appendices 258 6.9.1. Automatically annotating a source code 258 6.9.2. Automatically subdividing input intervals 259 6.9.3.Introducingcutstrategiesfordeductiveverification 261 6.9.4.Combining abstract interpretation, deductive verification and functions which can be evaluated in assertions 263 6.9.5.ValidatingACSLlemmasbyformalcalculus 265 6.9.6.Combiningstaticanddynamicanalysis 266 www.it-ebooks.info Table of Contents ix 6.9.7. Finalizing 268 6.10.Acknowledgements 268 6.11.Bibliography 269 Chapter 7. Efficient Method Developed by Thales for Safety Evaluation of Real-to-Integer Discretization and Overflows in SIL4 Software 273 Anthony BAÏOTTO, Fateh KAAKAÏ, Rafael MARCANO and Daniel DRAGO 7.1. Introduction 273 7.2.Discretizationerrorsintheembeddedcodeproductionchain 274 7.2.1.Presentationoftheissue 274 7.2.2.Objectiveoftheanalysisofthereal-to-integerdiscretization 278 7.3.Modelingofthecreationandpropagationofuncertainties 280 7.3.1.Creationofuncertainties 280 7.3.2.Propagationofuncertainties 287 7.4.Goodpracticeofananalysisofreal-to-integerdiscretization 294 7.4.1.Codeextraction 294 7.4.2.Functionalcodereorganisation 294 7.4.3.Algorithmicbreakdowninbasicarithmeticrelations 295 7.4.4.Computationofuncertainties 295 7.5.Arithmeticoverflowanddivisionbyzero 297 7.5.1.Analysisofarithmeticoverflowrisk 297 7.5.2.Analysisoftheriskofdivisionbyzero 298 7.6.Applicationtoarailsignallingexample 299 7.6.1. General presentation of the communication-based train controller system 299 7.6.2.Exampleofanalysisofthebehaviorofspeedcontrol 300 7.6.3.Industrialscaleview:afewnumbers 306 7.7.Conclusion 307 7.8.Annexe:proofsupplements 308 7.8.1.Proof1:existenceandunicityofintegerdivision 308 7.8.2.Proof2:framingtheerrorofintegerdivision 312 7.8.3.Proof3:rulesofthearithmeticofuncertaintyintervals 314 7.8.4.Proof4:framingofuncertaintiesfromaproduct 314 7.9.Bibliography 317 Conclusion and viewpoints 319 Jean-Louis BOULANGER Glossary 323 List of Authors 327 Index 329 www.it-ebooks.info Introduction Context Although formal program analysis techniques (see works by Hoare [HOA 69] and Dijkstra [DIJ 75]) are quite old, the implementation of formal methods goes back to the 1980s. These techniques enable us to analyze the behavior of a software application described in programming language. Program correction (good behavior, program stop, etc.) is then demonstrated by program proof based on the calculation of the weakest precondition [DIJ 76]. It was not until the end of the 1990s that formal methods (Z [SPI 89], VDM [JON 90]) and the B method [ABR 96, ARA 97] were used in industrial applications and could be applied in an industrial context. One of the obstacles to their use was how they could be implemented in an industrial application (large application, time and cost constraints, etc.). They could only be implemented using tools that were mature enough and had sufficient performance. It is worth noting that in the context of critical applications, at least two formal methods have a recognized and commonly used design environment that covers part of the realization of the code specification process while integrating one or several verification processes, that is to say the B method [ABR 96] and Lustre language [HAL 91, ARA 97] and its graphic version, called SCADE ® [DOR 08]. The B method and SCADE ® environment are associated with proven industrial tools. For example, AtelierB and Btoolkit, commercially produced by Clearsy and Bcore, respectively, are tools that completely cover the B method development cycle (specification, refinement, code generation and proof). Introduction written by Jean-Louis BOULANGER. www.it-ebooks.info xii Static Analysis of Software Formal methods are based on different formal verification techniques, such as proof, model checking [BAI 08] and/or simulation. The use of formal methods, though in full expansion, is still marginal compared to the number of code lines. Indeed, there are currently many more lines of Ada [ANS 83], C and C++ code that have been manually produced via a formal process only. For this reason other formal techniques have been implemented to verify the behavior of a software application written in a programming language such as C or Ada. The main technique, called abstract program interpretation [COU 00], enables us to evaluate the set of behaviors of a software application using static analysis. In the past few years, this type of technique has given rise to several tools, such as Polyspace ®1 , Caveat 2 , Absint 3 , Frama-C 4 and/or Astrée 5 . The efficiency of these static program analysis techniques has greatly progressed with the increase in the power of office equipment. It is worth noting that these techniques generally require the integration of complementary information into the manual code, such as pre-conditions, invariants and/or post-conditions. SPARK Ada 6 is an approach where Ada has been extended [BAR 03] in order to introduce additional elements (pre, post and invariant) and a sequence of adapted tools has been defined. Objective In [BOW 95] and [ARA 97], we have the first feedback from industrialists regarding formal techniques, and in particular feedback on the B method, Lustre language [HAL 91, ARA 97] and SAO+ (SCADE ® ’s predecessor). Other works, such as [MON 00, MON 02, HAD 06] provide an overview of formal methods from a scientific point of view. With regards to the presentation of context and the state of the literature, our objective is to present concrete examples of the industrial uses of formal techniques. By formal techniques, we mean different approaches based on mathematics, which enable us to demonstrate that a software application respects a certain number of properties. 1 See www.mathworks.com/ products/polyspace/. 2 See www-list.cea.fr/labos/fr/LSL/caveat/ index.html. 3 See web www.absint.com. 4 To find out more, see web frama-c.com. 5 See www.astree.ens.fr. 6 See www.altran-praxis.com/spark.aspx contains additional information about SPARK Ada. www.it-ebooks.info [...]... the robustness of the software; 2 xx is the name of the object www.it-ebooks.info 16 Static Analysis of Software – evaluate the amount of validation effort to be carried out on the various components of the software Figure 1.8 Example of SEEA table Its application is broken down into three phases: – preliminary analysis of all the safety procedures for characterizing the development of studies for... Realization of a software application It is worth noting that we are talking about the realization of a software application and not the development of a software application The realization of a software application includes development activities but also activities of verification, validation, production, installation and maintenance Chapter written by Jean-Louis BOULANGER www.it-ebooks.info 2 Static Analysis. .. analyzed); – procedure-by-procedure analysis of the consequences for safety of the envisaged software errors (analysis sheet for each procedure analyzed containing the identification of errors, safety criteria associated with each criteria and the consequences of errors); – summary of works in view of software validation and the development of the safety dossier (list of scenarios that go against safety,... 23 Symbolic execution consists of carrying out the execution of a software application but changing the type of data Indeed, we have gone from a software application that handles numbers to a handling of algebraic expressions (see Figure 1.11) The complete symbolic execution of a software application is impossible, as a limit − the number of turns of the cycles − is often dependent on the execution... includes the creation of a model, M The static view (see Figure 1.12) has two viewpoints: www.it-ebooks.info 24 Static Analysis of Software – hierarchical point of view, which allows the visualization of the decomposition tree; – composition point of view, which enables communications between models of the same level to be visualized Figure 1.12 Example of static introducing different types of communication... www.it-ebooks.info 14 Static Analysis of Software The objective of software inspection is to look for faults (understanding, interpretation, translation, etc.), deviations − particularly with regards to quality clauses, absences or overabundances, etc − and to supply elements to provide corrections The aim of software inspection is not to carry out corrections In order to be efficient, software inspection... tools for programming rule verification such as: codewizard 1.5.1.1.4 Software error effects analysis SEEA [AFN 90, GAR 94] is part of analyses that are carried out during the various stages of development SEEA consists of examining the consequences of potential software errors The objectives of SEEA are to: – identify these integrated software components with precision, and to evaluate their criticality... particle are capable of making a bit in the memory evolve, thus making the program or associated data evolve, etc; – of great complexity and therefore very high (too high?) cost: the size of software applications has gone from several tens of thousands of lines to several hundreds of thousands of lines of code and the question of how to manage this complexity thus arises; – etc This list of characteristics... generally presented The objective of the analysis of needs is to verify the appropriateness of the expectations of the client and the technological feasibility The specification phase has the objective of describing what the software must do (and not how it will do it) In the context of the architectural definition, we are seeking to carry out a hierarchical decomposition of the software application in a module/component... static analysis These are inspection (documentary inspection, code inspection) and software error effects analysis (SEEA) 1.5.1.1.1 Software inspection: principles Software inspection (see [GRA 93]) is the technique for manual static analysis, the objective of which is to discover faults as soon as possible DEFINITION 1.6 – Software inspection This is a control technique enabling us to ensure that documentation . Realization of a software application It is worth noting that we are talking about the realization of a software application and not the development of a software application. The realization of a software. 47 2.1.5.Developmentofavionicslevels 50 www.it-ebooks.info vi Static Analysis of Software 2.2. Two methods for formal verification 52 2.2.1.Generalprincipleofprogramproof 53 2.2.2.Staticanalysisbyabstractinterpretation. Static Analysis of Software www.it-ebooks.info Static Analysis of Software The Abstract Interpretation