Using MISRA C and C++ for security and reliability. Part III

There are a couple of programming errors in the example:

1. The C code does not check that malloc returns a non-NULL pointer. In C++, a call to new that cannot be fulfilled will result in a throw, but the surrounding code would need to be analyzed to see whether it could correctly handle the exception.

A secure embedded system will probably need to restart the thread in a way that is consistent with its design.

2. The memory allocated is never freed.

This kind of analysis might lead to other insights. For example, there is often an upper bound on the size of most inputs. If this is true, in this case, then the programmer could have just as well used malloc in a case where a static or automatic array of fixed size would have been better. Even if these sorts of transformations are not possible, it can still be instructive to look at the places where memory allocation is used. This requirement will tend to discourage unnecessary uses of malloc.

Of course, a development team could use most of MISRA, but totally disregard rules that do not seem practical for their application given the amount of development time that they have. For example, a team could follow all of the required MISRA rules, except for the rule that prohibits dynamic memory allocation. They could also decide to follow many of the useful advisory rules, such as rule 6.3 (which says to use length-specific types instead of the built-in types). Later on, perhaps after completing the next milestone, the team could reconsider any rules that they chose to disregard in the last pass.

It might also be necessary to add additional rules beyond what MISRA calls for. For example, MISRA C++ allows exception handling, but any given system may not be able to accommodate the ROM size of the tables if they are not often used. If the compiler offers an option that excludes exception handling in order to generate better code, this might be the right thing to do. Others claim that exception handling makes a program difficult to analyze.

One thing that makes MISRA particularly attractive is that a number of embedded tools vendors are already checking the rules this in their compilers and code checkers. This off the shelf support makes MISRA easier than other alternatives that specify rules but have little infrastructure to back them up.

Conclusion
MISRA is a valuable tool for programming teams trying to write highly secure and reliable code. The rules are well thought out and provide many insights into likely errors and constructs that may cause security problems. Almost anyone who writes C or C++ code will find MISRA’s coding guidelines useful. Consistent use of MISRA will increase the security of your software.

Check out Part One and Part Two.

----------------------
If you found this article to be of interest, visit Military/Aerospace Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of military, defense and aerospace. And, to register to our weekly newsletter, click here.