MISRA C is a coding standard for the C programming language developed to enable safe and secure embedded systems. It defines a subset of the C language that removes opportunities for mistakes. The standard has evolved from focusing on the automotive industry to being applicable for any industry requiring high integrity or reliability software. Recent updates to MISRA C include improved compliance guidance, additional security rules, and assessments of coverage against other standards like ISO/IEC TS 17961 for secure coding rules and CERT-C. Future work plans to consider rules addressing C11 features and operating environment access.

1. MISRA C Presentation
Safety and Security
... and future plans for MISRA C
Device Developer Conference, Cambridge (April 2016)
Andrew Banks
BSc IEng MIET FBCS CITP
Frazer-Nash Research Limited, and
Chairman, MISRA C Working Group

2. The C Language
A Quick History
April 27, 20162

3. 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!
April 27, 20163

4. MISRA-C – The Rationale
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...
April 27, 20164

5. MISRA C
A Quick History
April 27, 20165

6. 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)
April 27, 20166

7. 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)
April 27, 20167

8. MISRA C - A brief history
April 27, 20168
CompanyspecificMISRACMISRAC++
MISRA
C++:2008
MISRA
C:2012
MISRA
C:2004
MISRA
C:1998
JSF++
Rover
Ford
UK MoD

9. 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.
April 27, 20169

10. MISRA C:2012 – The Document
Published early 2013
159 Guidelines in total
- 16 Directives
o 9 Required
o 7 Advisory
- 143 Rules
o 10 Mandatory
o 101 Required
o 32 Advisory
Includes a compliance and deviation policy
April 27, 201610

11. MISRA C:2012 – The Structure
March 201611
20 9%
157 69%
49 22%
Pages
Introductory material
Guidelines
Appendices
Content
19 18%
62 58%
25 24%
MISRA
C:2004
Pages

12. MISRA C
Misunderstandings
April 27, 201612

13. 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
April 27, 201613

14. Myth Busting #2
The Misunderstanding
- MISRA C is only a safety coding standard, not a secure/security one
The History
- MISRA C 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
- The difference between safety and security are largely semantic
- Unfortunately, a perception remains...
April 27, 201614

15. MISRA Compliance
April 27, 201615

16. MISRA-C – Published Today
MISRA Compliance
- Enhances guidance for compliance guidance
- Clarifies/tightens the Deviation process
- Standalone document
o Compatible with MISRA C:2012 (and any future versions)
o Compatible with MISRA C++:20xx
o No reason it cannot be applied to earlier versions of either document!
April 27, 201616

17. Safety v Security
Comparison with other guidelines
April 27, 201617

18. ISO/IEC TS 17961
C Secure Coding Rules
April 27, 201618

19. 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 (see later) but significantly
rationalised
From the document’s Background:
- “In practice, security-critical and safety-critical code have the same
requirements”
- “The purpose of this Technical Specification is to specify analyzable
secure coding rules that can be automatically enforced to detect security
flaws in C-conforming applications”
April 27, 201619

20. ISO/IEC TS 17961 – C Secure Coding Coverage
Coverage Method # Comments
MISRA covers fully – explicitly 22 Some rules are stricter than SecureC
MISRA covers fully – broad 12 Eg: bans dynamic memory, signal.h
MISRA covers fully – implicitly
5 Undefined/unspecified behaviour
3 Standard library
MISRA covers partially – broad 2 getenv() and related functions
MISRA does not cover directly 2 sizeof(pointer), padding
46
April 27, 201620

21. ISO/IEC TS 17961 – C Secure Coding Coverage
The MISRA C Response...
MISRA C:2012 Addendum 2
“Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013”
MISRA C:2012 Amendment 1
“Additional Security Guidelines”
- Fourteen new guidelines
o 1 new Directive
o 13 new Rules
April 27, 201621

22. ISO/IEC TS 17961 – Revised C Secure Coverage
Coverage Method # Comments
MISRA covers fully – explicitly 31
MISRA covers fully – broad approach 7 Eg: bans dynamic memory, signals
MISRA covers fully – implicitly
3 Taint
5 Undefined/unspecified behaviour
MISRA covers partially or not at all 0
46
April 27, 201622

23. CERT-C
C Secure Coding Rules
April 27, 201623

24. 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
- We are reviewing CERT-C’s rules and recommendations
April 27, 201624

