Final 12 months, we wrote about why a reminiscence security technique that focuses on vulnerability prevention in new code shortly yields sturdy and compounding beneficial properties. This 12 months we have a look at how this strategy isn’t simply fixing issues, however serving to us transfer quicker.
The 2025 knowledge continues to validate the strategy, 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 adjustments 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 signifies that these outcomes are very doubtless near last. We are able to and can speed up patching when crucial.
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 greatest shock was Rust’s impression on software program supply. With Rust adjustments 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 information 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. Now we have 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 stop recurrence. It’s additionally a very good likelihood to reply the query “if Rust can have reminiscence issues of safety, why hassle in any respect?”
Creating an working system requires the low-level management and predictability of programs programming languages like C, C++, and Rust. Whereas Java and Kotlin are necessary for Android platform improvement, their function is complementary to the programs languages reasonably than interchangeable. We launched Rust into Android as a direct different to C and C++, providing an identical stage of management however with out a lot 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.
Once we have a look at improvement in programs languages (excluding Java and Kotlin), two developments 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 embody programs languages, C/C++ (which is primarily C++), and Rust.
The chart exhibits that the quantity 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 turn into the {industry} customary for evaluating software program engineering group efficiency. DORA metrics concentrate on:
- Throughput: the rate of delivering software program adjustments.
- Stability: the standard of these adjustments.
Cross-language comparisons could be difficult. We use a number of strategies to make sure the comparisons are dependable.
- Comparable sized adjustments: 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 contemplate first-party adjustments 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.
- Observe developments 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. Remodeling code is a main supply of those pricey delays. Information exhibits that Rust code requires fewer revisions. This pattern has been constant since 2023. Rust adjustments of an identical measurement want about 20% fewer revisions than their C++ counterparts.
As well as, Rust adjustments 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 group.
Whereas much less rework and quicker code evaluations provide modest productiveness beneficial properties, probably the most vital enhancements are within the stability and high quality of the adjustments.
Stability
Secure and high-quality adjustments differentiate Rust. DORA makes use of rollback price for evaluating change stability. Rust’s rollback price may be very low and continues to lower, at the same time as its adoption in Android surpasses C++.
For medium and enormous adjustments, the rollback price of Rust adjustments in Android is ~4x decrease than C++. This low rollback price would not simply point out stability; it actively improves general 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, can even 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 arduous knowledge on rollback charges and overview occasions 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 objectives. The shift to Rust is completely different: we’re considerably enhancing 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 tasks are underway, reminiscent of 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 serious enchancment in safety. Now we have 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 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 applied in Rust and is presently working in Google Play Companies.
- MLS: The protocol for safe RCS messaging is applied 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 function 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 lately averted transport our very first Rust-based reminiscence security vulnerability: a linear buffer overflow in CrabbyAVIF. It was a near-miss. To make sure the patch obtained 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 provides invaluable 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 as a result of guard pages surrounding secondary allocations. Whereas Scudo is Android’s default allocator, used on Google Pixel and plenty of different units, we proceed to work with companions to make it obligatory. Within the meantime, we are going to challenge CVEs of ample severity for vulnerabilities that may very well 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 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 Evaluate and Coaching
Working system improvement requires unsafe code, sometimes C, C++, or unsafe Rust (for instance, for FFI and interacting with {hardware}), so merely banning unsafe code is just not 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 improvement, goals to show builders easy methods to cause about unsafe Rust code, soundness and undefined conduct, in addition to finest practices like security feedback and encapsulating unsafe code in protected abstractions.
Higher understanding of unsafe Rust will result in even greater 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 serious shift in safety posture. Based mostly on our near-miss, we are able to 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 presently monitoring at a density orders of magnitude decrease: a greater than 1000x discount.
Reminiscence security rightfully receives vital focus as a result of the vulnerability class is uniquely highly effective and (traditionally) extremely prevalent. Excessive vulnerability density undermines in any other case stable 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 total 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 vital hypothesis, misconceptions, and even theories that unsafe Rust is likely to be extra buggy than C. Empirical proof exhibits this to be fairly unsuitable.
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 chance of unsafe Rust. We don’t know for certain why that is the case, however there are doubtless a number of contributing elements:
- unsafe{} would not truly disable all and even most of Rust’s security checks (a standard 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 strategy tried to maneuver quick after which choose 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 an alternative of shifting quick and then later fixing the mess, we are able to transfer quicker whereas fixing issues. And who is aware of, as our code will get more and more protected, maybe we are able to 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 consequently.
- Dmytro Hrybenko for main the trouble to develop coaching for unsafe Rust and for offering intensive suggestions on this submit.
- Alex Rebert and Lars Bergstrom for his or her invaluable strategies and intensive suggestions on this submit.
- Peter Slatala, Matthew Riley, and Marshall Pierce for offering info on a number of the locations the place Rust is being utilized in Google’s apps.
Lastly, an amazing thanks to the Android Rust group, and your entire Android group to your relentless dedication to engineering excellence and steady enchancment.
Notes
