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.