Memory unsafety
Memory safety bugs, errors in handling memory in native programming languages, are the most common issue in the Android codebases. They account for over 60% of high severity security vulnerabilities and for millions of user-visible crashes.
Memory safety bugs negatively impact quality and stability and account for a
significant share of the crashes observed on end user devices. Therefore a high
density of memory safety bugs directly correlates with poor user experience.
Native code, written in memory unsafe languages like C, C++, and Assembly
represent over 70% of the Android platform code and is present in approximately
50% of Google Play Store apps.
Given the ever increasing complexity of code, if left unattended, memory
safety bugs are going to increase over time. Therefore, providing our ecosystem
with the tools and technologies that can detect and mitigate such bugs is
critical to our long term success.
Over the last several years, we have been working closely with our hardware
partners to develop hardware technologies such as Arm Memory Tagging and have
introduced Rust in the Android codebase.
These technologies are going to accelerate our path to memory safety and
are going to help the wider software industry address a key problem area.
Memory safety bugs negatively affect quality
Latent memory safety bugs can cause non-deterministic results, depending on the state of the system. This unpredictable behavior leads to crashes and annoyance for our users.
Every day we observe millions of native crashes from end user devices and
with the introduction of GWP-ASan, we have traced the majority of them to memory
safety bugs.
This data point validates the correlation between quality
and density of memory safety bugs and is in alignment with what our Chrome
colleagues observe (see Chrome GWP-ASan bug hotlist).
Memory safety bugs negatively affect security
Memory safety bugs have consistently been the top contributor to Android security vulnerabilities, going as far back as the first Android release.
While it is encouraging to know that this is not just an Android problem
(see Chrome
and Microsoft
stats), we need to do more for the safety of our users.
The Project Zero team
at Google tracks
zero day exploits that have been used in real attacks against users as zero day
vulnerabilities. These are not hypothetical bugs but exploits actively used in
attacks against users. Memory safety bugs (memory corruption and use-after-free)
comprise an overwhelming majority.
Memory safety bugs increase costs
Keeping devices up to date with security fixes keeps our users safe but comes with a monetary cost to our ecosystem.
The high density of memory safety bugs in low level vendor code, which often has custom modifications, significantly increases the fix and tests costs. However, detecting these bugs early during the development cycle can lower these costs.
Research shows that detecting bugs earlier can reduce costs up to six times. However, given the complexity of our ecosystem, the average number of codebases maintained by a vendor and the ever increasing complexity of software, the savings could be higher.
Memory safety
Starting with Android 12, we've made systemic changes to reduce the density of memory safety bugs in Android codebases. We are extending the Android memory safety tools and introducing new requirements that encourage our ecosystem to address this category of bugs. Over time, these should translate to higher quality and better security for our users and lower costs to our vendors.
Memory safety is likely to become a differentiator for quality and security in the coming years, and Android plans to lead the way.
Requirements in support of memory safety
The Android
Compatibility Definition Document (CDD) strongly recommends the use of
memory safety tools during development.
We are working closely with our ecosystem to increase the use of memory
safety tools and integrate them in the continuous integration and testing
processes.
Over time, we would like to ensure that each device passes a full
Compatibility Test Suite (CTS) run, using memory
safety tools, which demonstrates that no such bugs were found. For example, Arm
v9 platforms will be required to provide a CTS run with Memory Tagging enabled,
whereas Arm v8 platforms will be requested to provide a CTS run using HWASAN and
KASAN.
Rust as a new programming language for platform code
Android 12 introduced Rust as a platform language. Rust provides memory and thread safety at performance levels similar to C/C++. We expect Rust to be the preferred choice for most new native projects. However, rewriting all memory unsafe code, currently representing over 70% of the Android platform code, in Rust isn't feasible. Moving forward Rust will be complementary to memory safety tools.
Memory safety tools
Android supports a wide variety of tools that help detect memory safety bugs. The figure below presents a taxonomy of the available Android memory safety tools.
Our tooling covers a vast range of deployment scenarios and targets. The following documentation describes each tool and provides a reference for using them in your products.