Why Google Is Betting the Android Bootloader on Rust?

For most of Android’s existence, the software that boots your phone has been written in C — a language designed in the 1970s that gives programmers complete control over memory and almost zero protection from getting it wrong. A misplaced pointer or an off-by-one buffer calculation can open a door that attackers walk straight through. Google has spent years patching these holes. Now it has decided to stop digging them in the first place.

The strategy is straightforward: replace C and C++ in the most sensitive parts of the Android stack — starting with new code and firmware — with Rust, a systems programming language that enforces memory safety at compile time. The bootloader and firmware layer is the first critical target, and the results published through late 2025 suggest the bet is paying off.

The Problem with C at Boot Time

When an Android device powers on, the bootloader is the first significant piece of software that runs. It verifies the integrity of the operating system, sets up the hardware environment, and hands control to the Linux kernel. Because it operates before any OS-level security is active, a vulnerability here is about as dangerous as it gets — an attacker who can exploit bootloader code potentially owns the device before Android’s defenses ever wake up.

Bootloaders have historically been written in C for good reason: the language maps directly to hardware, has no runtime overhead, and tooling for it exists on every architecture Android supports. But C’s power comes without guardrails. Memory safety bugs — buffer overflows, use-after-free errors, null-pointer dereferences — are not caught by the compiler. They become bugs, and bugs at this level become exploits.

Google’s own data showed that in 2019, memory safety issues accounted for 76 % of Android’s reported vulnerabilities. Patching them was expensive, slow, and reactive. The company began searching for a structural solution.

Why Rust — and Why Now?

Rust was designed with one core promise: memory safety without a garbage collector. Its ownership and borrowing system ensures that entire classes of memory errors — the ones that cause most of Android’s high-severity CVEs — are rejected at compile time. Code that would silently corrupt memory in C simply does not compile in Rust.

Google formally added Rust to the Android Open Source Project in April 2021, initially focusing new code rather than rewriting existing stable C libraries. This was a deliberate choice: research showed that most vulnerabilities live in new or recently modified code, with roughly half of all bugs being less than a year old. Rewriting mature, battle-tested C code offered little benefit compared to ensuring all new code was safe from the start.

The US Cybersecurity & Infrastructure Security Agency (CISA) has independently urged software vendors to treat eliminating memory safety vulnerabilities as a top-level company goal, lending government weight to the direction Google was already heading.

The Bootloader Rewrite: pVM Firmware as the Template

The most concrete example of Rust’s use at the boot layer involves Android’s Virtualization Framework (AVF). Google needed firmware for protected virtual machines — pVM — that would serve as a root of trust, analogous to how a bootloader validates the OS. The original implementation was built on top of U-Boot, a widely used open-source bootloader written in C.

The problem, as Google engineer Andrew Walbran stated publicly, was that U-Boot “was not designed with security in a hostile environment in mind.” Google found and patched specific memory-safety issues in U-Boot, but recognized that in a security-critical role, finding bugs after the fact wasn’t good enough. The pVM firmware was rewritten entirely in Rust, providing a memory-safe foundation for the root of trust.

This firmware performs functionally the same role as a bootloader — verifying integrity before handing off execution — making it the clearest demonstration yet of Rust operating at the bare-metal boot level in Android.

What Has Already Been Rewritten

The bootloader firmware is not the only component that has migrated. Google has been systematically introducing Rust across Android’s most sensitive subsystems over the past four years:

The Numbers Don’t Lie

The measurable impact of this strategy has been striking. Memory safety vulnerabilities in Android dropped from 223 in 2019 to fewer than 50 in 2024. By November 2025, Google reported that memory safety bugs had fallen below 20 % of total Android vulnerabilities for the first time — compared to the 70 %+ industry norm that still plagues most software ecosystems.

Crucially, this improvement was achieved without mass-rewriting existing stable C code. The decline is driven almost entirely by ensuring that new code is written in Rust. Vulnerability density in Rust-written code is approximately 1,000 times lower than in equivalent C/C++ code, according to Google’s internal analysis.

Addressing the “Unsafe Rust” Question

Rust has an escape hatch: unsafe blocks, where programmers can bypass the language’s safety guarantees to do things like raw pointer arithmetic required for hardware interaction. Critics of Rust’s role in bootloader and firmware code have pointed to this as a potential gap.

Google addressed this directly in its November 2025 security blog post, disclosing what it called a “near-miss” — a linear buffer overflow found in unsafe Rust code in Pixel’s driver customization layer. The vulnerability was patched in the August 2025 Android security update. But Google’s analysis found the bug was rendered non-exploitable in practice by Scudo, Android’s dynamic memory allocator designed to mitigate heap vulnerabilities. The conclusion: even unsafe Rust has significantly lower vulnerability density than C/C++, because the unsafe surface area is small, explicitly marked, and surrounded by safe code that constrains what can go wrong.

What Comes Next

Google has stated its intention to continue expanding Rust across the Android stack, with the Linux kernel, additional firmware components, and high-exposure first-party apps — including Nearby Presence and Message Layer Security (MLS) — all on the roadmap.

The bootloader work establishes a template: identify a C component operating in a hostile environment, understand its security role, and rewrite it in Rust with security as the primary design constraint. The pVM firmware rewrite showed this is achievable at the lowest level of the stack. Future bootloader iterations for new Pixel hardware and reference Android devices are expected to follow the same pattern.

The broader signal is that Google no longer treats memory safety as a problem to manage after the fact — it treats it as something to be eliminated by design, one component at a time, starting at the point where Android is most vulnerable: before the OS even loads.