Andrew Banks BSc IEng MIET FBCS CITP Frazer-Nash Research Limited, and Chairman, MISRA C Working Group

1. MISRA C –
Recent developments and a road map
to the future
Andrew Banks
BSc IEng MIET FBCS CITP
Frazer-Nash Research Limited, and
Chairman, MISRA C Working Group

2. Agenda
1. Introduction
a. A Quick History
... and busting two myths
b. Safety v Security
2. Recent Publications
a. MISRA Compliance
b. Additional Security Guidelines
3. Current Activity and Road Map
October 26, 20162

3. MISRA C – A Quick History
From the beginning, to MISRA C:2012
(See “Additional Material”)

4. Myth Busting #1
The Misunderstanding
- MISRA C is only applicable to the automotive industry
The History
- MISRA C was originated by the automotive industry, for the automotive
industry... and we are proud of our automotive heritage.
The Reality
- MISRA C is applicable to any industry that requires high-integrity software
- MISRA C has been adopted by many industries, including medical, rail,
aerospace, space and defence. eg:
• http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
• http://www.stroustrup.com/JSF-AV-rules.pdf
October 26, 20164

5. Myth Busting #2
The Misunderstanding
- MISRA C is only a safety coding standard, not a secure/security one
The History
- MISRA C:2012 suggests (in its vision) its use in safety-related software
The Reality
- MISRA C also suggests (in its vision) its applicability to any application
with high integrity or high reliability requirements
- Unfortunately, a perception remains...
October 26, 20165

6. MISRA C – Safety v Security
Or do we just mean “High Integrity”?

7. Safety v Security
The difference between safety and security are largely semantic... especially
at the software level
Depending on the language they are talking, it might even appear that they
seem being divided by a common language.
- German Sicherheit v Sicherheit
- Spanish Seguridad v Seguridad
- French Sécurité v Sécurité
- Italian Sicurezza v Sicurezza
October 26, 20167

8. MISRA C – The Vision
The vision of MISRA C is set out in the opening paragraph of the
Guidelines:
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 high integrity or high
reliability requirements.
But don’t just take my word for it...
October 26, 20168

9. ISO/IEC TS 17961 – C Secure Coding Rules
Produced by ISO/IEC JTC 1/SC 22/WG 14 – the same people responsible for
the C standard itself
Originally proposed to be based on CERT-C but significantly rationalised
From the document’s Background:
- “In practice, security-critical and safety-critical code
have the same requirements”
October 26, 20169

10. Safety v Security v High Integrity
Secure System
- Prevents risks to privacy
- Considers only malicious actions
- No requirement for Safety...
- Garbage in, Garbage Out
Safety Critical System
- Prevents risks to human lives and/or the environment
- Considers well-intentions (and accidental!) actions also
- Inherently requires a level of Security
High-Integrity and/or High-Reliability System
- A system that must be trusted to work dependably
- Unacceptable loss or harm may result otherwise.
October 26, 201610

11. MISRA C – Recent Developments (1)
Updates for improved Compliance

12. MISRA Compliance
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!
October 26, 201612

13. MISRA Compliance
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
October 26, 201613

14. MISRA Compliance
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.
October 26, 201614

15. MISRA C – Guideline Categorization
Three levels
- Mandatory
o Guidelines for which a violation is never permitted
- Required
o Guidelines which can only be violated when supported by a deviation
- Advisory
o Recommendations to be followed as far as is reasonably practicable
o Violations are identified but do not required a deviation
The methods planned to be used to provide enforcement of each Guideline
shall be documented in a Guideline Enforcement Plan
The compliance level claimed by the project shall be documented in a
Guideline Compliance Summary
October 26, 201615

16. MISRA Compliance – Guideline Recategorization
Guidelines may be reclassified, depending on their base level
- Mandatory
o May not be reclassified
- Required
o May be reclassified to Mandatory
- Advisory
o May be reclassified up to Mandatory or Required
o May be Disapplied
Introduces a new Category of Disapplied
o No checks performed... violations may be ignored
Documented in a Guideline Recategorization Plan
- Usually agreed between Acquirer and Supplier at the project outset
October 26, 201616

