Memory Safety: An Interview on Rust and the Future of Secure Software Development, Part 2

The first part examined the issue of memory safety vulnerabilities and possible solutions. The programming language Rust is considered a promising path toward more secure software. In this interview, hardware security expert Pascal Mainini (BFH TI) explains why Rust is worth considering, where the biggest hurdles for companies lie, and in which areas the language is already gaining significance today.

[Herren]: You teach the module Introduction to Rust and Embedded Systems and work extensively with Rust. How did you first come into contact with this language, and what specifically sparked your interest in Rust?

[Mainini]: I had already heard about this programming language but had no experience with it yet. At a departmental conference, the head of computer science at the time asked whether anyone knew of an operating system called “Tock”; it is written in Rust and also has other interesting properties. I was a bit bold and volunteered—even though I didn’t know it. That’s how I ended up with this elective module, which I have now taught for the 6th time.

[Herren]: Why should someone opt for Rust from your perspective? Why not, for example, stick with the established language C++, which is also increasingly focusing on memory safety?

[Mainini]: The question is justified. Compared to the time when I started with Rust, there has indeed been a shift in thinking in other languages as well. It’s also somewhat a philosophical question: I can also write memory-safe programs in C, for example, but the necessary caution and effort are  significantly higher. Wouldn’t it then be better to choose a language that already has the corresponding principles fundamentally built in?

On the other hand, I can also write memory-unsafe programs in Rust, but the language forces me to explicitly mark such areas. From my perspective, this is a great advantage and better than the reverse approach. For some time now, there are also certified compilers available, which enable the use of the language in safety-critical areas such as automotive components, for instance.

[Herren]: How do you see the future of Rust? Will companies increasingly switch to Rust?

[Mainini]: As always, there are the early adopters, but also those who are already fully on board. In between, there is a large field that is observing and perhaps developing a single application in Rust to test it out. At conferences, however, you also see big names that are fully committed to Rust, and there is now quite a bit on offer in the consulting sector. I think the topic has definitely arrived in the industry.

[Herren]: In which industries or areas will Rust gain importance?

[Mainini]: Rust is  a general purpose language, but there are areas where adoption is already more advanced. On one hand, of course, programming close to hardware, but also, for example, the cloud sector. Since Rust is a very efficient language, it also contributes to energy efficiency when applications run on thousands of servers. Last but not least, Rust is also the only language that can now be used alongside C for developing drivers for the Linux kernel.

[Herren]: What are the biggest hurdles for companies that want to rely more on Rust?

[Mainini]: I think certainly the personnel situation: programmers who have been programming in C++ for 20 years can be found on the market—this is not yet the case with Rust. Also, potential costs that always arise when established processes need to be adjusted. And also a certain uncertainty regarding the future development of Rust, although I think it is becoming increasingly smaller.

[Herren]: Do you think that if Rust gains importance in the future, security vulnerabilities related to memory safety will decrease?

[Mainini]: Absolutely. That is the goal of industry, but also of politics. There are corresponding statements even up to the White House level. This is not primarily about Rust, but about memory safety – I share this goal!

[Herren]: Are there any developments where you are curious to see how Rust will evolve in the future?

[Mainini]: Yes, on one hand, the developments in the Linux kernel – there are many controversial discussions there, although the topic is established. And I’m also curious about the embedded sector: things generally move a bit more slowly there. These are companies that have been on the market for a long time, and there are established processes and systems.

[Herren]: What would you advise future developers? Is it worth taking a closer look at Rust?

[Mainini]: It is definitely worth taking a closer look at Rust. Even if you don’t end up programming in Rust afterwards, it raises awareness enormously. I generally think it’s a good idea to look at different languages, and Rust is a language with interesting concepts.

What is Memory Safety?

Memory safety describes how securely and correctly software handles the management, allocation, and release of memory (RAM). Both program code (the instructions the computer executes) and data (such as user data or calculation results) are stored in memory. Faulty access to memory can be exploited by attackers to execute malicious code or read confidential data, for example. Despite years of research, memory safety remains one of the most common causes of vulnerabilities in modern software.

Where are memory safety vulnerabilities found in practice?

An analysis of data from the National Vulnerability Database (NVD) shows that consistently around 15-20% of published vulnerabilities across the entire IT landscape are related to memory safety. Such vulnerabilities also occur in commonly used systems of various kinds.

What are approaches to improving memory safety?

To avoid memory safety vulnerabilities, it is recommended that program code is written in memory-safe languages as much as possible. Languages like Python, Java, and C# achieve this through automatic memory management (e.g., with a garbage collector). The language Rust, on the other hand, relies on strict rules for memory management that guarantee memory safety already at development time, without an additional garbage collector.

Interested?

To learn more about the topic of memory safety, read the full article here.