Amendment to MISRA C:2012 has been released by the MISRA C Working Group in support of the C Standard known as “C11” and formally ratified as ISO/IEC 9899:2011. C11 has been gaining widespread use and for projects and organizations that have been holding off migrating to C11, this is a well-received announcement. C11 also replaces C99 (standard ISO/IEC 9899:1999) and has been superseded by C18 (standard ISO/IEC 9899:2018). In addition to the updated C language guidelines, the MISRA C Working Group released the MISRA Compliance 2020 guidelines, which are now mandatory to claim compliance with the standard.
MISRA C:2012 Amendment 2 now references ISO/IEC 9899:2011 and contains C language updates, providing guidelines to features that may be used but subject to restrictions and features that are prohibited unless it comes with a deviation that has been approved through your teams software review process. During the development of amendment 2, the opportunity to correct any known issues with the previous additions have also been taken. Unending the MISRA working group’s mission to provide guidance towards avoiding unpredictable behavior, reduce or remove coding defects and facilitate code safety, security, portability and reliability in the context of embedded software systems.
One example of a new MISRA Rule added that applies to new features in C11 is Rule 1.4, “Emergent language features shall not be used.” An instance of this would be if the facilities <threads.h> and the _Thread_local storage class specifier is used; this Rule will tag the C11 language structure with a violation category type “Required”. C11 standardizes the semantics of multi‐threaded programs, potentially running on multi‐core platforms, and lightweight inter‐thread communication using atomic variables. Global memory local to a thread is used, in which instances of undefined and unspecified behavior have been identified, including defined behavior which does not meet expectations. Moving forward and being compliant with MISRA C:2012 Amendment 2, if I use _Thread_local not only is a deviation required but assurance measures need to be put in place in order to address the behaviors that compromise safety and/or security.
The _Generic keyword is another new C11 language feature that shall not be used which may exhibit undesired behavior and some have found that the C11 standard is vague in certain scenarios. The _Generic operator is a type of macro overloading. It is used to help the programmer use any macro as generic, for the purpose of making it more efficient. The following line of code shows how the _Generic keyword is used to declare any macro for the different types of data types and as generic for different methods. Take the following VOL macro example below; VOL(x) translates to VOLc(x), VOLl(x), VOL(x) or VOLf(x) depending on the type of x.
#define VOL(x) _Generic((x), char: VOLc, long double: VOLl, default: VOL, float: VOLf)(x)
One common cause of security vulnerabilities is the use of the standard library function system defined in <stdlib.h>. MISRA C:2012 Amendment 2 has added new Rule 21.21 which specifies that the standard library function system shall not be used. The system call is a blocking function, used to execute subprocesses and commands, waiting until the child process terminates and returns its exit value. Recognize that the prototype “int system (const char *command);” does not need to be a single command but can be a pipeline or series of pipelines. (e.g. system (“pngtopnm \”My Picture.png\” | pnmtoxwd > fout.xwd && xwud fout.xwd”);) Since the variable command is constructed from user-supplied data, an attacker may be able to break out of the quoting and execute any arbitrary command in the context of the parent. Some suggested measure could be to utilize predetermined command strings or bypass the system call all together and use spawn instead.
For a claim of MISRA compliance there are written guidelines which have been refined and revised over a past number of years. The latest of this document is the MISRA Compliance 2020, which was just released in February. From a high level view, having in place a reporting of the use of a well-ordered software development process, a list of exactly which guidelines are being applied and the effectiveness of the enforcement methods, including the degree or level of the deviations, plus having had taken into account the status of all software components developed outside of the project is necessary in order to claim MISRA compliance. Parasoft DTP provides a dedicated reporting extension that is fully conformant with the requirements from the MISRA Compliance standard. DTP will guide you through the process of building the Guidelines Enforcement Plan (GEP) and Guidelines Recategorization Plan (GRP) and automatically generate Guidelines Compliance Summary (GCS) together with a full list of approved deviations. Automated reporting eliminates a huge amount of tedious manual work and enables organizations with the compliance process which is now mandated for MISRA coding guidelines.
There are other new MISRA C:2012 Amendment 2 Rules that stand out like the _Noreturn function specifier, the _Atomic type specifier, the _Alignas alignment specifier and the _Alignof operator. Use of these type specifiers will trigger a category Required violation and are not to be use, addressing concerns with coverage of C11 and security vulnerabilities. There are also the numerous Amendment 2 updates and text replacements made, which clarify, improving the standard. Also, very important to note again that along with the standard, users have the now mandatory and complimentary compliance release of the MISRA Compliance 2020 guidelines to follow. Kudos to the MISRA working group for continuing to do an outstanding job and providing an immense contribution to the software community.
Sr. Technical Product Marketing Manager for Parasoft’s embedded testing solutions. He has expertise in the SDLC and test automation of embedded real-time, safety and security critical applications, and software compliance to industry standards.