17. MISRA C – Adopted Code
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
October 26, 201617

18. MISRA C – Deviations
Sometimes a violation may be justified
- A deviation is an appropriate way of handling such a violation
- Legitimate reasons may be
o Code quality See ISO/IEC 25010
o Access to hardware
o Adopted code integration
o 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
October 26, 201618

19. MISRA Compliance – Claiming Compliance
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) } Probably
- Guideline Enforcement Plan } a single
- Guideline Compliance Summary } document!
- Deviation Records covering all violations of Required guidelines
October 26, 201619

20. MISRA C – Recent Developments (2)
Additional guidance for Security

21. MISRA C – Additional Security Guidelines
Publication timeline met, as outlined at VDA Automotive SYS 2015...
MISRA C:2012 Addendum 2 (free download)
- Provides a matrix showing coverage of MISRA C:2012 against
ISO/IEC TS 17961:2013 C Secure
- Demonstrates that MISRA C:2012 can justifiably claim to be a Security
standard as well as a Safety Critical one!
MISRA C:2012 Amendment 1 (free download)
- Introduces an additional 14 targeted guidelines
o 13 new Rules
o 1 new Directive
- Incremental update to MISRA C:2012
October 26, 201621

22. MISRA C:2012 Amendment 1
New Guidelines
- Validation of external data 1G
- Use of sizeof() on a function parameter of array type 1M
- <ctype.h> functions 1M
- <stdlib.h> memory comparison functions 3R
- <stdlib.h> environment functions 2M
- <string.h> string-handling functions 2M
- <stdio.h> I/O functions – handling of EOF 1R
- <error.h> handling of errno 3R
October 26, 201622

23. ISO/IEC TS 17961 – C Secure Coding Coverage
Coverage Method #1 #2 Comments
MISRA covers fully – explicitly 22 35 Some rules stricter than Csecure
MISRA covers fully – implicitly 7 3
MISRA covers fully – broad 11 8 Eg: bans dynamic memory, signal.h
MISRA covers partially – broad 2 0 getenv() and related functions
MISRA does not cover directly 4 0 sizeof(pointer), padding
46 46
October 26, 201623
#1 MISRA C:2012 as published
#2 incorporating Amendment 1

24. MISRA C – Recent Developments (3)
Comparison with CERT-C

25. CERT-C – Secure Coding Standard
What is CERT-C
- Produced by the Software Engineering Institute (SEI) at Carnegie Mellon
University.
- Sponsored by the U.S. Department of Defense
- Originally proposed to be adopted as an ISO standard, but this was not
progressed by WG14, who progressed a subset as ISO/IEC TS 17961
instead.
The MISRA C Position
- We view CERT-C as complementary to MISRA C
o Most rules align with the MISRA C rules
o Some small variance due to difference of focus (not just safety v security)
o In particular, CERT-C considers the interface to the environment in hosted
applications
- Publication of comparison matrix imminent.
October 26, 201625

26. MISRA C comparison to CERT-C
Coverage Method #1 #2 Comments
C11 functions out of scope 15 16 Align, threads and atomics
MISRA covers fully – explicitly 41 42 Some MC rules stricter than CERT
MISRA covers fully – implicitly 18 18
MISRA covers fully – restrictive 22 21 Eg: bans dynamic memory, signal.h
MISRA does not cover directly 2 2 rand()
98 99
October 26, 201626
MISRA C:2012 incorporating Amendment 1 against:
#1 CERT-C 2nd edition as published
#2 CERT-C PDF released 30th June 2017 (adds 2 Rules, deletes 1)

27. MISRA C – Recent Developments (4)
Technical Corrigendum 1

