Rust at Microsoft (or the creation of Security Daemon Azure IoT Edge)

Note from the translator: Rust is a relatively young programming language, and practical examples are always interesting at this stage of development. It is known that Intel, Dropbox, Amazon, Facebook, Google and others use Rust in their projects. About the use of Rust in the project from Microsoft was known, but there were no details, and this is probably the first official publication about the use of Rust at Microsoft. (technical details for the product itself are provided “as is”, specify details on the company's website)



Azure IoT Edge is an open-source cross-platform software project created by the Azure IoT development team at Microsoft. Azure IoT Edge “is an Internet of Things service based on the Internet of Things Center. This service is intended for customers who need to analyze data not in the cloud, but on edge devices. As a result of moving part of the workload to the border area, devices spend less time sending messages to the cloud and respond more quickly to events. ” [Taken from official Russian-language documentation (1) - approx. translator]



This post explains some of the reasons we chose Rust as the programming language for implementing the Security Daemon component in the product.



Security Daemon loads the Azure IoT Edge runtime. It acts as a mediator between the Azure IoT Edge runtime and many host services, such as the container runtime and hardware cryptography hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs).

Technical stack selection for Security Daemon

When we started working on Security Daemon (hereinafter referred to as edgelet ), we identified the following main design goals:

• edgelet must be a native component that does not require a runtime, such as the .NET CLR.
• since the edgelet will serve as a channel for accessing the HSM / TPM equipment on the device, it must be protected.
• edgelet will communicate with HSM / TPM equipment through the binary C application interface (ABI), so loading common objects / DLLs and calling C functions should be simple.

According to these points, we had to choose one of the following programming languages: C or C ++, or Rust, which compiles into native code. Unwillingness to bear the overhead of the garbage collector meant that Go was not suitable for us. The security requirements of the daemon meant that we wanted to avoid memory and concurrency errors. As it turned out, given these limitations, Rust is perfect for us. In a previous publication (2) on this blog [referring to the “Microsoft Security Response Center” blog - translation comment] , the advantages were considered when choosing Rust as the programming language.

What did we like

Before we released Azure IoT Edge to the public, we brought in an external security vendor to test penetration software. The fact that they did not find any problems with the security of the code base in Rust was for us a confirmation of the correctness of our choice. From the very beginning, we decided that the compiler would treat all warnings as errors, including errors verified by clippy. Our continuous integration system rejects the pool of requests that do not pass rustfmt, which ensures consistent formatting of the code throughout the code base.



The process of updating the Rust and Cargo compiler [assembly and package management system - approx. translator] work seamlessly in Azure IoT Edge. Upgrading to a new version of the compiler is almost always a painless action.

Acceptance of Rust

The next step was learning the language. Compared to other popular programming languages, Rust has a fairly high entry threshold, and we feared what impact this study would have on project timelines. Our team had experienced developers in C, C ++, C # and Java, and fortunately for us, there were also several developers who were very passionate about Rust!



We came up with Rust workshops in which we conducted a team on those parts of the language that, in our experience, were quite difficult to understand. These time consumptions turned out to be very useful. We found that learning a language ended up not being as big a problem as we imagined.



For 4-6 weeks, almost every member of the team made a non-trivial contribution to the source code in Rust.

Difficulties

Despite the fact that our first experience of launching a production with a Rust-based product at Microsoft was completely successful, we would have noted several difficult points:

• The Rust ecosystem is still relatively new compared to some other more established languages. This meant that we often had to create parts of the infrastructure that otherwise we probably would not need to create.
• Parsing compiler error messages sometimes proved too complicated, especially when working with code that heavily used combinators from Tokio (3) [an asynchronous framework for Rust] Futures or std :: iter :: Iterator.
• Teams that are used to fully supporting C # editing and debugging tools and Java code have not found the same support in Rust. The VS Code Rust RLS extension was unstable in practice.
• Challenges in Tokio Future Chain Analysis
• Sometimes it was not easy to sort out the complex types that inevitably arise in Tokio Future combinator chains.

What's next

It would be fair to note here that Azure IoT is fully integrated with the Rust programming language. Since we released Azure IoT Edge, the use of Rust has only increased. Many of the cloud service projects that are currently being actively worked on are written in Rust. The trinity that Rust offers (memory security, data race security, and performance) is perfect for Azure IoT. We hope that we will have something else to say about this in the future!



Raj Wengalil, General Manager, SWE, IoT Platform

References

(1) docs.microsoft.com/en-us/azure/iot-edge

(2) msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming

(3) tokio.rs



From a translator: thanks for the help in translating Legatus88 , Funkill , the Russian-language telegram group Rust (@rustlang_ru), KDPV from here .