Experiencing the Journey Towards Memory Safety

The push towards migrating to MSLs (Memory Safe Languages) has been growing over the past years and shows no signs of slowing.

This trend really started to gain steam with the NSA’s release of the “Software Memory Safety” Cybersecurity Information Sheet all the way back in 2022, and has continued to this day with multiple other government agency publications advocating for the adoption of memory-safe languages (naming Rust and Ada specifically).

Like with almost every aspect of software engineering, the stupendous progression of coding agents and LLMs (especially the commercial frontier models) has amplified the capabilities to detect and exploit defects that MSLs could have prevented.

As a customer-facing engineer, I get the opportunity to explore the wide spectrum of techniques and solutions that different organizations are looking at as part of their journey towards delivering memory-safe software.

Today, I wanted to share my hands-on experience with one approach; namely, performing advanced static analysis of C++ code while translating it to Ada.

The Starting Point

I wanted my experiments to have some real-world relevance, so I started (like I expect most would today) by asking my favorite AI chatbot to scour the internet for an open-source, C++ library, that has aerospace industry pedigree. It didn’t take much convincing that NASA’s F’ open-source library, which is currently deployed on 3 space missions, would be a really interesting example!

The first stop on my memory safety journey was to set up advanced static code analysis of the codebase using CodeSonar. Truthfully, this was my first attempt to analyze some non-trivial, real-world C++ code with CodeSonar, and I was keen to see if it was as simple to start as I had been promised in my training. Good news, it was (at least for a high-quality project like NASA’s F’ library)!

The F’ ecosystem comes with a set of Python build tools (fprime-util) that generate and build gobs of C++ code which depend on a core fprime library. Once I figured out the build command (unsurprisingly fprime-util build), getting CodeSonar to start analyzing the code was as simple as wrapping this build command in the codesonar analyze sub-command (e.g. codesonar analyze FPRIME ... -preset misrac++ fprime-util build). Under the hood, CodeSonar does all the heavy lifting of monitoring the processes spawned by the build command.

This was already a meaningful achievement, using advanced static analysis to check compliance with standards like MISRA C++ is one technique for improving the memory safety of C++ code. However, there are some drawbacks because Static Analysis generates false positives, so time and effort must be devoted to understanding the warnings (in addition to MISRA C++ being a challenging standard to comply with in the first place).

Translating to Ada

The “Rewrite it in Rust” movement needs little introduction, but in the A&D vertical it’s been interesting to see somewhat of a reversal in the trend of rewriting Ada to C++.

My colleagues, Tony Aiello and Mark Hermeling have been reporting great progress in the frontier coding agent models’ abilities to generate Ada and SPARK code, so I thought this was a great opportunity to try to recreate their results.

Unfortunately the one-shot prompt which translated the C++ code to Ada is lost to time since I didn’t archive it and I no longer have access to the machine it ran on, but the gist of it was something like:
“For the purposes of demonstrating CodeSonar’s mixed Ada and C++ analysis features, translate a non-trivial part of this C++ library’s source code and after translation, inject an inter-unit, inter-procedural memory safety vulnerability in the Ada code.” I added that second part to the prompt to make sure that static analysis had a juicy error to report.

The coding agent dutifully obeyed and delivered a new version of the library with just the FrameAccumulator component responsible for reconstructing message frames from byte streams rewritten in Ada, linked with the rest of the code in C++ and passing all its original unit tests.

All that was missing was a convenient way to analyze more than one of the newly translated Ada components at once which was just requiring the creation of an aggregate GPR project. With that in place, analysis of the now mixed Ada and C++ codebase was done in just two commands: codesonar build FPRIME -clean ... codesonar ada_scan.py ada_all.gpr followed by codesonar analyze FPRIME ... -preset misrac++ fprime-util build. The former performs the advanced static analysis of the Ada code, and the latter augments that data with the intermediate representation used for C++ analysis before sending everything to the CodeSonar Hub to finalize the C++ analysis and combine all the results.

The end result: a single mixed-language analysis that shows warnings for both languages in unified reports, charts, and the CodeSonar Web UI views.

Note: the warnings reported on the original F’ code were not reviewed and could be false positives or coding standard violations for a coding standard the code does not adhere to, so these counts do not reflect in any way, shape, or form the quality of the F’ library.

Conclusion

AI code translation capability is mature enough to be useful and can translate C++ code to Ada quite well. Advanced static analysis tools can ingest mixed code bases and can be used to place cost-effective guardrails around the translation process to avoid unintentionally introducing vulnerabilities into field-tested code. This provides a pathway to component-by-component translation of existing C++ code into memory-safe Ada. The next step would be to lift the Ada code to SPARK Silver and statically prove the absence of runtime errors. As an added benefit, Ada is a language with a long history in functional safety, so if your software has functional safety requirements, you have a strong path to switch from certified C++ to a certified C++-Ada mix, to a certified memory-safe Ada solution.