MISRA guidelines have always been designed to help developers write high-quality code, which is by nature more safe and secure. But increased industry awareness of security risks promoted the MISRA C working group to review the guidelines with that specific benefit in mind.

Security risks had increased significantly with the advent of the Internet of Things. Secure application code may only be one component of the defence-in-depth strategy needed to develop a secure connected device, but it is nevertheless an important part if vulnerabilities are to be minimized.

In acknowledgement of this changing environment, MISRA C:2012 Amendment 1 was written to further ensure complete coverage of the C Secure rules, and to be used as an extension to MISRA C:2012. It established 14 new guidelines for secure C coding to improve the coverage of the concerns highlighted by the ISO C Secure Guidelines, and these rules were fully integrated into the MISRA C document in MISRA C:2012 (3rd Edition, 1st Revision), first published in 2019.

Insecure coding examples and related rulesTo put the amendment into context, it is useful to review examples of where the additional rules apply.Example 1: Rule 12.5Rule 12.5 states, “The sizeof operator shall not have an operand which is a function parameter declared as “array of type”

Many developers use the “sizeof” operator to calculate the size of an array. In a normal scenario that works fine. But when that approach is used on an array passed as a function parameter, that parameter is passed as a “pointer to type.” Consequently the attempt to calculate the number of elements usually returns an incorrect value, possibly resulting in an array bound being exceeded (Figure 4).

Figure 4: sizeof source code example

A static analysis tool can be used to check for the use of such syntax (Figure 5).

Figure 5: The TBvision component of the LDRA tool suite detects the MISRA C:2012 rule violation for the “sizeof” operator example

Example 2: Rule 22.7Rule 22.7 states “The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF.”

An “EOF” (End Of File) return value from standard library functions is used to indicate that the relevant stream has either reached the end of the file, or an error has occurred in reading from or writing to that file. The macro “EOF” is defined as an “int” with a negative value.

If the “EOF” value is captured in a variable of incorrect type, then it may become indistinguishable from a valid character code (Figure 6). It is therefore important to use an “int” to store the return code from such functions such as “getchar()” or “fgetc()”, and to avoid because the common practice of storing the result in a char.

Figure 6: EOF source code example

Automatic detection of rule violation at an early stagePeer reviews represent a traditional approach to enforcing adherence to such guidelines, and whilst they still have an important part to play, automating the more tedious checks using tools is far more efficient, less prone to error, repeatable, and demonstrable (Figure 7).

Figure 7: The TBvision component of the LDRA tool reports the Rule 22.7 (EOF comparison with char) violation in the source code

MISRA C and cybersecurity