28. MISRA C – Work In Progress
MISRA C:2012 Technical Corrigendum 1
- Address typographical errors and guideline clarification
- Publication (as a PDF download) imminent
October 26, 201628

29. MISRA C Road Map
From MISRA C:2012 to MISRA C:201x
... and then into the future

30. MISRA C roadmap
March 201630
MISRA
C:2012
MISRA C:2012
coverage
against ISO/IEC
17961:2013
MISRA C:2012
AMD1
“Security”
MISRA C:2012
TC1
MISRA
Compliance
MISRA
C:201x
ISO/IEC 17961
review
User feedback
Embody
JAMA ADC etc. Consequential
amendments
(editorial only?)
Published
in 2013
Published
in 2016
Consolidate

31. MISRA C – Future Work
Planned Way Ahead
- Consider additional rules and/or rule revisions to address:
o issues in the new features introduced by C11
o issues in accessing the operating environment, within hosted programs
o issues in using the Standard Library (see Extra Material at the end)
- Continue the review activity against
o CERT-C
o Common Weakness Enumeration
o ... and any other sources that may become known
The MISRA C Working Group welcomes feedback from all users
October 26, 201631

32. What about C:11
MISRA C Working Group has commenced a review of the deltas:
- Atomic primitives
- Multi-threading
- Unicode characters
- Appendix F/G – ISO/IEC 60559 floating point
- Appendix K – new bounds-checking functions should allow some existing
rules to be revised, with pre-C11 “unsecure” functions deprecated.
However, though, it is possible that this section may be deleted from the
standard!
- Appendix L – Analyzability
We propose to create an update to the Guidelines to address undesirable
behaviours.
More information in due course...
October 26, 201632

33. In Summary
October 26, 201633

34. MISRA C – In Summary
MISRA C is
- widely respected as a safety-related coding standard
- equally applicable as a security-related coding standard
MISRA C has
- evolved from an automotive standard into a pan-industry standard
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 welcomes
- feedback from the user community
- approaches from prospective Working Group members
October 26, 201634

35. Any Questions?
October 26, 201635

36. Thank You!
I would like to acknowledge the support of the members of the MISRA C Working Group for their
assistance in preparing this presentation.
October 26, 201636

37. About the speaker
Biography
- Chairman of MISRA-C since June 2013...
... working group member since 2007
- Over 25 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
Social Media
AndrewBanks.com
@AndrewBanks
https://linkedin.com/in/AndrewBanks
October 26, 201637

38. Extra Material
October 26, 201638

39. MISRA C – A Quick History
From the beginning, to MISRA C:2012

40. The C Language – A Quick History
K&R C
- 1972 First created by Dennis Ritchie
- 1976 First C static analyser (link) 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
Very few (if any) of you will be using ANSI C any more!
October 26, 201640

41. The C Language – The Problems
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
WG14 will not address these problems:
• “The standard is not considered to be broken” [WG14 N444]
October 26, 201641

42. The C Language – The Options
There are a number of solutions:
Use a different language...
• Ada or a derivative: eg SPARK or AdaCore
Adopt C language Guidelines
• ISO/IEC 17961 “C Secure”
• CERT-C
• MISRA C
• etc
October 26, 201642

43. Original MISRA publications
November 1994: Development guidelines for vehicle based software (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)
October 26, 201643

44. MISRA C - A brief history
MISRA-C:1998 (aka MISRA-C1)
- “Guidelines for the use of the C
language in vehicle based software”
- Compatible with ISO/IEC 9899:1990
(aka C90)
MISRA-C:2004 (aka MISRA-C2)
- “Guidelines for the use of the C
language in critical systems”
- Remains compatible with
ISO/IEC 9899:1990 (aka C90)
MISRA C:2012 (aka MISRA-C3)
- Adds compatibility with
ISO/IEC 9899:1999 (aka C99)
October 26, 201644

45. MISRA-C – The Vision
The vision of MISRA C is set out in the opening paragraph of the
Guidelines:
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 high integrity or high
reliability requirements.
October 26, 201645

