Parts of the FreeRTOS kernel are MISRA 2012 compliant (details are here). I am quite impressed with the work done to make a project originally written without MISRA in mind MISRA-compliant.
They used Coverity static analysis (now part of Synopsis) to perform the MISRA testing at the time. But I wondered what CodeSonar would find today on that kernel, and whether or not the Coverity scans cover MISRA 2023 checkers. So I setup a project in GitLab, based on an earlier FreeRTOS demo that I already had, and conducted a test using CodeSecure’s CodeSonar Static Application Security Testing (SAST) with built in MISRA compliance modules.
Parameters
The four key parts to the FreeRTOS work include:
- A project that defines what parts are included, see examples/coverity, for single and multi-core versions
- A configuration that turns certain checkers off for Coverity, which is typical for many projects that select a subset of MISRA to target
- A file with a set of deviations and justifications for those
- Annotations in the source files that refer to the file in number 3
Hypothesis
What would CodeSonar find on code that was Coverity tested?
My reasoning behind this test is simple: we know that CodeSonar has fewer false negatives compared to Coverity because we hear this from our customers frequently, especially from those that build security- and safety-critical software. This mostly relates to security vulnerabilities and paths through the source code where a problem may occur, often due to memory violations.
MISRA is a C subset that makes C memory safe, with a set of guidelines to follow. Nevertheless, I wanted to test this for the “fun” factor.
What would the delta be if we enabled MISRA 2023 checkers?
MISRA 2023 is mostly a roll-up of the MISRA 2012 amendments, but I still wanted to find the answer to this question out of my own curiosity.
All in all, it took me about 15 mins or so to create the clone and setup the pipeline and run some tests. Actually reviewing the results took a bit more time, but the findings are worth it.
Findings
The results were interesting and pretty much in-line with my expectations. For example:
- Some rules that Coverity did not check for, such as 17.11 (a function that never returns should be declared with a _Noreturn function specifier)
- Some findings that Coverity somehow did not detect, for example a comparison between an unsigned and a signed char, which violates rules 10.4 (Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category).
- A couple of places where CodeSonar simply digs deeper, such as variables that can remain uninitialized in certain cases and possible integer underflows.
- No new warnings after switching to MISRA-C 2023, which makes sense, as the CodeSonar MISRA 2012 configuration covers the latest version of MISRA 2012 and MISRA 2023 is really the roll-up of all the amendments and corrections to 2012.
Bullet number one above is more of a software clarity check, it makes software easier to understand. Bullets two and three can actually lead to run-time failures. I am actually surprised to the number of MISRA warnings that Coverity missed.
With these and other specific findings resulting from my tests, I am currently working on integrating the findings into the open-source project and working towards a set of pull requests that provides MISRA corrections, source code fixes and a CodeSonar configuration for FreeRTOS. Giving back to the open source community is important and having the CodeSonar configuration readily available will make it easier for projects to get started and deliver more safe and more secure code fast.
Want to have a look for yourself? The CodeSonar configuration is available here:
https://github.com/CodeSecure-SE/FreeRTOS-Kernel/blob/main/examples/codesonar/README.md
