View
372
Download
5
Category
Preview:
Citation preview
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
The C Language
A Quick History
April 27, 2016 2
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, 2016 3
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, 2016 4
MISRA C
A Quick History
April 27, 2016 5
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, 2016 6
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, 2016 7
MISRA C - A brief history
April 27, 2016 8
Co
mp
an
y s
pe
cific
M
ISR
A C
M
ISR
A C
++
MISRA
C++:2008
MISRA
C:2012
MISRA
C:2004
MISRA
C:1998
JSF++ Rover
Ford
UK MoD
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, 2016 9
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, 2016 10
MISRA C:2012 – The Structure
March 2016 11
20 9%
157 69%
49 22%
Pages
Introductory material
Guidelines
Appendices
Content
19 18%
62 58%
25 24%
MISRA
C:2004
Pages
MISRA C
Misunderstandings
April 27, 2016 12
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, 2016 13
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, 2016 14
MISRA Compliance
April 27, 2016 15
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, 2016 16
Safety v Security
Comparison with other guidelines
April 27, 2016 17
ISO/IEC TS 17961
C Secure Coding Rules
April 27, 2016 18
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, 2016 19
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, 2016 20
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, 2016 21
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, 2016 22
CERT-C C Secure Coding Rules
April 27, 2016 23
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, 2016 24
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, 2016 25
Road Map and Work In Progress
April 27, 2016 26
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, 2016 27
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, 2016 28
MISRA C roadmap
March 2016 29
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
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, 2016 30
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, 2016 31
In Summary
April 27, 2016 32
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, 2016 33
Any Questions?
April 27, 2016 34
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, 2016 35
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, 2016 36
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, 2016 37
Extra Material
April 27, 2016 38
ISO/IEC TS 17961
C Secure Coding Rules
April 27, 2016 39
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, 2016 40
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, 2016 41
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, 2016 42
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, 2016 43
Standard Conformance Freestanding v Hosted
April 27, 2016 44
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, 2016 45
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, 2016 46
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, 2016 47
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, 2016 48
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.
Recommended