Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

MISRA C – Recent developments and a road map to the future

  1. 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. 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. 3. MISRA C – A Quick History From the beginning, to MISRA C:2012 (See “Additional Material”)
  4. 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. 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. 6. MISRA C – Safety v Security Or do we just mean “High Integrity”?
  7. 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. 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. 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. 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. 11. MISRA C – Recent Developments (1) Updates for improved Compliance
  12. 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. 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. 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. 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. 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. 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. 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. 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. 20. MISRA C – Recent Developments (2) Additional guidance for Security
  21. 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. 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. 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. 24. MISRA C – Recent Developments (3) Comparison with CERT-C
  25. 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. 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. 27. MISRA C – Recent Developments (4) Technical Corrigendum 1
  28. 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. 29. MISRA C Road Map From MISRA C:2012 to MISRA C:201x ... and then into the future
  30. 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. 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. 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. 33. In Summary October 26, 201633
  34. 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. 35. Any Questions? October 26, 201635
  36. 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. 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. 38. Extra Material October 26, 201638
  39. 39. MISRA C – A Quick History From the beginning, to MISRA C:2012
  40. 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. 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. 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. 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. 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. 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. 46. MISRA C – A Quick History From the beginning, to MISRA C:2012
  47. 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. 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. 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. 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. 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. 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. 53. MISRA C – Standards Conformance Freestanding v Hosted
  54. 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. 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. 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. 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.

×