Design Article
Using MISRA C and C++ for security and reliability. Part III
Greg Davis, director of engineering, Compiler Development
8/22/2012 8:30 AM EDT
Editor's Note: This article was originally presented at ESC Boston 2011.
-------------------------
The purpose of MISRA C and MISRA C++ guidelines are not to promote the use of C or C++ in critical systems. Rather, the guidelines accept that these languages are being used for an increasing number of projects. The guidelines discuss general problems in software engineering and note that C and C++ do not have as much error checking as other languages do. Thus the guidelines hope to make C and C++ safer to use, although they do not endorse MISRA C or MISRA C++ over other languages.
MISRA C is a subset of the C language. In particular, it is based on the ISO/IEC 9899:1990 C standard, which is identical to the ANSI X3.159-1989 standard, often called C ’89. Thus every MISRA C program is a valid C program. The MISRA C subset is defined by 141 rules that constrain the C language. Correspondingly, MISRA C++ is a subset of the ISO/IEC 14882:2003 C++ standard. MISRA C++ is based on 228 rules, many of which are refinements of the MISRA C rules to deal with the additional realities of C++.
In Part One, Compiler Development introduced MISRA C and MISRA C++ and presented the taxonomy of rules.
MISRA C and MISRA C++, in their entirety, are obviously not for everyone. MISRA was designed for the automotive market where reliability is of the utmost importance, but manufacturers in other markets, such as game machines, may be able to tolerate less reliability in order to cram more features into the product. But, in terms of security, a simple and well-conceived design usually wins. It’s hard to imagine an extremely secure design that doesn’t lend itself to quite a number of the MISRA rules.
As discussed earlier, some of the rules in the standard are advisory. One need not always follow them, although they are not supposed to just be ignored. Even the mandatory rules do not need to be observed everywhere. But, a manufacturer wishing to claim that his product is MISRA compliant must have a list of where it was necessary to deviate from the rules, along with other documentation mentioned in the standard.
A looser approach might suffice in many cases where total compliance is not necessary. For example, let’s consider dynamic memory allocation. Some projects might only use dynamic memory in rare circumstances. It might be wise for an embedded development team to look through their uses of dynamic memory to verify that their use of dynamic memory is truly safe.
Consider the following example:
-------------------------
The purpose of MISRA C and MISRA C++ guidelines are not to promote the use of C or C++ in critical systems. Rather, the guidelines accept that these languages are being used for an increasing number of projects. The guidelines discuss general problems in software engineering and note that C and C++ do not have as much error checking as other languages do. Thus the guidelines hope to make C and C++ safer to use, although they do not endorse MISRA C or MISRA C++ over other languages.
MISRA C is a subset of the C language. In particular, it is based on the ISO/IEC 9899:1990 C standard, which is identical to the ANSI X3.159-1989 standard, often called C ’89. Thus every MISRA C program is a valid C program. The MISRA C subset is defined by 141 rules that constrain the C language. Correspondingly, MISRA C++ is a subset of the ISO/IEC 14882:2003 C++ standard. MISRA C++ is based on 228 rules, many of which are refinements of the MISRA C rules to deal with the additional realities of C++.
In Part One, Compiler Development introduced MISRA C and MISRA C++ and presented the taxonomy of rules.
In Part Two, Compiler Development reviewed the rules mentioned in Part One. Now, Part Three is applying MISRA.
--------------------------
Applying MISRAMISRA C and MISRA C++, in their entirety, are obviously not for everyone. MISRA was designed for the automotive market where reliability is of the utmost importance, but manufacturers in other markets, such as game machines, may be able to tolerate less reliability in order to cram more features into the product. But, in terms of security, a simple and well-conceived design usually wins. It’s hard to imagine an extremely secure design that doesn’t lend itself to quite a number of the MISRA rules.
As discussed earlier, some of the rules in the standard are advisory. One need not always follow them, although they are not supposed to just be ignored. Even the mandatory rules do not need to be observed everywhere. But, a manufacturer wishing to claim that his product is MISRA compliant must have a list of where it was necessary to deviate from the rules, along with other documentation mentioned in the standard.
A looser approach might suffice in many cases where total compliance is not necessary. For example, let’s consider dynamic memory allocation. Some projects might only use dynamic memory in rare circumstances. It might be wise for an embedded development team to look through their uses of dynamic memory to verify that their use of dynamic memory is truly safe.
Consider the following example:
|
|
|
|
|
Navigate to related information
Phil.Gillaspy
8/31/2012 3:24 PM EDT
I have looked over the MISRA C++ standard and by and large it is a very reasonable code standard. Naturally though, I have my disagreements with several restrictions. Most significantly, I believe the rationale based on performance to be unjustifiable. The MISRA standard has as its purpose to prevent and reduce code errors. Performance is not within that directve.
Sign in to Reply