Abstract Interpretation-based Static Analysis Tools:

Transcription

1 Abstract Interpretation-based Static Analysis Tools: Proving the Absence of Runtime Errors and Safe Upper Bounds on the Worst-Case Execution Time and Safe Upper Bounds on the Stack Usage Christian Ferdinand AbsInt GmbH 2013

2 AbsInt Angewandte Informatik GmbH Provides advanced development tools for embedded systems, and tools for validation, verification, and certification of safety-critical software. Founded in February 1998 by six researchers of Saarland University, Germany, from the group of programming languages and compiler construction of Prof. R. Wilhelm. Privately held by the founders. Selected Customers:

3 Background Time drift in Patriot rockets in 1991 [Rounding error] Crash of railway switch controller 1995 in HamburgAltona [Stack overflow] Explosion of Ariane rocket 1996 [Arithmetic overflow] AECL Medical Therac-25 incident ( ) [Arithmetic overflow]

4 Functional Safety Demonstration of functional correctness Required by Well-defined criteria Automated and/or model-based testing Formal techniques: model checking, theorem DO-178B / DO-178C ISO-26262, EN IEC proving Satisfaction of non-functional requirements No crashes due to runtime errors (Division by zero, Required by invalid pointer accesses, overflow and roundingdo-178b errors) / DO-178C Resource usage: ISO-26262, EN Timing requirements (e.g. WCET, WCRT) Memory requirements (e.g. no stack overflow) IEC Insufficient: Tests & Measurements Test end criteria unclear No full coverage possible "Testing, in general, cannot show the absence of errors." [DO-178B]

5 Key Products: AI-based Static Analyzers ait WCET Analyzer Proving the correct timing behavior Safe upper bounds on the worst-case execution time of tasks in real-time systems StackAnalyzer Excluding stack overflows Safe upper bounds on maximal stack usage of tasks Astrée Proving the absence of runtime errors (division by zero, arithmetic overflow, invalid pointer accesses, etc.) in C programs

6 Static Analysis an Overview General Definition: results are only computed from the program structure, without executing the program under analysis. Classification Syntax-based: Style checkers (e.g. MISRA-C) Unsound semantics-based: Bug-finders / bug-hunters. Can find some bugs, but cannot guarantee that all bugs are found. Examples: Splint, Coverity CMC, Klocwork K7, Sound semantics-based / Abstract Interpretation-based Can guarantee that all bugs (from the class under analysis) are found. Results valid for every possible program execution with any possible input scenario. Examples: ait, StackAnalyzer, Polyspace Verifier, Astrée.

7 Static Analysis an Overview General Definition: results are only computed from the program structure, without executing the program under analysis. Classification Syntax-based: Style checkers (e.g. MISRA-C) Unsound semantics-based: Bug-finders / bug-hunters. Can find some bugs, but cannot guarantee that all bugs are found. Examples: Splint, Coverity CMC, Klocwork K7, Sound semantics-based / Abstract Interpretation-based Can guarantee that all bugs (from the class under analysis) are found. Results valid for every possible program execution with any possible input scenario. Examples: ait, StackAnalyzer, Polyspace Verifier, Astrée.

8 Aerospace: DO-178B / DO-178C Verification is not simply testing. Testing, in general, cannot show the absence of errors.

9 Automotive: ISO Criticality levels: A(lowest) to D (highest) Excerpt from: Final Draft ISO Road vehicles - Functional safety Part 6: Product development: Software Level. Version ISO/FDIS :2011(E), 2011.

10 Automotive: ISO Excerpt from: Final Draft ISO Road vehicles - Functional safety Part 6: Product development: Software Level. Version ISO/FDIS :2011(E), 2011.

11 E&E Systems: IEC Edition 2.0 Excerpt from: IEC-61508, Edition 2.0. Functional safety of electrical/electronic/programmable electronic safety-related systems Part 3: Software requirements

12 E&E Systems: IEC Edition 2.0 Criticality levels: SIL1 (lowest) to SIL4 (highest) Confidence levels:

13 Railway: EN Excerpt from: DRAFT pren 50128, July 2009

14 Worst-Case Execution Time Analysis Controllers in planes, cars, plants, are expected to finish their tasks within reliable time bounds. Schedulability analysis must be performed. Hence, it is essential that an upper bound on the execution times of all runnables/tasks is known. Commonly called the Worst-Case Execution Time (WCET).

