From HIS 2019

1. MISRA C: How to achieve ISO 26262 Compliance
Presented by
Andrew Banks
(Andrew.Banks@LDRA.com)
High Integrity Software 2019
Bristol, 5th November 2019

2. Agenda
2
MISRA C – A quick history
MISRA C in an ISO 26262 context
Cybersecurity & Autonomy
1
2
3
4
5
MISRA C in a little bit more detail
Achieving MISRA C compliance

3. LDRA Overview
Provider of Software Quality, Compliance
Management & Testing Solutions
Established 1975
ISO 9001 certified company
Certified for use in safety related software
development according to IEC 61508, EN
50128, ISO 26262, IEC 62304 & IEC 60880
Active participants in standards e.g.
DO-178C, MISRA C/C++, CERT
3

4. Experts in Safety and Security Critical
Software
Aerospace Defence Medical
Industrial
& Energy
Rail
Transportation Automotive
4

5. The LDRA tool suite® Solution
5
Visualisation of Standards
Compliance, Quality
Metrics & Code Coverage
Collaborative
Test
Management,
Requirements
Traceability
& Verification
Workflow
Host & Target
Unit/Integration
Test
Core Static and Dynamic Analysis Engine
Plug-ins for:
Eclipse, Visual
Studio, MPLABX,
Rhapsody…
TBmanager®
TBvision®
TBrun®
LDRA
Testbed®
C/C++, Java, Ada83/Ada95
& Assemblers

6. MISRA C
... A quick history
1

7. ▪ K&R C
▪ 1972 First created by Dennis Ritchie
▪ 1976 Lint, the first C static analyser, created by Stephen Johnson
▪ 1978 The C Programming Language published
▪ ANSI C
▪ 1989 ANSI X3.159-1989 aka C89 First standardized version
▪ ISO C
▪ 1990 ISO/IEC 9899:1990 aka C90 Equivalent to C89
▪ 1995 Amendment 1 aka C95
▪ 1999 ISO/IEC 9899:1999 aka C99
▪ 2011 ISO/IEC 9899:2011 aka C11
▪ 2018 ISO/IEC 9899:2018 aka C18 A “TC” in all but name
▪ Very few (if any) of you will be using ANSI C any more!
The C Language – A Quick History
7

8. ▪Despite its popularity, there are several drawbacks with
the C language, eg:
▪ The ISO Standard language definition is incomplete
▪ Behaviour that is Undefined
▪ Behaviour that is Unspecified
▪ Behaviour that is Implementation Defined
▪ Language misuse and obfuscation
▪ Language misunderstanding
▪ Run-time error checking
▪MISRA C is one solution...
MISRA C – The Rationale
8

9. ▪ November 1994: Development guidelines for vehicle based
software (aka The MISRA Guidelines)
▪ The first automotive publication concerning functional safety
▪ Commenced more than 10 years before work started on ISO
26262
▪ April 1998: Guidelines for the use of the C language in
vehicle based software (MISRA C)
▪ December 1998: IEC 61508 (first edition) published!
Original MISRA publications
9

10. ▪ MISRA-C:1998
▪ “Guidelines for the use of the C language
in vehicle based software”
▪ Compatible with ISO/IEC 9899:1990
(aka C90)
▪ MISRA-C:2004
▪ “Guidelines for the use of the C language
in critical systems”
▪ Remains compatible with ISO/IEC
9899:1990 (aka C90)
▪ MISRA C:2012 (3rd Edition)
▪ Adds compatibility with
ISO/IEC 9899:1999 (aka C99)
▪ Updated to 1st Revision in 2019 to include
AMD1 and TC1
MISRA C – A Quick History
10

11. MISRA C in an
... ISO 26262 context
2

12. ISO 26262-6:2018, section 5.4.3
▪Criteria for suitable modelling, design or
programming languages that are not sufficiently
addressed by the language itself shall be covered
by the corresponding guidelines, or by the
development environment, considering the topics
listed in Table 1
▪Example 1: MISRA C is a coding guideline for the
programming language C and includes guidance
on automatically generated code
MISRA C – In an ISO 26262 Context
12

13. ISO 26262-6:2018, Table 1
MISRA C – In an ISO 26262 Context
13

