© 2009 grammatech, inc. all rights reserved grammatech, inc. 317 n aurora st. ithaca, ny 14850 tel:...

© 2009 GrammaTech, Inc. All rights reserved

GrammaTech, Inc.317 N Aurora St.Ithaca, NY 14850Tel: 607-273-7340E-mail: [email protected]

Safety-Critical Coding and Testing Trends

Presented by:

Paul Anderson

MAE UKNovember 10th, 2009


Outline

Introduction and Motivation Coding Standards for Safety Critical Development

› Rationale› Critiques of Coding Standards› Detection of Standards Violations

Advanced Static Analysis for Safety Critical Code Case Studies


Introduction and Motivation

High-confidence software is difficult to validate› Risk of failure is very high› Most software contains flaws

Two approaches› Use coding standards to streamline development› Use advanced static-analysis tools to find flaws early


Microsoft Zune Bug


Coding Standards

Address several practices› Layout

• “Spaces will not be used around ‘.’ or ‘->’, nor between unary operators and operands.” (JSF 63).

› Naming• “Different identifiers should be typographically unambiguous” (Misra C+

+ 2-10-1).

› Syntactic restrictions• “Brackets and parentheses in macros must be balanced” (JPL 8.2).

› Semantic guidelines• “Do not use dynamic memory allocation after initialization.” (JPL 3).

› Process• “Compile with all warnings enabled, and use source code analyzers”

(JPL 10).


Safety-critical Coding Standards

Misra C/C++ (Motor Industry Software Reliability Association)› Rules first introduced in 1998› Revised in 2004: 141 rules for C› Revised to cover C++ in 2008 (mostly derived from JSF rules): 228 rules› Widely used in motor vehicle industry› Some support in popular embedded compilers› Closed standard

JSF› Joint Strike Fighter Air Vehicle standards, introduced in 2005› 232 rules for C and C++, some based on Misra C› Not widely used yet due to low uptake of C++ for safety-critical› Open standard

EC› A subset of ISO C, introduced in 2003 by Les Hatton› Designed to be “measurement based”› Open standard


Safety-critical Coding Standards

Netrino Embedded C Coding Standard› Much overlap with Misra C, but more liberal› Rules biased towards enforcability› Closed standard

JPL “Power of 10”› Gerard Holzmann’s (of NASA Jet Propulsion Laboratory), introduced

in 2006› 23 distinct rules› Intended as a minimum set of the most important rules› Designed to leverage automation› Adopted by JPL for NASA codes› Open Standard


Rationale for Coding Rules

Clarity› Reduce programmer confusion› A construct may be perfectly unambiguous and well-defined, but

may make code difficult to read› “Do not use goto statements” (JPL 1.1)

Predictability› Eliminate sources of ambiguity› Helps with portability› “Do not use union types” (Misra C++ 9-5-1)

Simplicity› Keep the program simple› May help reduce the cost of testing› Keeps programs amenable to analysis› “No recursion” (JPL 1.2)


Rationale for Coding Rules

Defense› Encourage defensive programming› Fosters maintainability› “Switch statement shall be a well-formed switch statement” (Misra C++ 6-4-3)

Compliance› Standards compliance› Aids portability› “Use IEEE floating point formats” (Misra C++ 0-4-3)

Process› How code is developed, not about the code itself› “Compile with all warnings enabled, and use source code analyzers” (JPL 10)

Performance› Nothing to do with safety› “Trivial forwarding functions should be inlined” (JSF 124)


Critiques of Coding Standards

Too many rules Rules are ambiguous or otherwise poorly defined Enforcement may not improve quality

› Hatton argues that rules should only be specified where there is empirical evidence that violations are risky

› Fixing violations may inject faults, with probability p• p < 0.02 required to achieve higher quality for Misra C, but

• p = 0.15, as reported

› Conclusion based on analyzing code after completion

Poor support for automation Standards are closed


Critique of Critiques of Coding Standards

Too many rules› “Power of 10” is designed to be easy to recall

Rules are ambiguous or otherwise poorly defined› For many rules, consistency of interpretation is most important› Dogmatic interpretation may be counter productive

Enforcement may not improve quality› Enforcement helps quality by fostering good programming practices› Advanced static-analysis tools do help eliminate bugs

Poor support for automation› Tool support is improving

Standards are closed› “Power of 10” is open


JPL “Power of 10” rules

Easy for programmers to remember all rules Open standard Keeps code simple

› Easy for humans to understand› Easy for machines to manipulate and analyze

• Not just static analysis, but test-case generation etc.

Leverage automation as much as possible› Infeasible to manually scan for violations otherwise› Bias code towards analyzability

Rule 10: “Compile with all warnings enabled, and use source code analyzers”

› i.e., Advanced Static Analysis Tools


Advanced Static Analysis Testing

Finds serious flaws by examining the program source code› Leaks, Null pointer dereferences, Buffer overruns, Race conditions,

etc.› No execution, so no test cases are required

Uses symbolic execution to explore many paths through the program

Not guaranteed to find all bugs Low false positive rate Highly scalable (multiple MLOC) Extensible


JPL10: “Compile with all warnings enabled, and use source code analyzers

By “source-code analyzers”, read “advanced static analysis tools”

Fix all issues raised, even if they are technically false positives

› Because not doing so may mask real problems too› Train programmers to “write to the tool” by eliminating false positives

by rewriting the code

Helps the tool, simplifies the code