15 16 Probability The Timing Problem Best-case execution time Exact worst-case execution time Execution time

16 17 Probability The Timing Problem Best-case execution time Unsafe: execution time measurement Exact worst-case execution time Execution time

17 18 Probability The Timing Problem Best-case execution time Unsafe: execution time measurement Safe worst-case execution time estimate Exact worst-case execution time Execution time

18 19 Probability The Timing Problem Unsafe: execution time measurement Safe worst-case execution time estimate Execution time

19 ait WCET Analyzer Internal Structure

20 ait WCET Analyzer Combines global static program analysis by Abstract Interpretation: microarchitecture analysis (caches, pipelines, ) + value analysis integer linear programming for path analysis to provide safe and precise bounds on the WCET. Application Code void Task (void) { variable++; function(); next++: if (next) do this; terminate() } Specifications (*.ais) clock khz ; loop "_codebook" + 1 loop exactly 16 end ; recursion "_fac" max 6; SNIPPET "printf" IS NOT ANALYZED AND TAKES MAX 333 CYCLES; flow "U_MOD" + 0xAC bytes / "U_MOD" + 0xC4 bytes is max 4; Entry Point area from 0x20 to 0x497 is read-only; Compiler Linker Executable (*.elf / *.out) à ;Þ Kÿÿô;ÿ KÿÿØ 2}Œ`øÿÿ (8H# é³ ( ait Worst Case Execution Time Visualization, Documentation

21 ait WCET Analyzer Advantages WCET results determined automatically Valid for all inputs and all execution scenarios No modification of your code or tool chain required Integration into development tool chain Application areas Timing verification Feedback for optimization Software integration Architecture exploration 22

22 Stack Usage In safety-critical embedded systems the Stack is typically the only dynamically managed memory The stack is used to store Local variables Intermediate values Function parameters Function return addresses Start of reserved stack space Usable stack space Stack frame of current function SP /Stack Pointer End of reserved stack space

23 Stack Usage Analysis Stack space has to be reserved at configuration time => maximal stack usage has to be known. Underestimating stack usage can cause stack overflows. Stack overflows are severe errors: they can cause wrong reactions and program crashes, they are hard to recognize, they are hard to reproduce and fix.

24 Testing is difficult A traditional approach Fill the stack area with a pattern (0xAAAA) Let the system run for a long time Monitor the maximum stack usage so far Error-prone and expensive! Typical stack usage of a task can be very different from maximum stack usage. Dynamic testing typically cannot guarantee that the worst case stack usage has been observed.

25 Solution: StackAnalyzer StackAnalyzer computes save upper bounds of the stack usage of the tasks in a program for all inputs Static program analysis based on Abstract Interpretation Executable (elf,coff, ) à ;ÞKÿ ÿô;ÿ KÿÿØ 2}Œ`øÿÿ (8H#é³ ( Function pointers, recursion depths, instruction "_main" + 1 computed calls "_fooa", "_foob", "_fooc"; routine "_fib" incarnates max 5; Entry Points StackAnalyzer Stack Usage Visualization Documentation

26 StackAnalyzer: Static Stack Usage Analysis StackAnalyzer is an Abstract Interpretation based static analyzer which calculates safe and precise upper bounds of the maximal stack usage of the tasks in the system. It can prove the absence of stack overflows: on binary code without code modification without debug information taking into account loops and recursions taking into account inline assembly and library function calls

27 StackAnalyzer Advantages Results are determined automatically, valid for all inputs and all execution scenarios. No modification of your code or tool chain required. Code is analyzed as executed in the final system. Stack optimization/software integration. Successfully used for certification according to DO178B/Level A. Available for various processor/compiler combinations

28 The Static Analyzer Astrée Crashes or undefined behavior due to runtime errors are bad and too many false alarms are bad. Astrée detects all runtime errors with few false alarms: Array index out of bounds Integer division by 0 Invalid pointer dereferences Arithmetic overflows and wrap-arounds Floating point overflows and invalid operations (IEEE floating values Inf and NaN) + User-defined assertions, unreachable code, uninitialized variables recommended: C programs without dynamic memory allocation and recursion ALARM: invalid dereference: dereferencing 1 byte(s) at offset(s) 10 may overflow the variable ArrayBlock of byte-size 10 at [ ]

29 Astrée Domains Interval domain, Octagon domain. Floating-point computations: #include <stdio.h> Control programs often perform massive int main () { double x; float a,y,z,r1,r2; floating-point computations. a = 1.0; x = ; Rounding errors have to be taken into y = x+a; z = x-a; account for precise analysis. r1 = y - z; r2 = 2*a; Astrée approximates expressions on printf("(x+a)-(x-a) = %f\n", r1); printf("2a = %f\n", r2); variables Vk as } [ a0, b0 ] + [ak, bk ] Vk k Rounding modes can be changed during runtime. Astrée considers worst-case of all possible rounding modes. Output: (x+a)-(x-a) = a = Astrée result: r1 in [ e+08, e+08] r2 = 2.0 Further value domains: Decision tree domain, Digital filter domain, Clock domain, Memory domain.

30 Alarm Analysis: Example

31 The Zero Alarm Goal With zero alarms, absence of runtime errors is automatically proven by the analysis run, without additional reasoning Design features of Astrée: Precise and extensible analysis engine, combining powerful abstract domains (intervals, octagons, filters, decision trees, ) Support for precise alarm investigation Source code views/editors for original/preprocessed code The more precise the analysis is, the fewer false alarms there are. Astrée supports improving precision by parametrization: local tuning of analysis precision making external knowledge available to Astrée specialization: adaptation to software class and target hardware

32 Other Isues in Safety Standards handled by Astrée Control flow analysis Data flow analysis Static code analysis Semantic code analysis Soon: Shared variables Soon: Coding rule checker (MISRA C)

33 Astrée Advantages Low number of false alarms by high analysis precision. Special support for real-time systems, digital filters, Floating-point rounding errors taken into account Efficient elimination of false alarms High analysis speed Local tuning of analysis precision Efficient support for alarm analysis (intuitive GUI, variable values per context, ) High reliability. No alarms shadowed (no "green follows orange ) Seamless integration into development environment Flexible licensing models Qualified tool support (CET) and analysis service

34 36 Esterel SCADE + ait/stackanalyzer Analysis Results (XML) SCADE-aiT coupling Traceabilit y File (XML) ait Generated C Code Cross Compiler External C Code Executable Code

35 37 GUI Integration

36 38 SCADE: Model-Level Feedback

37 39 dspace TargetLink + Astrée TargetLink Code Generator Analysis Results (XML) TargetLink-aiT Coupling Data Dictionary Astrée Generated C Code Integratio n C Code Preprocesso r Preprocesse d C Code

38 EmbeddedTester Coupling Analysis Results (XML) EmbeddedTester Simulink/TargetLink Model Information void wrapper(){ AutoGenerated Analysis Models EmbeddedTester Astrée while (1){ subsys_function(); } } ait TargetLink Auto-Code Information StackAnalyzer

39 41 Tool Coupling Advantages Automatic transfer of model-level information to implementationlevel tools Analysis results are conveniently accessible from the modeling level Direct feedback on the effect of design decisions on resource usage Automatic Verification Cost savings estimation during European IST research project INTEREST on real-life software for SCADE-aiT coupling. Main findings: SCADE-Workflow with ait coupling saves 2 days per KLOC In average, for a 19 KLOC SW, 40 days are saved, which represent 66% of the total effort in the classical approach.

40 The Confidence Argument Absence of hazards has to be shown with adequate confidence: the evidence provided can be trusted beyond reasonable doubt. Abstract Interpretation is a formal verification method enabling provably sound analyses to be designed. Reasoning strategy: 1. Soundness proof of mathematical analysis specification. 2. Automatic generation of analyzer implementation from mathematical specification, enabling high implementation quality. 3. Empirical validation of chosen abstraction, i.e., analysis model. 4. Qualification Support Kits: demonstrating implementation correctness in operational context of tool users. 5. Qualification Software Life Cycle Data reports: soundness of tool development and validation process.

41 Qualification Support Kits

42

43 Summary Current safety standards also require to demonstrate nonfunctional program properties. In all of them, variants of static analysis are recommended or highly recommended as a verification technique AI-based static analyzers for non-functional properties are increasingly used in industry and can be considered as the state of the art. ait Worst-Case Execution Time Analyzer StackAnalyzer runtime error analyzer Astrée They can easily be integrated into (model-based) development processes and can contribute to reducing the V&V effort

44