14. ▪ISO 26262-6:2018, section 8.4.5
▪Design principles for software unit design and
implementation at the source code level as listed
in Table 6 shall be applied to achieve the following
properties:
▪ correct order of execution of subprograms and functions within the
software units, based on the software architectural design;
▪ consistency of the interfaces between the software units;
▪ correctness of data flow and control flow between and within the
software units;
▪ simplicity;
▪ readability and comprehensibility;
▪ robustness;
▪ suitability for software modification; and
▪ verifiability
MISRA C – In an ISO 26262 Context
14

15. ISO 26262-6:2018, Table 6
MISRA C – In an ISO 26262 Context
15

16. Static Analysis, control flow analysis and data flow
analysis are mentioned twice as a set:
▪Table 7 ... software unit verification
▪Table 10 ... verification of software integration
Control flow analysis and data flow analysis are also
mentioned in Table 4:
▪Table 4 ... verification of software architectural design
MISRA C – In an ISO 26262 Context
16

17. ISO 26262-6:2018, Table 7 (unit)
MISRA C – In an ISO 26262 Context
17

18. ISO 26262-6:2018, Table 10
This also maps to the MISRA C guideline scope:
▪Unit Verification Single-translation-unit guidelines
▪Integration System-wide guidelines
MISRA C – In an ISO 26262 Context
18

19. MISRA C...
... in a little bit more detail
3

20. ISO 26262-6:2018, Table 1
MISRA C – In an ISO 26262 Context
20

21. ▪1a) Enforcement of low complexity
▪MISRA C deliberately avoids the topic of measurement,
other than suggesting you need to do it!
▪MISRA Report 5 “Software Metrics” (February 1995)
offers good advice!
Table 1
21

22. ▪Keep it simple
▪ Keep the design as simple and small as possible.
▪ Complex designs increase the likelihood that errors will be
made in their implementation, configuration, and use
Enforce Low Complexity
22

23. Enforce Low Complexity
23
Impossible to understand, maintain or test

24. ▪Treat Code Complexity with caution...
For example a switch() construct has a
high calculated complexity!
Enforce Low Complexity
24

25. ▪1b) Use of a language subset
▪The MISRA C Vision
▪ The MISRA C Guidelines define a subset of the C language in
which the opportunity to make mistakes is either removed or
reduced.
▪ Many standards for the development of safety-related software
require, or recommend, the use of a language subset, and this
can also be used to develop any application with security, high
integrity or high reliability requirements.
Table 1
25

26. ▪1c) Use of strong typing
▪Section 8.10 “The Essential Type Model”
▪ The rules in this section collectively define the essential type
model and restrict the C type system so as to:
1. Support a stronger system of type-checking;
2. Provide a rational basis for defining rules to control the
use of implicit and explicit type conversions;
3. Promote portable coding practices;
4. Address some of the type conversion anomalies found
within ISO C.
▪ The essential type model does this by allocating an essential
type to those objects and expressions which ISO C considers to
be of arithmetic type. For example, adding an int to a char gives
a result having essentially character type rather than the int
type that is actually produced by integer promotion.
Table 1
26

27. ▪1d) Use of defensive implementation techniques
▪MISRA C has guidance relating to:
▪ Control flow
▪ If / else if / else
▪ Switch / default
▪ While / do
▪ For loops
▪ Unreachable code
▪ The shall be no unreachable code
▪ There shall be no unused code
Table 1
27

28. ▪Consider the Required MISRA C:2012 Rule 2.1
▪ A project shall not contain unreachable code
▪Consider the Required MISRA C:2012 Rule 15.6
▪ The body of an iteration-statement or a selection-statement
shall be a compound-statement. eg:
if ( condition )
{
action();
}
▪Some suggest that these Rules are (to be polite)
unnecessary
▪I wonder if Apple’s software team agree?
▪ CVE-2014-1266
Defensive Implementation Techniques
28

