SAFETY & SECURITY STANDARDS
Compare MISRA C With SPARK For Safe and Secure Programming By Yannick Moy, AdaCore
As part of the Linux Security Summit Europe last October, I participated in a panel around the question, “Would Abandoning the C Language Really Help?” C, which is the main language used in the Linux kernel, is notorious for having an endless source of vulnerabilities. Just look at the long list of open bugs automatically reported by the fuzzing robot syzbot that are still waiting for a fix.1
T
he panel discussion revolved around alternative, safer languages that are suitable for kernel development like Ada and Rust, as well as the need for formal verification to go beyond the guarantees that a compiler can provide. Indeed, many memory and safety vulnerabilities currently reported on the Linux kernel would stop the program altogether in Ada or Rust, which is only slightly better. Looking at kernel patches reveals that many issues could be detected by specifying simple properties on the code, like what calls are legal in which mode, the types of data invariants that should be preserved, and how to verify them statically using appropriate tools. Surprisingly, MISRA C was not mentioned at all during the discussion, even though
12
it has established itself as a must-have in a number of industries to protect against fallibilities of the C language. MISRA C appeared in 1998 as a coding standard for C, initially for the automotive industry, and has been revised twice. The current version is MISRA C:2012. It focuses on avoiding error-prone features of the C programming language rather than enforcing a particular programming style. A study of coding standards for C, written by Les Hatton, found that, compared to ten typical coding standards for C, MISRA C was the only one to focus exclusively on error avoidance rather than style enforcement, and by a very large margin.2 The popularity of the C programming language, as well as its many traps and pitfalls, have led to the huge success of MISRA C in domains where C is used for high-integrity software. This success has driven tool vendors to propose many competing implementations of MISRA C checkers.3 Tools compete, in particular, on the coverage of MISRA C guidelines that they help enforce, as it is impossible to enforce all of the 16 directives and 143 rules (collectively referred to as guidelines) of MISRA C. In particular, 27 rules out of 143 are not decidable, so no tool can always detect all violations of these rules without, at the same time, reporting “false alarms” on code that does not constitute a violation. An example of an undecidable rule is rule 1.3: “There shall be no occurrence of undefined or critical unspecified behavior.”
Embedded Computing Design EMBEDDED WORLD | Spring 2021
www.embedded-computing.com