Properties of a Violation Detection Tool

Wide range of ability› Should be able to find violations of simple rules, as well as deep semantic violations

• Easier to “dumb down” than “smarten up”

› Many different technologies appropriate• Preprocessor, parser, control-flow analysis, data-flow, symbolic execution

Customizability› Easy mechanism for minor changes (e.g., N=20 to N=25)› Users should be able to adapt rules› Entirely new rules should be possible

Should cope with “extreme” environments› Language variants (there is no ANSI C)› Unusual build systems› Huge code bases› Pathological constructs

False positive management› Unavoidable in practice› Dismiss once, never be bothered again


Recommendations for Adoption of Coding Standards

Pick a coding standard and adopt it› Consider using JPL rules as the base

Use a wide-spectrum violation detection tool› Deploy this for regular scans and practice JPL rule 10

Be careful about interpreting rules› Use the rationale as a guide for rules with a subjective element

Allow exceptions› Discourage these for objective rules

Be consistent about enforcement Extend the tools for new rules

› As new flaws are found, derive a rule for how the code should have been written, and write a checker

Don’t neglect manual reviews, thorough testing, etc.


Conclusions

Safety-critical coding standards are becoming more popular› Despite doubts about the efficacy of requiring enforcement for

existing code› Wide consensus on use of such standards for new code› Keys to success are non-dogmatic consistency, and leverage of

automation

Advanced static analysis testing tools now best practice› For finding serious defects early in development process› For detecting violations of coding standards

Use of both yields maximum benefit› Symbiotic relationship developing between coding rules and tools

© 2009 GrammaTech, Inc. All rights reservedCopyright © GrammaTech, Inc. 2009Page 18

Case Study: LLNL

Lawrence Livermore National Laboratories› DoE-funded government research lab

Detailed study of 200 KLOC C/C++ program› 285 defects found using Klocwork

• 56 critical (null pointer dereferences, buffer overruns)• 14 severe (use of freed memory)• 193 errors (leaks, uninitialized variables)• 22 other warnings

› Estimated cost savings of $200,000• Based on $4,000 cost to fix if found during deployment vs $100 to fix early

Used advanced static-analysis tool on 1.9 MLOC› Over 3,000 defects found and repaired

Reference:› "Give Your Defects Some Static - Using Static Analyzers to Debug Your Code", Greg Pope, Kim Ferrari, and Bill

Oliver, Better Software, July 2008, Volume 10, Number 6, pp 36-42, StickyMinds.com, http://www.stickyminds.com/BetterSoftware/Magazine.asp.

© 2009 GrammaTech, Inc. All rights reservedCopyright © GrammaTech, Inc. 2009Page 19

Case Study: FDA

Software Forensics Lab at FDA› Studies software for medical devices, usually after harmful incident is reported

Case Study:› 200 KLOC C program for old device

• Used discontinued compiler. Build system had to be reconstructed.› Analyzed with CodeSonar

Results› 127 serious problems (736 reported in 16 classes)

• 29 unsafe casts• 28 null pointer dereferences• 36 uninitialized variables• 20 unreachable code• 14 other

› Manufacturer was previously aware of 82 of these› 45 were not previously known

References› "Flaws in medical coding can kill", Jonathan D.Rockoff, Baltimore Sun, June 30 2008,

http://www.baltimoresun.com/news/health/bal-te.fda30jun30,0,912831.story.› "Using Static Analysis to Evaluate Software in Medical Devices", Raoul Jetley and Paul Anderson, Embedded

Systems Design, April 2008, Volume 21, Number 4, pp 40-44, TechInsights, http://www.embedded.com/design/207000574.


References

Coding rules› Misra C: http://www.misra.org.uk/› JSF: http://www.research.att.com/~bs/JSF-AV-rules.pdf› JPL 10: http://www.spinroot.com/p10/› EC: http://www.leshatton.org/ISOC_subset1103.html› Netrino: http://www.netrino.com

Critiques› Les Hatton Misra C Critique:

http://www.leshatton.org/Documents/MISRA_comp_1105.pdf Tools

› CodeSonar: http://www.grammatech.com/products/codesonar Me

› Paul Anderson, [email protected]

http://www.misra.org.uk/



http://www.research.att.com/~bs/JSF-AV-rules.pdf


Backup slides


JPL “Power of 10”

1. Restrict to simple control flow constructs.

2. Give all loops a fixed upper-bound.

3. Do not use dynamic memory allocation after initialization.

4. Limit functions to no more than 60 lines of text.

5. Use minimally two assertions per function on average.

6. Declare data objects at the smallest possible level of scope.

7. Check the return value of non-void functions, and check the validity of function parameters.

8. Limit the use of the preprocessor to file inclusion and simple macros.

9. Limit the use of pointers. Use no more than one level of dereferencing.

10.Compile with all warnings enabled, and use source code analyzers.

See http://www.spinroot.com/p10/


Rule Interpretation: use Rationale

Clarity› Be flexible, as clarity is a very subjective issue. Foster consistency among developers

Compliance› Be flexible, but bear in mind future transition costs.

Defense› Be moderately flexible, but have good evidence that exceptions are justified.

Performance› Be very flexible, except where performance is required to enhance safety properties

Predictability› Strongly avoid compromising on predictability.

Process› Avoid violations of these rules, as following them offers the best return on investment

Simplicity› Be flexible, but bear in mind that compromise on these rules may impact testing costs.