Abstract Interpretation-based Static Analysis Tools:

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

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.

Background



_{Time drift in Patriot rockets in 1991 [Rounding error]}



_{Crash of railway switch controller 1995 in}

Hamburg-Altona [Stack overflow]



_{Explosion of Ariane rocket 1996 [Arithmetic overflow]}



_{AECL Medical Therac-25 incident (1985-1987)}

[Arithmetic overflow]

Functional Safety



_{Demonstration of}

_functional

_correctness

 _{Well-defined criteria}

 _{Automated and/or model-based testing}

 _{Formal techniques: model checking, theorem proving}



_{Satisfaction of}

_{non-functional}

_requirements

 _{No crashes due to runtime errors (Division by zero,}

invalid pointer accesses, overflow and rounding errors)

 _{Resource usage:}

 _{Timing requirements (e.g. WCET, WCRT)}

 _{Memory requirements (e.g. no stack overflow)}

 _{Insufficient: Tests & Measurements}

 _{Test end criteria unclear}

 _{No full coverage possible}

 _{"Testing, in general, cannot show the absence of errors." [DO-178B]}

4

Required by

DO-178B / DO-178C /

ISO-26262, EN-50128,

IEC-61508

Required by

DO-178B / DO-178C /

ISO-26262, EN-50128,

IEC-61508

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

Key Products:

AI-based Static Analyzers

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.} 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

Aerospace: DO-178B / DO-178C



_{“Verification is not simply testing. Testing, in general, cannot}

show the absence of errors.”

Automotive: ISO-26262

Final Draft ISO 26262-6 Road vehicles - Functional safety – Part 6: Product development: Software Level.

Automotive: ISO-26262

11

Excerpt from:

Final Draft ISO 26262-6 Road vehicles - Functional safety – Part 6: Product development: Software Level.

E&E Systems: IEC-61508 – Edition

2.0

12

Excerpt from:

IEC-61508, Edition 2.0. Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 3: Software requirements

E&E Systems: IEC-61508 – Edition

2.0

Railway: EN-50128

14

Excerpt from:

DRAFT prEN 50128, July 2009

15



_{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)

.

16

The Timing Problem

Pr o b a b ili ty Execution time Exact worst-case execution time Best-case execution time

17

The Timing Problem

Pr o b a b ili ty Execution time Exact worst-case execution time Best-case execution time Unsafe: execution time measurement

18

The Timing Problem

Pr o b a b ili ty Execution time Exact worst-case execution time Safe worst-case execution time estimate Best-case execution time Unsafe: execution time measurement

19

The Timing Problem

Pr o b a b ili ty Execution time Safe worst-case execution time estimate Unsafe: execution time measurement

aiT WCET Analyzer Internal

Structure

21

clock 10200 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; area from 0x20 to 0x497 is read-only;

Specifications (*.ais)

Entry Point

 _{Worst Case Execution Time}  Visualization, Documentation

aiT

void Task (void) { variable++; function(); next++: if (next) do this; terminate() } Application Code Executable (*.elf / *.out) à =€@€ aŒ† | @€,@€;Þ Kÿÿô;ÿ Kÿÿ؉ €2}Œ`øÿÿ ™ €(8H# 鳡 ¶ €(  Compiler Linker

aiT WCET Analyzer

Combines



_{global static program analysis}

_by

_Abs

_tract

_Int

_erpretation

_:

microarchitecture

analysis (caches, pipelines, …) +

value

analysis



_{integer linear programming for}

_{path analysis}

22

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}

23 End of reserved stack space Start of reserved stack space Stack frame of current function Usable stack space SP /Stack Pointer



_{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}

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.}

25



_{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.

26

instruction "_main" + 1 computed calls "_fooA", "_fooB", "_fooC";

routine "_fib"incarnates max 5;

Function pointers, recursion depths, …

Entry Points  Stack Usage  Visualization  Documentation Executable (elf,coff,…) à =€@€ aŒ† | @€,@€;ÞKÿ ÿô;ÿ KÿÿØ ‰ €2}Œ`øÿÿ™ €(8H#鳡 ¶  €( 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

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

28



_{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}

DO-178B/Level A.



_{Available for various processor/compiler combinations}

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

29

ALARM: invalid dereference:

dereferencing 1 byte(s) at offset(s) 10 may overflow the variable ArrayBlock of byte-size 10 at […]

Astrée Domains



_{Interval domain, Octagon domain.}



_{Floating-point computations:}

 _{Control programs often perform massive}

floating-point computations.

 _{Rounding errors have to be taken into}

account for precise analysis.

 _{Astrée approximates expressions on}

variables Vk as

 _{Rounding modes can be changed}

during runtime.

 _{Astrée considers worst-case of all}

possible rounding modes.



_{Further value domains: Decision tree domain, Digital filter}

domain, Clock domain, Memory domain.

30

#include <stdio.h> int main () {

double x; float a,y,z,r1,r2;

a = 1.0; x = 1125899973951488.0; y = x+a; z = x-a; r1 = y - z; r2 = 2*a; printf("(x+a)-(x-a) = %f\n", r1); printf("2a = %f\n", r2); } Output: (x+a)-(x-a) = 134217728.0000 2a = 2.0000 Astrée result: r1 in [-1.34218e+08, 1.34218e+08] r2 = 2.0

∑

Alarm Analysis: Example

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}

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)}

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}

36 SCADE-aiT coupling Cross Compiler Generated C Code Traceabilit y File (XML) External C Code Executable Code Analysis Results (XML)

Esterel SCADE + aiT/StackAnalyzer

37

38

39 TargetLink-aiT Coupling Preprocesso r Generated C Code Integratio n C Code Preprocesse d C Code

dspace TargetLink + Astrée

Data Dictionary Analysis Results (XML) TargetLink Code Generator Astrée

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

EmbeddedTester Coupling

41



_{Automatic transfer}

_of

_model-level

_{information to}

implementation-level

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.

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.

Qualification Support Kits

Summary



_Current

_{safety standards}

_{also require to demonstrate}

non-functional 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

46

email: [email protected] http://www.absint.com