Ryan Levick and Sebastian Fernandez, two Microsoft engineers, will give a keynote address at RustFest Barcelona on Saturday, November 9. They’ll discuss the reasons Microsoft is looking into implementing Rust, some of the difficulties we’ve encountered, and Microsoft’s plans for the future. Attend the keynote and speak with Ryan and Sebastian afterward if you want to learn more about how Microsoft is changing its code practices for better security.
A portion of the tale of Microsoft’s adoption of Rust is detailed in this blog. I recently had to rewrite an experimental low-level system component of the Windows codebase ( sorry, we ca n’t say which one just yet ). I was instructed to use Rust, a memory-safe alternative, rather than rewriting the code in C++. I can say that I’ve had a generally positive experience with Rust, even though the project is n’t yet complete. For those looking to avoid common errors that frequently result in security flaws in C++ code bases, it’s a wise choice.
Excellent development experience
Rust is a breath of fresh air for C++ developers who are accustomed to writing complex systems. The compiler’s assurances of memory and data safety give developers much more assurance that their code will be accurate and free from memory safety flaws. Debugging unimportant problems or annoying racial conditions takes up less time. Rust programmers can quickly identify and fix problems in their code thanks to the compiler’s extremely well-written warning and error messages. A useful extension ( RLS ) for VSCode already offers syntax highlighting and Intellisense suggestions. The Cargo build tool also provides a wealth of practical features for testing, creating documentation, and automatic formatting.
Curve learning
For someone like me who has spent the majority of my career using C++, learning Rust is fairly simple thanks to the abundance of online documentation and extremely helpful compiler error messages. C/C++ systems engineers are the target audience for some tutorials. In his speech at RustConf 2019, Facebook’s Jeremy Fitzhardinge observed that seasoned C/C++ developers became accustomed to the language in about four weeks and fairly fluent in eight. This is consistent with what I’ve seen. With one seasoned Rust developer and one total novice, I took part in the yearly Microsoft internal” One Week” hackathon. The inexperienced Rust programmer wrote more than 1000 lines of idiomatic code in just three days. In addition to the excellent documentation, there are practical tools like Clippy that enable seasoned C++ developers to begin coding Rust without much help from knowledgeable users.
I think it would be wise to create a RustReviewers group for any PRs that contain RuSt code as Microsoft expands its use of the language. Regardless of the particular problem domain, this will assist novices in various teams in getting feedback from Rust experts.
Generally speaking, it will be the simplest to port new or existing components to Rust with simple interfaces. The part I’ve been rewriting has been difficult because there are numerous abstractions that have been leaked from one layer to the next, necessitating some initial revision.
Interfaces for Foreign Functions ( FFI )
Linking Rust code to C ABI ( application binary interface ) boundaries is simple. Writing boilerplate code for basic functions using basic types only requires a small amount of it. However, a wrapper function is always preferred because FFI operations are never safe. It is preferable to use bindgen to automatically create a Rust struct equivalent for functions that require more complex structures. Although some teams are already looking into it, it will take more research to be able to directly interact with C++. We believe that Microsoft’s recently released COM library is the first step in this direction, but we will eventually require more sophisticated tooling to directly interact with intricate C++ APIs.
preserving its security
Strict guidelines must be put in place regarding the use of the unsafe keyword in order to get the desired safety guarantees from Rust. A wrapper function that offers a secure abstraction around an FFI function should receive any calls to it. A wrapper function or struct that offers a safe abstraction should be included in any other code that must use the unsafe keyword.
In reality, unsafe has only been necessary for handling very simple protocols outside of FFI boundaries. In these situations, writing generic unsafe code that can be thoroughly unit tested and applied to a variety of scenarios makes the code feel much safer than C++. Since I ca n’t rely on the compiler to guarantee memory safety after writing Rust code, I find writing C++ to be much more frustrating.
Having a set of internal Rust coding standards will assist new developers in making the most of the language, in addition to providing safety assurances. Higher quality code will be produced more quickly if error handling, logging, locking, and other language-specific practices are followed.
The Rust community and desired features
There are still some language features that would be ideal for our development given Rust’s relative youth. The safest of these are fallible allocation ( fail gracefully from allocation failure rather than panic ), safe transmutation ( safely cast “plain old data” types to and from raw bytes ), and safe support for C style unions.
Unit testing built into Cargo, which enables developers to write unit tests in the same file as production code and easily run them while developing, is another incredible feature of Rust. Unfortunately, our large and complex build system does not currently support Cargo as a build tool, so we cannot rely solely on these tests for automatic code integration flows. The Cargo team has already begun discussing how big businesses like Microsoft, which have complicated current build systems, can still profit from the company.
The community is already working to address these problems as a result of interest in using Rust in low-level systems like kernels and hypervisors as well as microcontrollers. I have no doubt that Microsoft will be able to contribute to these efforts to shape the language’s future and increase its usefulness in these circumstances.
Moving forward from here
Rust usage has generally been a really positive experience. I’m excited to see more Microsoft developers collaborating with the general public and other developers to improve the language’s suitability for some of the tasks we perform here at the company.
Adam Burch, a Hyper-V team software engineer