25. CERT-C (April 2014) – MISRA C:2012 Coverage
Coverage Method #1 #2 Comments
MISRA covers – fully 36 42
MISRA covers – partially 18 22
MISRA does not cover explicitly 41 33 But many are covered by directives
Possible Contradictions! 1 1?
96 98
#1 Assessment presented at escrypt.
#2 MISRA C Working Group preliminary assessment
(MISRA C:2012 against CERT-C:Apr14)
A full assessment will be published in due course...
April 27, 201625

26. Road Map and
Work In Progress
April 27, 201626

27. MISRA-C – Published Today
MISRA Compliance:2016
- Achieving compliance with MISRA Coding Guidelines
MISRA C:2004 Permits
- Deviation permits for MISRA Compliance
MISRA C:2012 Addendum 2
- Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 “C Secure”
MISRA C:2012 Amendment 1
- Additional Security Rules for MISRA C:2012
April 27, 201627

28. MISRA-C – Work In Progress
MISRA C:2012 Addendum 3
- Coverage of MISRA C:2012 against “CERT-C”
MISRA C:2012 Technical Corrigendum 1
- Address typographical errors and guideline clarification
April 27, 201628

29. MISRA C roadmap
March 201629
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 To publish Consolidate

30. 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
April 27, 201630

31. 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...
April 27, 201631

32. In Summary
April 27, 201632

33. 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
April 27, 201633

34. Any Questions?
April 27, 201634

35. 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.
April 27, 201635

36. References
MISRA C:2012
http://misra.org.uk/
Embedded Security in Cars (November 2014, Hamburg)
https://www.escar.info/history/escar-europe/escar-europe-2014-lectures-and-program-committee.html
ISO/IEC TS 17961:2013 – C secure coding rules
http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134
CERT-C
https://www.securecoding.cert.org
ISO/IEC 9899 CD2 comments and decisions
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n847.htm
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n872.htm
April 27, 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
April 27, 201637

38. Extra Material
April 27, 201638

39. ISO/IEC TS 17961
C Secure Coding Rules
April 27, 201639

40. ISO/IEC TS 17961 – The Gaps
The gaps (partial or not covered) can be grouped as follows:
- Taintedness as a concept
- The use of getenv(), localeconv(), setlocale() and strerror() 2 rules
[or indeed other library functions relating to a hosted environment]
- Use of sizeof() on a pointer function parameter 1 rule
- Comparisons of padding data 1 rule
Proposal
- MISRA C:2012 be enhanced to address these gaps
April 27, 201640

41. ISO/IEC TS 17961 – The Broad Approaches
Some C Secure rules are implicitly fully covered by broad approaches
- MISRA C:2012 prohibits the use of the restrict keyword 1 rule
- MISRA C:2012 prohibits the use of dynamic memory allocation 3 rules
- MISRA C:2012 prohibits the use of the features in <signal.h> 3 rules
- MISRA C:2012 prohibits the use of the features in <stdio.h> 5 rules
Rationale
- MISRA C’s scope was originally freestanding application, without an
operating system and/or external environment
Proposal
- Keep these broad approaches under review
- Establish more targeted rules where appropriate
April 27, 201641

42. ISO/IEC TS 17961 – The Implicit?
Many of the Secure C rules are implicitly covered by Directives
- D4.1 Run-time failures shall be minimised
- D4.11 The validity of values passed to library functions shall be checked
Some of these may benefit from additional, focussed, rules
- The use of errno 1 rule
- The use of character handling functions 1 rules
- Use of string copying functions 1 rule
April 27, 201642

43. The Gaps – Taintedness
C Secure
- Many!
MISRA C:2012
- No explicit coverage of taintedness
- Directives D4.1 and D4.11 cover many of the consequences.
- The undefined behaviours are also trapped by R1.3
- Some unwanted behaviour also trapped by broad rules
o General prohibition in the use of stdio.h, signal.h etc
Proposed way ahead
- Add a new MISRA C directive to require validation of externally sourced
data to protect against taintedness.
- Additional explicit rules may be added as required.
April 27, 201643

44. Standard Conformance
Freestanding v Hosted
April 27, 201644

45. 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
April 27, 201645

46. 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.
April 27, 201646

47. 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
April 27, 201647

48. 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>
April 27, 201648
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.