Memory Safety

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 impact
  user experience, costs, and security.
Figure 1: Memory safety bugs and their negative impact on quality, security, and costs

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 Play Store applications.
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.

Memory safety bugs negatively affect
  security.
Figure 2: Memory safety bugs contribution to Android vulnerabilities

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.

Memory safety bugs negatively affect
  security.
Figure 3: Android memory safety tools landscape

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.