46. MISRA C – A Quick History
From the beginning, to MISRA C:2012

47. The C Language – A Quick History
K&R C
- 1972 First created by Dennis Ritchie
- 1976 First C static analyser (link) 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
Very few (if any) of you will be using ANSI C any more!
October 26, 201647

48. The C Language – The Problems
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
WG14 will not address these problems:
• “The standard is not considered to be broken” [WG14 N444]
October 26, 201648

49. The C Language – The Options
There are a number of solutions:
Use a different language...
• Ada or a derivative: eg SPARK or AdaCore
Adopt C language Guidelines
• ISO/IEC 17961 “C Secure”
• CERT-C
• MISRA C
• etc
October 26, 201649

50. Original MISRA publications
November 1994: Development guidelines for vehicle based software (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)
October 26, 201650

51. MISRA C - A brief history
MISRA-C:1998 (aka MISRA-C1)
- “Guidelines for the use of the C
language in vehicle based software”
- Compatible with ISO/IEC 9899:1990
(aka C90)
MISRA-C:2004 (aka MISRA-C2)
- “Guidelines for the use of the C
language in critical systems”
- Remains compatible with
ISO/IEC 9899:1990 (aka C90)
MISRA C:2012 (aka MISRA-C3)
- Adds compatibility with
ISO/IEC 9899:1999 (aka C99)
October 26, 201651

52. MISRA-C – The Vision
The vision of MISRA C is set out in the opening paragraph of the
Guidelines:
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 high integrity or high
reliability requirements.
October 26, 201652

53. MISRA C – Standards Conformance
Freestanding v Hosted

54. Strict Conformance
Chapter 4 of the ISO Standard mandates the following:
- A conforming program is one that is acceptable to a conforming
implementation.
- A strictly conforming program shall use only those features of the
language and library specified in the International Standard.
- It shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit.
MISRA C:2012 enforces this by:
- Rule 1.1 A standard C environment
- Rule 1.3 No occurrence of undefined or unspecified behaviour
- Dir 1.1 This permits the use of implementation-defined behaviour
but requires that any such use is documented
October 26, 201654

55. Language Extensions
Chapter 4 of the ISO Standard permits the following:
- A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behaviour of any strictly
conforming program.
MISRA C:2012 advises against this by:
- Rule 1.2 Language extensions should not be used
Chapter 4 of the ISO Standard defines the following
- The two forms of conforming implementation are hosted and freestanding.
- A conforming hosted implementation shall accept any strictly conforming
program.
October 26, 201655

56. Conformance: Freestanding v Hosted
Chapter 4 of the ISO Standard defines the following:
- A conforming freestanding implementation shall accept any strictly
conforming program in which the use of the features specified in the
library clause is confined to the contents of the standard headers:
o <float.h>
o <iso646.h>
o <limits.h>
o <stdarg.h>
o <stdbool.h>
o <stddef.h >
o <stdint.h>
MISRA C:2012 has no explicit library-specific restrictions on these headers,
except for <stdarg.h> which is prohibited by required Rule 17.1
October 26, 201656

57. Conformance: Freestanding v Hosted
o <assert.h> Implicit restriction
o <complex.h>
o <ctype.h>
o <errno.h>
o <fenv.h> Major restrictions
o <inttypes.h>
o <locale.h >
o <math.h>
o <setjmp.h> Shall not be used
o <signal.h> Shall not be used
o <stdio.h> Shall not be used
o <stdlib.h> Major restrictions
o <string.h>
o <tgmath.h> Shall not be used
o <time.h> Shall not be used
o <wchar.h> Shall not be used
o <wctype.h>
October 26, 201657
MISRA C:2012 places major restrictions (including out-right prohibition) on
many of the remaining standard headers:
The restricts are due to the extent of the undefined, unspecified and/or
implementation defined behaviour, and the functionality is mostly associated
with accessing the external environment.