Hey there, human — the robots need you! Vote for IEEE’s Robots Guide in the Webby Awards.

Close bar

The Move to Memory-Safe Programming

Shifting from C and C++ to memory-safe programming languages like Rust is gaining ground

3 min read
zeros and ones in a random sequence, a few brighter to look like an outline of a brain
iStock

Memory safety is in the spotlight. In November 2022, the National Security Agency recommended the use of memory-safe programming languages to protect against software-memory safety issues. Earlier this year, Consumer Reports encouraged the use of memory-safe languages in its “Future of Memory Safety” report.

“One of the key reasons why memory-safe languages are gaining popularity now is the prevalence of security issues, one of the main causes of which are memory-safety vulnerabilities,” says Azalea Raad, a senior lecturer in the Department of Computing at Imperial College London.

Memory safety is a feature of programming languages that prevents certain types of memory-access bugs, such as out-of-bounds reads and writes, and use-after-free bugs. In an app that manages a list of to-do items, for example, an out-of-bounds read could involve accessing the nonexistent sixth item in a list of five, while a use-after-free bug could involve accessing one of the items on an already deleted to-do list. These bugs could lead to accessing private data, corrupting data, or even executing code that isn’t part of a program.

“For instance, an out-of-bounds read can result in reading from adjacent blocks in memory that may contain sensitive data,” Raad says. “Similarly, an out-of-bounds write can overwrite sensitive information in memory and lead to hijacking the control flow of the program and executing privileged or malicious code.”

In memory-safe languages, these bugs are caught during compile time or runtime. At compile time, they’re flagged as errors which can then be fixed. When detected at runtime, they result in crashes instead of allowing unchecked access to memory, thereby limiting the potential damage and preventing security vulnerabilities.

Most programming languages are considered memory-safe—except for C, C++, and assembly. “Until the last few years, almost all systems software was written in C or C++, which are notoriously not memory-safe,” says Dan Grossman, a professor and vice director of the Paul G. Allen School of Computer Science & Engineering at the University of Washington.

Some tech companies responsible for systems software—such as operating systems and other low-level systems—are beginning to realize the importance of memory safety. In 2019, Google and Microsoft reported that a majority of vulnerabilities in their products have been memory-safety issues, and a similar study on Apple’s operating systems found the same. These companies are taking action by adopting more memory-safe languages. For example, Meta is embracing Rust and Linux is adding support for the language in its kernel. In Google’s Android 13 OS, about one-fifth of all new native code is in Rust, with the search giant seeing a significant drop in both the number and severity of memory-safety vulnerabilities.

“We’re now understanding that memory-safety vulnerabilities aren’t some esoteric computer science concept,” says Josh Aas, executive director of the Internet Security Research Group, whose Prossimo project is promoting the move toward memory safety. “They are a real consumer-safety issue. They are a national cybersecurity issue.”

Rust—ranked 20th in IEEE Spectrum’s top programming languages of 2022—is a memory-safe alternative to C and C++ and can be used to write low-level system code or develop an OS kernel, according to Raad. She also suggests software developers switch to Swift when developing for iOS and macOS; Kotlin when developing for Android as it offers interoperability with Java, the primary language Android was written in; and Go when writing network code for servers.

To make the move to new programming languages more manageable—especially for software developers working on large code bases—Raad recommends starting with a new code base instead of an existing one, as it would involve no code rewriting “but would still require adapting and extending the existing infrastructure for testing and deployment to support the new language.”

The next step is to target new modules of existing code bases, which also doesn’t warrant any code rewrites but “has a higher overhead as it would require building abstractions such as data structures for exchanging data that crosses the boundary between the two languages,” says Raad.

Finally, programmers could look into rewriting an existing module in a memory-safe language. “Ideally, this should be a module with a small scope to minimize the inherent risks of code rewrites and where there is a clear performance or security advantage in switching to a memory-safe language,” says Raad.

To further simplify the shift, coders could take advantage of application programming interfaces (APIs). “A lot of Rust components come with a C API, so you can benefit from that and you don’t have to learn a whole new language,” Aas says.

He adds that testing is also vital when adopting memory-safe languages. “If you’re worried about the idea that rewriting code might cause bugs, it’s good to recognize that investments in writing tests for your existing code are going to pay off here,” Aas says. “If you have really good tests for your current code, then those tests are going to help you verify that any rewriting in a memory-safe language is correct.”

Moreover, companies themselves could facilitate programming in memory-safe languages by providing training opportunities and engaging senior software engineers as language champions, which could make “a significant difference as they can provide code review and train developers new to the language,” says Raad.

The shift to a new programming language usually entails a learning curve, but “in the case of memory safety, the payoff is typically worth it,” says Grossman. “The world of ‘one bug can make the entire system inherently insecure’ is simply too dangerous.”

The Conversation (2)
Michael Faughn
Michael Faughn27 Feb, 2024
M

Kotlin is nice but Java is memory safe, right? Why suggest Kotlin over Java for Android apps (and why specifically for Android)?

Julian Cardich
Julian Cardich23 Mar, 2023
INDV

The "memory safety" issue is a red herring. Even so, we do not need trash languages like Rust. C and C++ can conveniently incorporate any requirements in a more efficient and elegant way than ugly inconvenient languages like Rust.