In the October programming language rankings released by TIOBE not long ago, C++ surpassed Java in one fell swoop and took the top spot, second only to Python and C. C++, which is over 40 years old, is still one of the most popular programming languages in the world. However, the movements of some giants in recent years have also made the security of C++ frequently at the center of controversy.
Previously, Microsoft revealed that it was rewriting the Windows 11 kernel based on the Rust language, partially replacing the previous C++. Later, Google claimed that it was migrating Android native code from C++ to Rust to further reduce security vulnerabilities.
Just as the outside world is speculating on how C++ will respond to the sudden midlife crisis and whether it really should give way to rising stars, recently Bjarne Stroustrup, the father of C++, publicly stated at the annual programming language conference held last month: He will Adding new security tools addresses criticism, bringing new solutions to billions of lines of C++ code around the world.
Rebuttal: Switching to a new language is not that simple
The 72-year-old refuted critics who believe the problem lies with C++ itself and that the solution is to switch to another language.
First, security refers to more than just memory safety.
Second, the need for interoperability between languages is often overlooked.
Third, the cost of language switching is often underestimated.
Stroustrup begins by stating that “the safety often mentioned is just memory safety – which is not enough… The need for interoperability with other languages (including C++ and C) is often not mentioned. And conversion The costs can be very high. This is rarely mentioned…”
“From what I’ve seen, we’re going to have about seven different languages replacing C++. Maybe forty years from now, we might have 20 different languages that have to interoperate with each other. It’s going to be difficult.”
Stroustrup also noted that “many so-called ‘safe’ languages outsource all the low-level stuff to C or C++”, temporarily detaching the original language to access hardware resources and even the operating system (often written in C) – It could even be extremely old “trusted code” hidden in an external library…
Stroustrup calls our current situation “an incremental and evolutionary approach, rather than the pursuit of entirely new approaches.” Like Gale’s Law: “An efficient complex system must develop from an efficient simple system.” Come.”
Ultimately, as Stroustrup points out, switching languages may seem like building a new system, but trying to solve all the problems of the old system is just a fantasy. The cost of switching languages may be much higher than you think.
New: “Be careful” won’t work, “we need to enforce the rules”
Stroustrup mentions many concepts of security, focusing on resource leaks, overflows, memory corruption, timing errors, concurrency errors, termination errors – and, of course, type errors. Then, he explained in detail the development trend of C++ security.
Stroustrup called the current situation “an opportunity,” stressing that type and resource safety have been goals of C++ since its inception. “The hardware we had then and we can’t provide complete security now for all languages and all use cases.” But Stroustrup didn’t want to see restrictions on C++ expression either, and in fact he envisioned a still A solution that follows the ISO standard for the language.
“We need it to be C++. That is, there shouldn’t be restrictions on what we can do, even though there may be restrictions on how we do it.”
At the same time, Stroustrup didn’t want to see a lot of additional runtime overhead. “There shouldn’t be any degradation in performance… In fact, some techniques for writing secure code can improve performance. I’m mainly talking about what the compiler and static checking can do because it’s free, or actually can Improve performance.”
Stroustrup found his solution: configuration files. In other words, a set of rules that, as long as they are followed, can achieve specific security guarantees. They will be defined by the ISO C++ standard, addressing common security issues such as pointer and array scopes.
As for the difficulty of adding new tools, Stroustrup noted that the C++ compiler itself is now a fairly sophisticated static analyzer that can also satisfy profile requirements. So “I think profile annotations should help with that” when it comes to adding tools to improve security.
Stroustrup outlines a general strategy: Use static analysis to eliminate potential bugs. But Stroustrup added: “Global static analysis is unaffordable.”
“So basically we need rules to simplify what we’re writing so that it can be efficiently and cheaply analyzed-local static analysis…and then provide libraries that make it feasible to rely on those rules.”
Additionally, he noted another advantage of this strategy: “supporting the gradual transition from legacy code to modern code that provides guarantees.” There will be a standard set of “base” guarantees, as well as larger, more open guarantees available. “I imagine type and resource safety, memory safety, scope safety. Things like arithmetic safety that could be standardized,” Stroustrup said. In addition, rules will be developed to apply different guarantees to different pieces of code. The code even gets an explicit expression of what guarantees are applied (thereby reassuring future readers).
Stroustrup makes the point succinctly: “Be careful” won’t work. So while core guidelines may recommend safe coding practices, “we need enforceable rules.”
“We have to create rules for safe use. We have to provide ways to verify that people are actually doing what they want to do.” Stroustrup noted that much of what he described has already been tried and even practiced at scale. “But none of this is integrated into a consistent, coherent whole. That’s what I think we should be doing.”
“Hygienic rules + static analysis + runtime checks” is the extracted formula. Stroustrup says C++ can eliminate many common errors, including uninitialized variables, scope errors, null pointer dereferences, resource leaks and dangling references.
Toward the end of his speech, Stroustrup went into more detail. “I recommend you use module-based controls.”
export My_module[[provide(memory_safety)]]; import std [[enable(memory_safety)]]; import Mod [suppress(type_safety)]];
Also in development are in-code controls for code snippets.
[[suppress(type_safety)]] X [[enforce(type_safety)]] X
Heli: A wish list for developers
This work is currently ongoing, and you can find related papers and discussions. Stroustrup said: “From classic C, from ‘C with classes’, to C++11, we have come a long, long way.”
For developers, Stroustrup suggests that users can help improve the configuration file and formalize its specifications. “I dream of something like Profiles Light, which provides most of the guarantees of profiles but can’t do all the last things because, say, static analyzers can’t do that yet.”
Stroustrup created a GitHub repository “where people can make suggestions and I’ll put my drafts etc. there so we can create a community dedicated to getting these things done in a reasonable amount of time.
The repository asks what is needed to make Profiles “an industry-wide tool for a variety of C++ security needs,” and calls the concept a framework. “To achieve widespread use, many parts must be created and installed. While we have done a lot of work, relatively few are widely available. This is a wish list. Please help in any way you can.”
Reference links:
https://thenewstack.io/bjarne-stroustrups-plan-for-bringing-safety-to-c/
https://www.youtube.com/watch?v=I8UvQKvOSSw &t=4371s