Final yr, we wrote about why a reminiscence security technique that focuses on vulnerability prevention in new code shortly yields sturdy and compounding beneficial properties. This yr we take a look at how this method isn’t simply fixing issues, however serving to us transfer quicker.
The 2025 knowledge continues to validate the method, with reminiscence security vulnerabilities falling under 20% of whole vulnerabilities for the primary time.
Up to date knowledge for 2025. This knowledge covers first-party and third-party (open supply) code modifications to the Android platform throughout C, C++, Java, Kotlin, and Rust. This submit is revealed a few months earlier than the tip of 2025, however Android’s industry-standard 90-day patch window implies that these outcomes are very probably near last. We will and can speed up patching when obligatory.
We adopted Rust for its safety and are seeing a 1000x discount in reminiscence security vulnerability density in comparison with Android’s C and C++ code. However the largest shock was Rust’s impression on software program supply. With Rust modifications having a 4x decrease rollback price and spending 25% much less time in code overview, the safer path is now additionally the quicker one.
On this submit, we dig into the info behind this shift and likewise cowl:
- How we’re increasing our attain: We’re pushing to make safe code the default throughout our total software program stack. We’ve updates on Rust adoption in first-party apps, the Linux kernel, and firmware.
- Our first rust reminiscence security vulnerability…nearly: We’ll analyze a near-miss reminiscence security bug in unsafe Rust: the way it occurred, the way it was mitigated, and steps we’re taking to stop recurrence. It’s additionally a very good probability to reply the query “if Rust can have reminiscence questions of safety, why hassle in any respect?”
Creating an working system requires the low-level management and predictability of techniques programming languages like C, C++, and Rust. Whereas Java and Kotlin are essential for Android platform growth, their position is complementary to the techniques languages reasonably than interchangeable. We launched Rust into Android as a direct various to C and C++, providing the same stage of management however with out lots of their dangers. We focus this evaluation on new and actively developed code as a result of our knowledge exhibits this to be an efficient method.
After we take a look at growth in techniques languages (excluding Java and Kotlin), two traits emerge: a steep rise in Rust utilization and a slower however regular decline in new C++.
Web strains of code added: Rust vs. C++, first-party Android code.
This chart focuses on first-party (Google-developed) code (not like the earlier chart that included all first-party and third-party code in Android.) We solely embody techniques languages, C/C++ (which is primarily C++), and Rust.
The chart exhibits that the amount of latest Rust code now rivals that of C++, enabling dependable comparisons of software program growth course of metrics. To measure this, we use the DORA1 framework, a decade-long analysis program that has develop into the {industry} customary for evaluating software program engineering crew efficiency. DORA metrics concentrate on:
- Throughput: the rate of delivering software program modifications.
- Stability: the standard of these modifications.
Cross-language comparisons might be difficult. We use a number of strategies to make sure the comparisons are dependable.
- Comparable sized modifications: Rust and C++ have comparable performance density, although Rust is barely denser. This distinction favors C++, however the comparability remains to be legitimate. We use Gerrit’s change dimension definitions.
- Comparable developer swimming pools: We solely take into account first-party modifications from Android platform builders. Most are software program engineers at Google, and there may be appreciable overlap between swimming pools with many contributing in each.
- Monitor traits over time: As Rust adoption will increase, are metrics altering steadily, accelerating the tempo, or reverting to the imply?
Throughput
Code overview is a time-consuming and high-latency a part of the event course of. Transforming code is a main supply of those expensive delays. Knowledge exhibits that Rust code requires fewer revisions. This development has been constant since 2023. Rust modifications of the same dimension want about 20% fewer revisions than their C++ counterparts.
As well as, Rust modifications presently spend about 25% much less time in code overview in comparison with C++. We speculate that the numerous change in favor of Rust between 2023 and 2024 is because of elevated Rust experience on the Android crew.
Whereas much less rework and quicker code opinions provide modest productiveness beneficial properties, probably the most important enhancements are within the stability and high quality of the modifications.
Stability
Steady and high-quality modifications differentiate Rust. DORA makes use of rollback price for evaluating change stability. Rust’s rollback price could be very low and continues to lower, whilst its adoption in Android surpasses C++.
For medium and enormous modifications, the rollback price of Rust modifications in Android is ~4x decrease than C++. This low rollback price does not simply point out stability; it actively improves general growth throughput. Rollbacks are extremely disruptive to productiveness, introducing organizational friction and mobilizing sources far past the developer who submitted the defective change. Rollbacks necessitate rework and extra code opinions, may result in construct respins, postmortems, and blockage of different groups. Ensuing postmortems typically introduce new safeguards that add much more growth overhead.
In a self-reported survey from 2022, Google software program engineers reported that Rust is each simpler to overview and extra more likely to be appropriate. The laborious knowledge on rollback charges and overview instances validates these impressions.
Placing all of it collectively
Traditionally, safety enhancements typically got here at a price. Extra safety meant extra course of, slower efficiency, or delayed options, forcing trade-offs between safety and different product targets. The shift to Rust is totally different: we’re considerably enhancing safety and key growth effectivity and product stability metrics.
With Rust assist now mature for constructing Android system providers and libraries, we’re centered on bringing its safety and productiveness benefits elsewhere.
- Kernel: Android’s 6.12 Linux kernel is our first kernel with Rust assist enabled and our first manufacturing Rust driver. Extra thrilling initiatives are underway, similar to our ongoing collaboration with Arm and Collabora on a Rust-based kernel-mode GPU driver.
- Firmware: The mix of excessive privilege, efficiency constraints, and restricted applicability of many safety measures makes firmware each high-risk, and difficult to safe. Transferring firmware to Rust can yield a significant enchancment in safety. We’ve been deploying Rust in firmware for years now, and even launched tutorials, coaching, and code for the broader neighborhood. We’re notably enthusiastic about our collaboration with Arm on Rusted Firmware-A.
- First-party purposes: Rust is guaranteeing reminiscence security from the bottom up in a number of security-critical Google purposes, similar to:
- Close by Presence: The protocol for securely and privately discovering native gadgets over Bluetooth is carried out in Rust and is presently operating in Google Play Providers.
- MLS: The protocol for safe RCS messaging is carried out in Rust and shall be included within the Google Messages app in a future launch.
- Chromium: Parsers for PNG, JSON, and net fonts have been changed with memory-safe implementations in Rust, making it simpler for Chromium engineers to cope with knowledge from the net whereas following the Rule of two.
These examples spotlight Rust’s position in lowering safety dangers, however memory-safe languages are just one a part of a complete reminiscence security technique. We proceed to make use of a defense-in-depth method, the worth of which was clearly demonstrated in a latest near-miss.
We not too long ago averted delivery our very first Rust-based reminiscence security vulnerability: a linear buffer overflow in CrabbyAVIF. It was a near-miss. To make sure the patch acquired excessive precedence and was tracked by launch channels, we assigned it the identifier CVE-2025-48530. Whereas it’s nice that the vulnerability by no means made it right into a public launch, the near-miss gives useful classes. The next sections spotlight key takeaways from our postmortem.
Scudo Hardened Allocator for the Win
A key discovering is that Android’s Scudo hardened allocator deterministically rendered this vulnerability non-exploitable because of guard pages surrounding secondary allocations. Whereas Scudo is Android’s default allocator, used on Google Pixel and lots of different gadgets, we proceed to work with companions to make it obligatory. Within the meantime, we are going to challenge CVEs of adequate severity for vulnerabilities that might be prevented by Scudo.
Along with defending towards overflows, Scudo’s use of guard pages helped establish this challenge by altering an overflow from silent reminiscence corruption into a loud crash. Nonetheless, we did uncover a niche in our crash reporting: it failed to obviously present that the crash was a results of an overflow, which slowed down triage and response. This has been fastened, and we now have a transparent sign when overflows happen into Scudo guard pages.
Unsafe Evaluation and Coaching
Working system growth requires unsafe code, usually C, C++, or unsafe Rust (for instance, for FFI and interacting with {hardware}), so merely banning unsafe code isn’t workable. When builders should use unsafe, they need to perceive how to take action soundly and responsibly
To that finish, we’re including a brand new deep dive on unsafe code to our Complete Rust coaching. This new module, presently in growth, goals to show builders easy methods to cause about unsafe Rust code, soundness and undefined conduct, in addition to greatest practices like security feedback and encapsulating unsafe code in protected abstractions.
Higher understanding of unsafe Rust will result in even larger high quality and safer code throughout the open supply software program ecosystem and inside Android. As we’ll focus on within the subsequent part, our unsafe Rust is already actually fairly protected. It’s thrilling to think about simply how excessive the bar can go.
This near-miss inevitably raises the query: “If Rust can have reminiscence security vulnerabilities, then what’s the purpose?”
The purpose is that the density is drastically decrease. A lot decrease that it represents a significant shift in safety posture. Based mostly on our near-miss, we will make a conservative estimate. With roughly 5 million strains of Rust within the Android platform and one potential reminiscence security vulnerability discovered (and glued pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million strains (MLOC).
Our historic knowledge for C and C++ exhibits a density of nearer to 1,000 reminiscence security vulnerabilities per MLOC. Our Rust code is presently monitoring at a density orders of magnitude decrease: a greater than 1000x discount.
Reminiscence security rightfully receives important focus as a result of the vulnerability class is uniquely highly effective and (traditionally) extremely prevalent. Excessive vulnerability density undermines in any other case strong safety design as a result of these flaws might be chained to bypass defenses, together with these particularly focusing on reminiscence security exploits. Considerably reducing vulnerability density doesn’t simply cut back the variety of bugs; it dramatically boosts the effectiveness of our total safety structure.
The first safety concern concerning Rust usually facilities on the roughly 4% of code written inside unsafe{} blocks. This subset of Rust has fueled important hypothesis, misconceptions, and even theories that unsafe Rust could be extra buggy than C. Empirical proof exhibits this to be fairly incorrect.
Our knowledge signifies that even a extra conservative assumption, {that a} line of unsafe Rust is as more likely to have a bug as a line of C or C++, considerably overestimates the danger of unsafe Rust. We don’t know for certain why that is the case, however there are probably a number of contributing elements:
- unsafe{} does not really disable all and even most of Rust’s security checks (a typical false impression).
- The observe of encapsulation permits native reasoning about security invariants.
- The extra scrutiny that unsafe{} blocks obtain.
Traditionally, we needed to settle for a trade-off: mitigating the dangers of reminiscence security defects required substantial investments in static evaluation, runtime mitigations, sandboxing, and reactive patching. This method tried to maneuver quick after which decide up the items afterwards. These layered protections have been important, however they got here at a excessive price to efficiency and developer productiveness, whereas nonetheless offering inadequate assurance.
Whereas C and C++ will persist, and each software program and {hardware} security mechanisms stay essential for layered protection, the transition to Rust is a distinct method the place the safer path can be demonstrably extra environment friendly. As an alternative of transferring quick and then later fixing the mess, we will transfer quicker whereas fixing issues. And who is aware of, as our code will get more and more protected, maybe we will begin to reclaim much more of that efficiency and productiveness that we exchanged for safety, all whereas additionally enhancing safety.
Thanks to the next people for his or her contributions to this submit:
- Ivan Lozano for compiling the detailed postmortem on CVE-2025-48530.
- Chris Ferris for validating the postmortem’s findings and enhancing Scudo’s crash dealing with in consequence.
- Dmytro Hrybenko for main the trouble to develop coaching for unsafe Rust and for offering in depth suggestions on this submit.
- Alex Rebert and Lars Bergstrom for his or her useful recommendations and in depth suggestions on this submit.
- Peter Slatala, Matthew Riley, and Marshall Pierce for offering info on a few of the locations the place Rust is being utilized in Google’s apps.
Lastly, an amazing thanks to the Android Rust crew, and your entire Android group in your relentless dedication to engineering excellence and steady enchancment.
Notes
