In this series, we’ve looked at the need for preventative action to fix a group of vulnerabilities and discussed some Microsoft code examples of memory safety problems that could have been avoided. We’ll now take a look at why, in our opinion, Rust is the best C and C++ substitute currently on the market.
First off, Microsoft already offers a ton of fantastic memory safe languages that are widely used both internally and externally. These include .NET languages like C# or F# as well as Swift, Go, and Python. Anyone currently using C or C++ is encouraged to think about switching to one of these languages. However, we’re referring to the requirement for a secure programming language ( i .e., one that can create operating systems similar to OS kernels ) for other software. These workloads require C, C++, and Rust’s quickness and predictable performance. Systems programming should avoid languages whose runtimes can result in unpredictable performance and needless overhead because they achieve memory safety through garbage collection.
Control and performance
Consider the performance and control that we ca n’t afford to sacrifice by switching from C or C++ when considering why Rust is a good alternative. Similar to C and C++, Rust has a small and optional “runtime.” Running on platforms without an operating system is also possible because Rust’s standard library is optional and depends on libc for platforms that support it, such as C and C++.
Like C and C++, Rust also provides the programmer with fine-grained control over when and how much memory is allotted, giving them a precise prediction of the program’s performance each time it is run. Rust, C, and C++ can all be thought of in the same terms, which has an impact on performance in terms of raw speed, control, or predictability.
Safety
Rust’s robust safety guarantees set it apart from C and C++. Rust is completely memory safe, making it impossible to express the problems we highlighted in the previous post unless explicitly opted out of using the “unsafe” keyword. We’ll go over those examples again in a later post to see how Rust typically avoids those problems without increasing runtime. As we’ve seen, memory safety concerns account for about 70 % of the security concerns that the MSRC assigns a CVE to. This means that 70 % of these security problems would have likely been fixed if the software had been written in Rust. Additionally, other businesses have also reported similar findings.
Sometimes a programmer in systems programming must carry out operations that cannot be statistically validated as secure. What was once restricted to code comments or conventions can now be statically enforced by the Rust compiler because it provides the programmer with the tools to wrap these operations in secure abstractions. Additionally, the surface area security professionals must examine for memory safety vulnerabilities must be clearly marked as such, which significantly reduces the scope of the memory-unsafe operations.
Performance and safety are not the only factors.
Due to the aforementioned factors, Rust initially piqued the MSRC’s interest, but other Microsoft teams have begun utilizing it for other factors.
- The main justification for adoption, according to an internal survey, was” correctness” —a continuation of Rust’s safety assurances that contribute to the proverb “if it compiles, then it works.”
- Beyond memory safety, Rust statically enforces a number of program characteristics, such as data race safety and null pointer safety ( i .e., no unsynchronized access of memory between two or more threads ).
- Numerous Microsoft teams have discovered that expressive program writing is made possible by Rust’s extensive type system. Rust’s goal of making programs as bug-free as possible is further enforced by ideas like enums with associated data and a strong trait system.
- The language benefits greatly from the community that already exists in Rust. Through libraries, tooling, and learning resources, a language’s power is largely derived from outside of its core. Rust, despite its youth, has a robust ecosystem with an open and active compiler and language development process, and it demonstrates its capacity to support production users while also fostering an active open source community. This strengthens our conviction that the language has a promising future.
All of this explains why Rust has consistently ranked highest on Stack Overflow’s list of preferred languages over the past four years. Early adoption of Rust has generally been very positive, even though it’s too early to say what it looks like at a scale as large as the engineering organization of Microsoft.
a promising future
When it comes to creating safe systems software, we think Rust revolutionizes the game. Rust empowers software developers to create robust, secure programs while giving low-level systems the performance and control they need.
We encountered some problems while researching Rust that have caused us to pause and still do. How to control the use of the “unsafe” Rust superset at scale, the lack of first-class C++ interoperability, and the compatibility with current Microsoft tooling are a few of these issues. Since many of these are difficult for Microsoft to adopt, we’ll be blogging about them in the future. We also want to involve the Rust and larger software communities in our search for universally applicable solutions.
However, the possibilities are what we’re most excited about. We encourage others to join us in carefully examining the language for their systems programming needs, even though there are still many unanswered questions about how Rust fits into the larger Microsoft engineering story.
Principal Cloud Developer Advocate Ryan Levick
Posts that are related: