Software Defined Vehicles
Automotive Software Development
A Rusty New Car
The relatively new programming language Rust promises safety, but risks still lurk under the hood. In the automotive industry, even the smallest error can be fatal – and yet C/C++ remain in play. A risky mix with consequences.
The relatively new programming language, Rust, is similar to C and C++ in syntax, provides much of the flexibility of those older languages but with much stronger safety guarantees that overcomes many of the memory-related problems encountered by C and C++ programmers and users. Rust’s expressive syntax, strong type system, and helpful compiler error messages significantly reduces the likelihood bugs being introduced. This is essential for embedded automotive systems that operate under strict resource constraints and real-time requirements.
Rust is therefore emerging as a alternative choice for the development of new software modules in high-criticality systems such as those found in the automotive industry. That’s why many major automotive manufacturers are working with Rust to develop prototypes.
Providing memory-safer structures
Rust users avoid many memory-safety issues by taking advantage of its strict rules and built-in support for memory allocation. For example, compile-time checks help guarantee the correct behaviour of references. Rust also has datatypes that provide pointer-like features that are supported by those compile-time checks. These checks help prevent issues typically encountered with C-like pointers.
Advertisement
By providing memory-safer structures and manipulation techniques, Rust can speed up the development and testing of automotive software. It also leverages the contemporary skills that developers are now learning and being trained in. These two factors are important to the automotive industry due to the fact that the complexity and volume of software systems being integrated into vehicles of every type is growing rapidly and is unlikely to slow.
However, just because Rust makes it more difficult to inadvertently introduce safety and security flaws, including memory faults, it does not mean that Rust-based codes will always be exempt from these runtime errors. In fact, these errors can still make their way into Rust software in a few ways.
Strict compilation checks
First of all, a Rust program may inherit a runtime error by calling code developed in C or C++. Many of the OEMs and Tier 1 automotive manufacturers that are exploring Rust are doing so by gradually integrating aspects of Rust alongside legacy code to mitigate risks as well as introduce Rust’s benefits. These automotive companies have invested heavily in C and C++ coding and toolchains for decades, so they are understandably trying to reuse their existing code bases. They may also be reluctant to plunge headfirst into Rust, particularly when it comes to safety. So, all of the software code, existing and new combined, still needs to be verified once integrated into a system that includes large portions written in C, C++, Rust or an additional language.
Second, there are needs that can only be met by bypassing some of Rust’s safeguards. This is particularly true for embedded control systems. Many low-level interactions such as accesses to memory-mapped hardware registers or data buffers, cannot easily be performed under Rust’s strict compilation checks.
Code that dereferences a raw pointer in Rust, for example, will trigger a compile error unless developers encapsulate that code within unsafe {} blocks. This marking tells the compiler to not perform its usual safety checks when compiling this code. As the result, the chances that a memory issues slips through to production code increases.
The role of unsafe blocks
There are other situations where developers need to use unsafe {} blocks, such as usage of unions. Although unions are not a core Rust feature, support for unions can be important to ensure Rust’s compatibility with C and C++. That’s because the compiler cannot guarantee the safety of operations on any fields because it cannot determine whether writes to one field will or will not corrupt the other fields that share the same memory structure.
There are many situations where unsafe markings are required in native Rust code. Within the general-purpose library that Rust uses, roughly 30% of the packages within the collection at crates.io use the unsafe{} construct. Again, a compiler cannot check operational safety within these packages.
Finally, to make matters worse, there are also situations where code that is not highlighted as “unsafe” in Rust can still experience memory issues at runtime. The Rust Book (the Rust language official documentation) even lists some trivial examples of these, such as an out-of-bounds access. Such codes will compile, however if specific combination of values are experienced at runtime, the error will cause the Rust thread to crash. Of course, such events are very undesirable in safety-critical applications such as the ones we find in Automotive.
However, just because runtime errors can still make their way to Rust programs does not mean these cannot be exhaustively detected before compilation. Formal verification and mathematical-reasoning techniques exist that enable code analysis before execution. They can determine whether code will suffer from memory-safety issues such as buffer overflows, null-pointer accesses and other issues.
Reducing the risk of costly recalls
Such static-analysis techniques are exhaustive in a way that provides guarantees at a level that even extensive dynamic testing cannot. Proper implementation of these methods ensure zero false negatives (failing to indicate the presence of a real error in code) and a low level of false positives (indicating an error where none exists). Using these techniques, developers working with Rust-based can highlight where problems can occur, and can then provide additional safeguards to ensure proper operation of the software. In general, the automotive industry’s drive toward electrification and connectivity requires a new approach to software development. Rust stands out as a language capable of reducing the risk of costly recalls due to software errors; enabling secure over-the-air updates and remote diagnostics; and modernising the skillset and productivity of automotive software teams.
As more automotive organisations contribute to the Rust ecosystem, the language is poised to play an increasingly important role in the vehicles of tomorrow.
But even if Rust helps to reduce the possibility that errors get inadvertently introduced in the code base, it does not eliminate it. For starts, Rust will likely coexist with C and C++ for the foreseeable future. And the fact is that even if Rust adopts a safer approach to memory-related issues, such issues can still happen, even in code bases that are entirely written in Rust and forgo the use of unsafe blocks.
The good news is that Rust-friendly tools like TrustInSoft’s TrustInSoft Analyzer, a static analysis tool that uses Formal Methods to provide mathematically proven guarantees about software safety and security, can be used to pinpoint exhaustively all of these issues, independently whether they are raised by Rust native code or calls to C/C++. Even better, TrustInSoft Analyzer can detect these hard-to-find bugs directly in mixed code bases, which increases the precision of its diagnostics, lowering the number of false positives. By leveraging Formal Methods verification, TrustInSoft Analyzer reduces the need for extensive manual testing while ensuring that the combined automotive software codebase is free of unsafe memory issues long before it hits the road.
This article was first published at all-electronics.de