29. The Apple iPhone SSL Bug
29
if ( ( err = SSLFreeBuffer( &hashCtx ) ) != 0 )
goto fail;
if ( ( err = ReadyHash(&SSLHashSHA1, &hashCtx ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.update( &hashCtx, &clientRandom ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.update( &hashCtx, &serverRandom ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.final( &hashCtx, &hashOut ) ) != 0 )
goto fail;

30. The Apple iPhone SSL Bug
30
if ( ( err = SSLFreeBuffer( &hashCtx ) ) != 0 )
goto fail;
if ( ( err = ReadyHash(&SSLHashSHA1, &hashCtx ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.update( &hashCtx, &clientRandom ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.update( &hashCtx, &serverRandom ) ) != 0 )
goto fail;
if ( (err = SSLHashSHA1.update( &hashCtx, &signedParams ) ) != 0 )
goto fail;
goto fail;
if ( ( err = SSLHashSHA1.final( &hashCtx, &hashOut ) ) != 0 )
goto fail;
 Now unconditional
 Now unreachable!

31. The Apple iPhone SSL Bug
31
if ( ( err = SSLFreeBuffer( &hashCtx ) ) != 0 )
goto fail;
if ( ( err = ReadyHash(&SSLHashSHA1, &hashCtx ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.update( &hashCtx, &clientRandom ) ) != 0 )
goto fail;
if ( ( err = SSLHashSHA1.update( &hashCtx, &serverRandom ) ) != 0 )
goto fail;
if ( (err = SSLHashSHA1.update( &hashCtx, &signedParams ) ) != 0 )
{  would this have helped?
goto fail;
goto fail;
}  not forgetting this one...
if ( ( err = SSLHashSHA1.final( &hashCtx, &hashOut ) ) != 0 )
goto fail;
 Now unreachable!
 Now reachable!

32. ISO 26262-6:2018, Table 6
MISRA C – In an ISO 26262 Context
32

33. ▪1a) One entry and one exit point
▪MISRA C Rule 15.5 (Advisory)
▪ Justification cites IEC 61508 and ISO 26262
▪A single entry point is a given in a structured
language...
▪Lots of debate as to the usefulness of the single exit
point requirement; often (eg error trapping) early
returns can make for simpler (and hence more
maintainable) code
Table 6
33

34. ▪ 1b) No dynamic objects
▪ MISRA C Directive 4.12 (Required) plus several Rules
▪ The C standard library dynamic memory functions are poorly
defined
▪ Error handling if allocation fails is a common cause of a
software “crash” (ie null pointer returned)
▪ Restriction in C++ harder to enforce due to automatic
allocations.......
▪ Note: JSF AV Coding Guidelines permit dynamic allocation
during program start-up
Table 6
34

35. ▪1c) Initialization of variables
▪MISRA C Rule 8.9 (Mandatory)
▪The C Standard requires “static” variables to be
initialised to zero (unless otherwise explicitly initialised)
▪However “automatic” variables are not initialized and
this have indeterminant values.
▪But is a default value of zero correct?
Table 6
35

36. MISRA Compliance
4

37. ▪MISRA has always included
guidance related to compliance
▪ Previously, this has been included
in the introductory chapters
▪ Going forward, this important
guidance now has its own
document
▪ The guidance has always made it
clear what must be done when
using and claiming compliance
with the Guidelines, but there
were some misconceptions and
the guidance has been known to
be ignored or adopted selectively
MISRA Compliance:2016
37

38. ▪Available as a standalone
document
(click for free download)
▪Compatible with MISRA C:2012
(and any future versions)
▪Compatible with forthcoming
MISRA C++:20xx
▪No reason it cannot be applied to
earlier versions of either
document!
MISRA Compliance
38

39. ▪Clearer definition of what is meant by MISRA
Compliance
▪ and how Compliance should be demonstrated
▪Provides a mechanism for tailoring classification of the
guidelines
▪ introduces the Guideline Recategorization Plan
▪Provides guidance on dealing with adopted code
▪Clarifies/tightens the Deviation process
▪Provides a mechanism for establishing pre-approved
Permits
MISRA Compliance
39

40. ▪MISRA Compliance is NOT
▪ claimed for an organisation ... but only for a deliverable item
▪ applicable to the software ... but to the development
lifecycle
▪MISRA Compliance does NOT mean
▪ No deviations ... but no unresolved violations
▪MISRA Compliance is achieved when
▪ development of a software item has been conducted in
accordance with the processes and principles specified in the
Guidelines
▪ all violations are accepted by means of a deviation, or are
against advisory guidelines and are documented as being
considered acceptable.
MISRA Compliance
40

41. ▪What is Adopted Code?
▪ Code developed outside of the current project
▪ May or may not have been developed to comply with the
Guidelines
▪ Source code or binary/library that is adopted unchanged
▪Examples include:
▪ The Standard Library
▪ Device driver files
▪ Third-party libraries
▪ Auto-generated code
▪ Legacy code
▪Note: Source code that is revised or modified in any
way, within the project, is no longer considered adopted
code
MISRA C – Adopted Code
41

42. ▪Sometimes a violation may be justified
▪ A deviation is an appropriate way of handling such a violation
▪ Legitimate reasons may be
▪ Code quality See ISO/IEC 25010 “SQuaRE”
▪ Access to hardware
▪ Adopted code integration
▪ Non-compliant adopted code
▪A deviation should not merely document the existence of
a violation
▪A deviation should
▪ document the reason why it is required
▪ be targeted in scope and specify any necessary precautions
▪ be subject to approval by a defined process
MISRA C – Deviations
42

43. ▪Check the code manually
▪ Needs to be done on MISRA C:2012 “undecidable” rules
▪ But don’t really want to do it on all the code!
▪Use a lightweight tool, such as is often built into
compilers
▪ Fast (Checks just a subset)
▪ Detects the easy to find defects
▪ Tends to be “Optimistic” – False Negatives
▪Use a heavyweight tool
▪ Slow (Deep analysis, Check all rules)
▪ Detects the easy and hard to find defects
(The ones that occur once a year!)
▪ Tends to be “Pessimistic” – False Positives
Checking Compliance
43

44. ▪Summary:
▪ MISRA Compliance is achieved when development of a
software item has been conducted in accordance with the
processes and principles specified in the Guidelines
▪Evidence:
▪ Guideline Recategorization Plan (if applicable)
▪ Guideline Enforcement Plan
▪ Guideline Compliance Summary
▪ Deviation Records covering all violations of Required guidelines
▪Note:
▪ Items 1, 2 and 3 can be combined into a single spreadsheet
MISRA Compliance – Claiming Compliance
44

45. Cybersecurity &
Autonomy
5

46. ISO/SAE JWG + ISO/TC22/SC32/WG11

47. 1. Applicable to road-vehicles
2. Goal of reasonably secure vehicles and systems
3. Management activities for cybersecurity
4. Automakers and suppliers can use to show “due
diligence”
5. Focus on automotive cybersecurity engineering
6. Based on current state-of-the-art for cybersecurity
engineering
7. Risk-oriented approach
8. Cybersecurity activities/processes for all phases of
vehicle lifecycle
ISO/SAE 21434 – Key Principles
47

48. Applicable to:
▪ The Road Vehicle,
▪ Its systems, sub-systems, and components
▪ The software installed
▪ Its connection from the vehicle to any external device/network.
Is designed to be compatible with ISO 26262
ISO/SAE 21434 – Scope
48

49. What about autonomy?
• Many initiatives under way
• ISO/IEC
• BSI
• SCSC
• etc etc

50. In Summary
6

51. ▪MISRA C is
▪ widely respected as a safety-related coding standard
▪ equally applicable as a security-related coding standard
▪ appropriate for use in all high-integrity and high-reliability
environments
▪MISRA C has
▪ evolved from an automotive standard into a pan-industry
standard
▪ but has specific applicability to the automotive industry in
general
... and ISO 26262 in particular
▪MISRA C will
▪ continue to evolve as new editions of the C standard are
produced
▪ seek to address other constraints as they become identified
MISRA C – In Summary
51

52. Q A&
Any Questions
52

53. .com
Need more information?
info@ldra.com
Contact Us
53

54. ▪Biography
▪ Over 30 years experience in developing real-time embedded software
systems, across a number of industries
▪ Chartered Fellow of the British Computer Society
▪ Member of the Institution of Engineering & Technology
... Member of the System Safety TPN Executive
▪ Technical Specialist / Field Application Engineer, LDRA
▪Standards
▪ Chairman of MISRA C Working Group since June 2013...
... Working Group member since 2007
▪ Chairman of the BSI Software Testing Working Group
▪ Contributor to ISO/IEC JTC1/SC7 and WG26
▪ Contributor to ISO 29119 “Software Testing”
▪ Contributor to ISO 26262 2nd Edition “Functional Safety”
▪ etc
About the speaker
54
@AndrewBanks
AndrewBanks