Why MISRA C matters for embedded system developers

Embedded systems are ubiquitous in our daily lives, from medical devices to automotive systems to smart homes, yet the most popular embedded programming language poses significant safety and security risks. The MISRA C guidelines reduce such risk by providing a set of rules and directives to minimize undefined behaviors and vulnerabilities in areas such as memory allocation, pointer management, and buffer overflows.

The recent release of the MISRA C:2012 Amendment 4 (AMD4) and upcoming release of the MISRA C:2023 edition offer embedded developers the opportunity to re-evaluate how the guidelines are adopted by embedded software teams. Amendment 4 addresses concurrency features introduced in the latest versions of the C standard (ISO/IEC 9899:2011 and 2018) and MISRA C:2023 will consolidate all MISRA C versions into one document.

By expanding the guidelines to cover multithreading and atomic types, the MISRA C guidance aligns to the increasing complexity and scale of embedded systems in any industry. Embedded developers are relying more on these concurrency features and sophisticated hardware platforms to deliver on growing requirements for connected devices and feature-rich user experiences.

Advancements in LED Drivers for Next-Generation Automotive Exterior Lighting09.18.2023

Reducing the Production Cost of Integrated Circuits in the Integration Era09.14.2023

Democratizing Edge AI and ML with a No Code Approach09.12.2023

MISRA C:2023 compliance report from the TBvision component of the LDRA tool suite indicates 27 violations within a C file. Source: LDRA

Reducing the risk of safety issues and security breaches in these complex environments means understanding how MISRA C compliance applies to your code.

The risks of C programming for critical systems

The MISRA Working Group developed the MISRA C guidelines to establish best practices in coding, tools, and development processes to ensure the reliability, safety, and security of embedded software in critical systems. MISRA C addresses a wide range of potential coding errors in areas such as data type conversions, control flow statements, and use of the standard library functions.

Such errors arise from limitations in the C language standard itself, where the implementation and behavior of some features are not specified to give compilers, operating systems, and developers flexibility in their use.

These unspecified features can lead to behaviors at runtime that are:

Undefined – the C standard contains no requirement for how the feature must behave.Unspecified – the C standard allows for two or more behaviors for a feature with no specification as to which one shall be used.Open to interpretation by the language implementation (compiler and operating system) to decide and document.

This flexibility allows implementers of the C standard and embedded developers to write code that meets the requirements of the language. However, it can also cause undesirable and unpredictable effects in critical systems. Below are some examples:

Writing to a file stream opened as read-only can lead to potentially undesirable behavior.Using functions that call themselves recursion can lead to a potential stack overflow.Accessing memory outside the bounds of a data structure can lead to a threat vector exploitable by hackers.

MISRA compliance example

To help development teams test their code and prove compliance, MISRA C classifies guidelines as either rules or directives:

Rule: A source code requirement that is complete, objective, and unambiguous. Developers can use analysis tools to check compliance with rules. The guidelines further classify rules as decidable if analysis tools can conclusively verify them and undecidable if no verification guarantee is possible.

Directive: A guideline satisfied through code, processes, documentation, or functional requirements. Directives can be subject to interpretation, and analysis tools may or may not be able to assist in checking compliance.

Take this code sample that uses the C sizeof() operator in accordance with the C standard:

void foo(int32_t x)

{

size_t x;

s = sizeof(int32_t[x]); //Compliant to MISRA C

s = sizeof(int32_t[x++]); //Non-compliant to MISRA C

}

As sizeof() does not execute expressions passed into it, but rather simply evaluates the type and size of the resulting expression at compile time, this code may result in unexpected behavior at runtime. Although such usage is legal according to the C standard, the MISRA Working Group restricts this usage in MISRA C:2012, Rule 13.6, stating that “The operand of the sizeof operator shall not contain any expression which has potential side effects.”

The guidelines classify this rule as decidable, which means that developers can use static analysis tools to identify occurrences in code where this rule is violated. Once identified, developers can correct the error with a simple adjustment:

void foo(int32_t x)

{

size_t x;

s = sizeof(int32_t[x]); //Compliant to MISRA C

++x;

s = sizeof(int32_t[x]); //Compliant to MISRA C

}

Benefits of MISRA compliance

Some C compilers can identify risky coding implementations, but they are by no means as comprehensive or effective as automated tools that can identify issues earlier in the lifecycle. As MISRA C lays out decidable rules to clearly restrict language use to a safe and secure subset, tools deploying static analysis can use this information to help developers identify potential issues as they write code.

MISRA C influences standards across many industries where critical software is built. MISRA C guidelines are either directly cited by or commonly practiced in projects following AUTOSAR, IEC 62304, IEC 61508, ISO 26262, and DO-178C processes. MISRA C also forms the basis of the Joint Strike Fighter C++ Coding Standard and the NASA Jet Propulsion Library C Coding Standard.

In addition to improving the security and safety of embedded systems, compliance with MISRA C has legal and financial benefits. Development teams adopting a MISRA compliance strategy can demonstrate due diligence toward reducing the risk of liabilities and the loss of confidence among consumers, investors, and industry regulators. In the event of a product recall, security breach, or similar incident, the artifacts of MISRA compliance can support investigation, remediation, and re-release efforts.

The path forward with MISRA C

MISRA C is not a coding style guide but rather a set of rules and directives to minimize or eliminate coding practices known to be hazardous. Especially relevant to the complexity of safety- and security-critical systems, AMD4 and MISRA C:2023 give developers an important tool in avoiding or eliminating potentially dangerous code.

By adapting development processes to support the effective and efficient demonstration of MISRA compliance, such as using static analysis tools to identify violations, teams can improve the reliability of their products and reduce the likelihood of vulnerabilities in their code.

Mark Pitchford is a technical specialist at LDRA.

Related Content

MISRA C: Write safer, clearer C codeUsing MISRA C and C++ for security and reliabilitySoftware test tools add support for MISRA C: 2012MISRA C update addresses automotive software safety5 ways to incorporate MISRA C:2023 into your embedded development process