MISRA C:2023
Addressing contemporary challenges in embedded development
The MISRA Working Group’s announcement of two new editions of its MISRA C Guidelines marks a critical step in the development of safety- and security-critical devices. MISRA C:2012 Amendment 4 (AMD4) and MISRA C:2023 bring essential guidance to developers.
From automotive software to medical devices, MISRA C has long been the guiding force behind safe, secure, and reliable code. With explosive growth in the need for feature-rich and connected devices, manufacturers have naturally turned to more sophisticated techniques to squeeze more value out of their processors and peripherals. After years of real-world research and development, the MISRA C Working Group addresses these modern software complexities with new guidance on multithreading and atomic types in support of C11 and C18.
Software safety, security, and reliability are critical imperatives for many embedded systems. Our smart home devices must minimize the risk of data breach, for example, and our car’s engine control units must behave only in ways intended by the developer.
While quite popular among embedded development teams, the C language allows developers to control application behavior and memory in ways that could compromise their systems. The ISO standards that define the language (ISO/IEC 9899:2011 and 2018, colloquially known as “C11” and “C18”) do not provide a complete specification of runtime intention, leaving some aspects up to the implementation to decide.
As a result, there are non-deterministic components to the C language that give license to developers in ways that could pose risks to the system:
- Undefined behavior – the C standard does not specify a requirement
- Unspecified behavior – the C standard allows for two or more possibilities and does not specify requirements for which one(s) is used
- Implementation defined – the compiler and runtime are free to define their own behaviors and must document the behaviors themselves
Over the years, developers have become proficient at exploiting such behaviors to extract higher performance out of their applications. One example is leaving variables of large array types uninitialized to avoid incurring the memset() cost of zero-initializing the storage (while undefined in the C standard, many compilers and static analyzers will flag this). It’s the unpredictable consequences of these loopholes that the MISRA C Guidelines aim to eliminate. For example:
- Writing to a file stream opened as read-only, leading to potentially undesirable behavior
- Using recursive functions, leading to a potential stack overflow
- Accessing memory outside the bounds of a data structure, which could lead to a potential attack surface for hackers
The philosophy behind the MISRA C Guidelines
The MISRA C Guidelines restrict the C language to a predictable subset in line with the needs of safety- and security-critical systems. Through rules and directives, these guidelines minimize or eliminate coding practices that are known to be hazardous and insecure:
- Rule: A source code requirement that is complete, objective, and unambiguous. The guidelines further classify rules as decidable if they can be conclusively verified through techniques like static analysis and undecidable if no verification guarantee is possible.
- Example rule: “The value of an object with automatic storage duration shall not be read before it has been set.” (MISRA C:2012 Rule 9.1)
- Directive: A guideline that may be satisfied through code, processes, documentation, or functional requirement. Directives can be subject to interpretation, and analysis tools may be able to assist in checking compliance.
- Example directive: “Any implementation-defined behavior on which the output of the program depends shall be documented and understood.” (MISRA C:2012 Directive 1.1)
MISRA C:2023 addresses the growing use of concurrency
With increasing reliance on multiprocessor systems and multithreaded applications to support embedded applications, the MISRA Working Group released new guidelines in AMD4 and consolidated all prior editions in the MISRA C:2023 edition. Focused on the growing use of concurrency in embedded systems, AMD4 extends support to many new features introduced by the C11 and C18 standards.
Guidance on multithreading
C11 introduced atomic types and operations that enabled developers to manipulate data objects indivisibly, or without risk of interference by another thread, to avoid the chance of data races in multithreaded applications. AMD4 adds new rules and modifies some existing rules to address undefined behaviors in the C language that may compromise atomicity in the system:
- Ensuring the correct configuration of atomic types
- Preventing the unintended removal of atomicity when referencing atomic types through pointers
- Restricting the use of multiple atomic types in the same statement
MISRA C for the modern age
The AMD4 additions also include other types of rules, covering C language features known to be problematic, and minor updates to clarify existing rules and directives. These include restricting the use of small integer macros and certain use cases of designated initializers.
Perhaps the biggest change, from a process perspective, is the consolidation of earlier MISRA C editions and the recent AMD4 enhancements to provide a single, comprehensive baseline. Now in one document, MISRA C: 2013 simplifies compliance and configuration management for existing users of MISRA C and eases entry for organizations starting new projects.
By understanding and adopting the MISRA C Guidelines, embedded development teams can improve the safety, security, and reliability of their code while also demonstrating a commitment to core business objectives. Such teams will find it valuable to deploy static analysis tools that rapidly and comprehensively check code for any deviations against the MISRA guidelines.
Hall 4
Booth 505
The author
Mark Pitchford
has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
mark.pitchford@ldra.com
