Final yr, we wrote about why a reminiscence security technique that focuses on vulnerability prevention in new code shortly yields sturdy and compounding features. This yr we have a look at how this strategy isn’t simply fixing issues, however serving to us transfer sooner.
The 2025 knowledge continues to validate the strategy, with reminiscence security vulnerabilities falling under 20% of complete 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 put up is printed a few months earlier than the top of 2025, however Android’s industry-standard 90-day patch window signifies that these outcomes are very probably near closing. We are able to and can speed up patching when needed.
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 influence on software program supply. With Rust modifications having a 4x decrease rollback charge and spending 25% much less time in code overview, the safer path is now additionally the sooner one.
On this put up, 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 whole software program stack. We’ve updates on Rust adoption in first-party apps, the Linux kernel, and firmware.
- Our first rust reminiscence security vulnerability…virtually: 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 forestall recurrence. It’s additionally a very good probability to reply the query “if Rust can have reminiscence issues of safety, why trouble in any respect?”
Growing 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 improvement, their position is complementary to the techniques languages fairly than interchangeable. We launched Rust into Android as a direct different to C and C++, providing an analogous 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 strategy.
After we have a look at improvement 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 traces of code added: Rust vs. C++, first-party Android code.
This chart focuses on first-party (Google-developed) code (in contrast to the earlier chart that included all first-party and third-party code in Android.) We solely embrace techniques languages, C/C++ (which is primarily C++), and Rust.
The chart exhibits that the amount of recent Rust code now rivals that of C++, enabling dependable comparisons of software program improvement course of metrics. To measure this, we use the DORA1 framework, a decade-long analysis program that has grow to be the {industry} customary for evaluating software program engineering staff efficiency. DORA metrics give attention to:
- Throughput: the rate of delivering software program modifications.
- Stability: the standard of these modifications.
Cross-language comparisons could be difficult. We use a number of methods 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 measurement 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 major supply of those pricey delays. Information exhibits that Rust code requires fewer revisions. This development has been constant since 2023. Rust modifications of an analogous measurement want about 20% fewer revisions than their C++ counterparts.
As well as, Rust modifications at present 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 staff.
Whereas much less rework and sooner code evaluations provide modest productiveness features, 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 charge for evaluating change stability. Rust’s rollback charge may be very low and continues to lower, whilst its adoption in Android surpasses C++.
For medium and huge modifications, the rollback charge of Rust modifications in Android is ~4x decrease than C++. This low rollback charge does not simply point out stability; it actively improves total improvement throughput. Rollbacks are extremely disruptive to productiveness, introducing organizational friction and mobilizing assets far past the developer who submitted the defective change. Rollbacks necessitate rework and extra code evaluations, may result in construct respins, postmortems, and blockage of different groups. Ensuing postmortems typically introduce new safeguards that add much more improvement overhead.
In a self-reported survey from 2022, Google software program engineers reported that Rust is each simpler to overview and extra prone to be right. 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 value. 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 bettering safety and key improvement 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, reminiscent of our ongoing collaboration with Arm and Collabora on a Rust-based kernel-mode GPU driver.
- Firmware: The mixture of excessive privilege, efficiency constraints, and restricted applicability of many safety measures makes firmware each high-risk, and difficult to safe. Shifting firmware to Rust can yield a serious 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 significantly enthusiastic about our collaboration with Arm on Rusted Firmware-A.
- First-party functions: Rust is making certain reminiscence security from the bottom up in a number of security-critical Google functions, reminiscent of:
- Close by Presence: The protocol for securely and privately discovering native units over Bluetooth is carried out in Rust and is at present operating in Google Play Companies.
- MLS: The protocol for safe RCS messaging is carried out in Rust and might 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 decreasing 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 strategy, the worth of which was clearly demonstrated in a current 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 way of 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 affords 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 resulting from guard pages surrounding secondary allocations. Whereas Scudo is Android’s default allocator, used on Google Pixel and lots of different units, we proceed to work with companions to make it necessary. Within the meantime, we are going to subject CVEs of ample severity for vulnerabilities that might be prevented by Scudo.
Along with defending towards overflows, Scudo’s use of guard pages helped establish this subject by altering an overflow from silent reminiscence corruption into a loud crash. Nevertheless, we did uncover a spot 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 mounted, and we now have a transparent sign when overflows happen into Scudo guard pages.
Unsafe Overview and Coaching
Working system improvement requires unsafe code, usually C, C++, or unsafe Rust (for instance, for FFI and interacting with {hardware}), so merely banning unsafe code just 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, at present in improvement, goals to show builders find out how to motive about unsafe Rust code, soundness and undefined conduct, in addition to greatest practices like security feedback and encapsulating unsafe code in secure 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 secure. 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 serious shift in safety posture. Primarily based on our near-miss, we will make a conservative estimate. With roughly 5 million traces of Rust within the Android platform and one potential reminiscence security vulnerability discovered (and stuck pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million traces (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 at present 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 could be chained to bypass defenses, together with these particularly focusing on reminiscence security exploits. Considerably reducing vulnerability density doesn’t simply scale back the variety of bugs; it dramatically boosts the effectiveness of our whole safety structure.
The first safety concern concerning Rust typically 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 is perhaps extra buggy than C. Empirical proof exhibits this to be fairly mistaken.
Our knowledge signifies that even a extra conservative assumption, {that a} line of unsafe Rust is as prone to have a bug as a line of C or C++, considerably overestimates the danger of unsafe Rust. We don’t know for positive why that is the case, however there are probably a number of contributing components:
- unsafe{} does not truly disable all and even most of Rust’s security checks (a typical false impression).
- The follow 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 strategy 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 important for layered protection, the transition to Rust is a unique strategy the place the safer path can be demonstrably extra environment friendly. As a substitute of transferring quick and then later fixing the mess, we will transfer sooner whereas fixing issues. And who is aware of, as our code will get more and more secure, maybe we will begin to reclaim much more of that efficiency and productiveness that we exchanged for safety, all whereas additionally bettering safety.
Thanks to the next people for his or her contributions to this put up:
- Ivan Lozano for compiling the detailed postmortem on CVE-2025-48530.
- Chris Ferris for validating the postmortem’s findings and bettering Scudo’s crash dealing with consequently.
- Dmytro Hrybenko for main the hassle to develop coaching for unsafe Rust and for offering intensive suggestions on this put up.
- Alex Rebert and Lars Bergstrom for his or her useful recommendations and intensive suggestions on this put up.
- Peter Slatala, Matthew Riley, and Marshall Pierce for offering data on among the locations the place Rust is being utilized in Google’s apps.
Lastly, an amazing thanks to the Android Rust staff, and the complete Android group in your relentless dedication to engineering excellence and steady enchancment.
Notes
