Memory safety isn’t a top priority for the ISO C++ 26 standard, despite growing concerns that it is a black hole in the programming language. Frustrated committee members said that conflicting interests, differing priorities and lack of participation has stymied the passing of memory safety proposals.
The topic was discussed during a technical session at the Supercomputing 2024 (SC2024) conference, held recently in Atlanta.
“I’m personally not too confident that there’s going to be any reasonable timeline for that,” said Bruno Lopes, a software engineer at Meta, who is also a member of the C++ standards committee.
Security Not a Major Focus
Languages such as C and C++ can introduce memory-safety-related vulnerabilities in systems. Hackers can use buffer overflows to inject malicious code or steal data from memory. Bad code can crash critical systems.
The C++ standard has evolved, but security isn’t at the top of the list as members have other priorities. People who show up at standards meetings might not have anything to do with safety, said Gonzalo Brito, a GPU architect at Nvidia. “If people that care about safety don’t show up, then I wouldn’t expect any improvement in that area whatsoever, even though everybody that goes there thinks it’s very important.”
Brito cares about the feature as it speeds up finding sources of bugs.
He said one bug reproduced once every 20 runs, and memory safety could prevent potentially expensive bugs that could otherwise take months to figure out.
“What I care about is being able to debug programs at scale or not have them fail,” Brito said.
Proposals
There are multiple proposals for memory safety in C++.
Meta’s Lopes likes Sean Baxter‘s Circle, which is a C++ compiler that aims to bring Rust-like safety features to C++. It is partially inspired by Rust’s borrow-checking system.
“It seems that to get something like that into standard C++, it’s going to be a multiyear, multi-people effort kind of thing,” Lopes said.
Another safety proposal is called Profiles from Bjarne Stroustrup, which allows developers to annotate code, make assumptions and establish safety requirements when building and compiling programs.
“You can actually bind these with modules — you can say that a certain module you’re importing must have some safety guarantees whenever it’s imported into your translation unit,” Lopes said.
Multiple Angles of Attack
Between Circle and other proposals, people are attacking the memory safety issue from multiple angles.
People can write up small pieces, try them out, and be part of the conversation, and then progress from there. However, it may take a long time to reach a consensus, the panelists said.
“Everyone wants to make their piece of THE thing … It takes some time for things to converge, and I’m just not very hopeful that’s going to happen. That’s my personal take,” Lopes said.
People using alternative memory-safe languages also have huge pre-existing C and C++ codebases. The committee has to find solutions that involve both safe programming languages and C++, at least in the medium term.
Lessons From Rust
“We have been trying to engage more with the Rust community to have a better Rust-C interoperability story,” Brito said.
The standards committee knows it has to start somewhere, and C++ 26 is addressing some fundamental security issues.
“We now have a feature that always initializes automatic variables on the stack, which helps prevent a pretty large subset of bugs,” Brito said.
Why Memory Safety Is Important
Baxter’s D3390 proposal points to several calls by the U.S. government about C++ being an unsafe programming language, which exposes systems to attacks by malicious actors.
Implementing memory safety in C++ by default reduces the chances of human programmer error. Memory safety issues also arise from vulnerabilities in CPUs and GPUs, with the most notable ones being the Meltdown and Spectre vulnerabilities in 2018.
Microsoft is actively aware of memory safety issues in C++ and is rewriting core system applications in Rust. These programs are mainly code such as firmware that forms the first line of defense to protect systems.
The company’s secure boot modules for the Surface hardware are being rebuilt on Rust. The UEFI (Unified Extensible Firmware Interface) firmware that boots the device to Windows OS is written in Rust, as is code for Microsoft’s security chip called Pluton.
Google in a research paper said that memory vulnerabilities put industries and society in danger.
“Google’s data and internal vulnerability research show that memory safety bugs are widespread and one of the leading causes of vulnerabilities in memory-unsafe codebases,” the company said.
DARPA has launched a program called TRACTOR (Translating All C to Rust) that will “automate the translation of the world’s highly vulnerable legacy C code to the inherently safer Rust programming language.”
The TRACTOR program envisions programmers feeding code to an AI model to automatically convert large C++ code bases to Rust. Current large language models can’t do that and may introduce errors in the process.
Memory Safety in Production
The SC2024 discussion panelists talked about past and future memory safe ideas.
There was an Epochs proposal that allowed switching off unsafe legacy code.
“I personally thought it was a pretty cool proposal, but it didn’t go anywhere,” Lopes said.
There are also attempts to add safety features by triggering specific behaviors for modules.
“That will guarantee that you only get the safe parts of things,” Lopes said.
There are also certain sanitizing tools that can run safety checks on code.
Some tools behind the UndefinedBehaviorSanitizer in Clang falls into that category.
“They were designed to be used in testing and not in production. You have to be a little bit careful — the address sanitizer kind of falls into that latter category,” said Hal Finkel, who is the director of the Computational Science Research and Partnerships Division at the U.S. Department of Energy, and formerly vice chair of the C++ standards committee for many years.
It’s complicated, as there’s not a single set of safety checks, so programmers need to be careful, Finkel said.
The post C++ Committee Divided on Memory Safety Plans appeared first on The New Stack.