September 5th, 2024

Deploying Rust in Existing Firmware Codebases

Google's Android team is integrating Rust into firmware to enhance security, focusing on new and high-risk code while addressing compatibility and porting challenges with tools like Bindgen for seamless integration.

Read original articleLink Icon
Deploying Rust in Existing Firmware Codebases

Google's Android team is integrating Rust, a memory-safe programming language, into existing firmware codebases to enhance security. This initiative stems from the need to address vulnerabilities in firmware, which often relies on memory-unsafe languages like C and C++. The blog post outlines a gradual approach to adopting Rust, focusing on new and high-risk code, which can significantly reduce vulnerabilities over time. The team emphasizes the use of "drop-in" Rust replacements for C code, allowing for seamless integration while maintaining performance. Key considerations for this transition include selecting appropriate Rust libraries, ensuring compatibility with bare-metal environments, and addressing challenges such as porting existing libraries to no_std configurations. The blog also discusses the importance of creating thin Rust shims to bridge existing C APIs with Rust implementations, minimizing unsafe code usage. Additionally, it highlights the need for custom target architectures and the use of tools like Bindgen for generating Rust FFI bindings to C. Overall, the adoption of Rust aims to provide a more secure foundation for firmware, ultimately making exploitation of the operating system more difficult.

- Google is adopting Rust to enhance firmware security by replacing memory-unsafe languages.

- The approach focuses on gradually integrating Rust into new and high-risk code.

- Drop-in replacements for C code are emphasized for seamless integration.

- Key challenges include ensuring compatibility with bare-metal environments and porting libraries.

- Tools like Bindgen are used to facilitate interaction between Rust and existing C code.

Link Icon 9 comments
By @the_panopticon - 4 months
This article is a nice addition to the community since rarely is a complete rewrite of a firmware corpus possible. Speaking of Rust and host or boot firmware, the recently published https://techcommunity.microsoft.com/t5/surface-it-pro-blog/s... provides a nice experience report. Other work on moving Rust into EDKII for UEFI style firmware https://github.com/tianocore/edk2-staging/tree/edkii-rust is described in https://uefi.org/sites/default/files/resources/Enabling%20RU... and https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resour.... There's also guidance on Rust for firmware in a book chapter https://link.springer.com/chapter/10.1007/978-1-4842-6106-4_....
By @Kostarrr - 5 months
It's really cool that google is investing so heavily in rust. However, the blog post is more of a "starting point" than a "lessons learned" (which I hoped for).
By @yazaddaruvala - 5 months
I hope this effort can also translate into more Rust in Linux, rather than potentially Android on a different OS.
By @gpvos - 4 months
By @petabyt - 4 months
The most painful thing about this is strings. To convert to/from cstrings, you have to use the stdlib FFI function, which will allocate memory. This was a nice surprise in the form of a bunch of undefined GNU ABI references when linking to C. I was writing bare metal firmware. I hadn't imported libgcc or even libc yet. Having to convert every string and use unsafe blocks everywhere is a pain. And last time I tried it wasn't even possible to interface with a varargs function. Im not a big Zig fan but it looks so much better from a FFI perspective. I haven't tried it but it looks like everything just works.
By @unwind - 5 months
Uh, I get a mostly blank page with a randomly-placed YouTube icon on the right, and no actual text? Wut?

Edit: Firefox on Linux/x64.

By @ngneer - 4 months
Too bad they do not go deeper into impacts on binary image size.
By @smaudet - 5 months
This page came up for me blank...

I had to stick it in brave for it to work. I guess google doesn't make web pages anymore...