[MUSIC PLAYING]
SERBAN CONSTANTINESCU: Hi, Android developers,
and welcome to this virtual talk.
My name is Serban Constantinescu,
and I'm a product manager with Android Security.
Today, I'll be talking to you about the Android Memory Safety
Tools, a comprehensive toolkit that
helps improve the quality and security of your application.
Let's start by recapping what memory safety bugs are,
and where they might be present in your code base.
Memory bugs are mistakes in handling memory in native
languages, like C or C++.
They're relatively easy to introduce.
And in this slide, you can see two of their most common forms,
buffer overflow and use after free.
Next, let's take a look at the impact memory bugs have
and the benefits of fixing them.
Every second, end user devices report over 3,000
memory-related crashes.
That's over 7.7 billion crashes each month.
Usually, these crashes are visible to the user
and that makes crashing apps look bad.
Using memory safety tools can help
you reduce bugs and therefore improve the user experience.
Each year, memory bugs contribute to over 60%
of the Android vulnerabilities.
It's not just Android.
Other large native code bases report similar issues.
Fixing memory bugs in our application
is as important as fixing them in the operating system.
It doesn't matter to your users if the operating
system protects their data, but your app does not.
Using memory safety tools can help you achieve
better security for your users.
More than 1/2 of the apps on the Play Store
contain some native code.
Even if your app doesn't include native code directly,
by developing part of your application in native language,
it may include native code indirectly,
part of a third-party SDK or library.
As you will see in the following slides,
detecting and fixing such bugs has never been easier.
Our mission is to help developers
achieve memory safety.
This means being protected from bugs and vulnerabilities
when dealing with memory in native code.
To do so, we have been developing
a set of tools that ease detection and improve developer
productivity.
The journey to memory safety starts by using our tools.
Over the years, we introduced new tools and enhanced existing
ones.
Today, developers can use HWASan, a compiler-based memory
bug detection tool, and GWP-ASan,
an allocator-based probabilistic memory detection tool.
These have been introduced in Android 10 and Android 11
respectively.
In the future with the introduction of new hardware,
developers will be able to use Arm MTE, hardware-based memory
bug detection tool that we have been
co-developing in collaboration with [INAUDIBLE]..
While this hardware technology makes its way
to Android devices, we strongly recommend
application developers familiarize themselves
with HWASan and GWP-ASan, and thus enable
a smoother transition when compatible devices become
available.
HWASan has been available since Android 10.
It detects all type of memory bugs,
including stack, global, and hip issues.
It requires recompilation as it functions
by introducing extra code around all memory operations.
Therefore, its performance is not
suited for deployment in production,
being around two times slower.
However, we recommend using HWASan
in development and testing.
It requires flashing your HWASan build on your test device
and recompiling your code with -fsanitize=hwaddress.
We maintain HWASan builds for most Pixel devices.
And while their performance might not
be suited for deployment in production,
it is certainly good enough for testing.
Internally, we use HWASan builds for dogfooding new Pixel
devices.
For more information, please check the link on this slide.
In Android 11, we introduce the probabilistic memory detection
program.
By probabilistic, we mean that we randomly
got certain hip allocations.
This strikes a balance between performance
and the chance of any single run catching a bug.
In some ways, this looks like a lottery system
where we increase our chances of detecting
a bug as the number of devices running our code base
increases.
GWP-ASan does not require recompilation
and its performance is well suited for production.
We strongly recommend using GWP-ASan everywhere,
from the early days of development, all the way
to testing and production.
It is as simple as adding "gwpAsanMode"
to your Android manifest file.
For more information, please check the link on this slide.
Once you enable the memory safety tools,
you should exercise as many code paths as possible.
Bugs generate logcat and tombstone traces,
which can be used for local debugging.
In production, the reports are exported off device
to the Play developer console.
In Android 12, we introduced a new tombstone API
that allows developers to extract more crash information
on the next app start.
We are also excited to announce that we have been working
with Firebase to introduce support for memory safety
tools in Crashlytics.
This is expected to become available later this year.
When using memory safety tools, bug reports
contain additional information that can help with debugging.
Besides the offending backtrace, we
include allocation and deallocation backtraces,
which can be extremely helpful in finding
the root cause of a bug.
We have been using the same tools internally
to develop the Android operating system to help us detect
numerous bugs that have been latent in our code base
for many years.
The tools significantly improved our ability to detect bugs,
and the enhanced bug reports sped up our fix time.
With that, I'd like to quickly recap
what was discussed in this presentation.
The Android memory safety tools detect
memory bugs in your code base.
Fixing this improves quality and security.
The recipe for memory safety is, use memory safety tools,
run your code and find bugs, fix those bugs.
I look forward to developers using our tools
and improving the quality and security of our ecosystem.
If you encounter any issues or have any feedback,
please reach out by filing a bug at the link provided below.
Thank you for your time.
[MUSIC PLAYING]