MTE can be enabled independently in the Android kernel and in any
process in the Android system. Google doesn't mandate any specific
configuration and aims to provide maximum flexibility to the device
builders.
This document describes MTE settings and scope that, in our opinion,
provides a good trade-off between security and cost for Android
users as always-on vulnerability mitigation.
Kernel
MTE in the kernel is configured through the command line. The
default is ON in Sync mode. This is subject to future change for
several reasons:
-
It has been shown to significantly affect performance and needs
optimization work.
-
Kernel code quality is widely perceived to be insufficient to ship
MTE in the enforcing (that is, panic-on-failure) mode.
The current recommendation is to
disable kernel MTE
on
production devices. To do this, add
kasan=off
to the
kernel command line.
Userspace
Google provides a default list of userspace binaries to be protected
with MTE. The list was composed with the input from Android Security
and includes components that are privileged and/or handle untrusted
inputs. The up-to-date list of native binaries that are recommended
with MTE can be found in
the
memtag-common.mk
file in the Android build
system. Additionally,
several
system apps
are included as well: currently, Nfc,
Bluetooth and SecureElement. These binaries and apps are
enabled in Async mode by default.
The current recommendation is to
use the default target list
(no changes required). Additionally, it is recommended to evaluate
BSP and OEM additions to the core system and enable MTE on the ones
that are security-sensitive.
Apps
The three system apps listed above are the only ones using
MTE at this time. In order for a third party app to enable
MTE, its
AndroidManifest.xml
would need to specify
android:memtagMode
with a value other
than
off
. Thus, common benchmark suites such as
Geekbench or AnTuTu do not run with MTE. If kernel MTE is also
disabled (see
kasan=off
above), then the benchmarks are
expected to show very limited performance impact, if any at all.
As for the other apps, there is active development of MTE support in
Chrome. Current Play Store version of Chrome includes
memtagMode=async
setting in the manifest. It is also our expectation
that a number of security-conscious apps in the Android ecosystem
(for example, banking apps) would do the same eventually. On the
other hand, we expect that some apps that demand peak CPU
performance such as games will choose to keep MTE disabled.
Other modes
The above instructions use only Asynchronous MTE mode
everywhere. Depending on the hardware, other modes may be almost, or
exactly as fast. They also provide better diagnostics and somewhat
stronger vulnerability mitigation properties.
We recommend testing one or two other configurations to see if they
are good enough for your performance/power requirements. MTE modes
can be set for each CPU core in the system by writing to
/sys/devices/system/cpu/cpu*/mte_tcf_preferred
. For example, writing
sync
(or
asymm
) would cause any userspace process that has requested
Async mode to be silently auto-upgraded to Sync (or Asymm) while
running on that core. This setup can be done in a .rc file at device
boot time.
We recommend measuring one or two other configurations to check if
they satisfy your performance and power requirements. Some
interesting configurations to explore:
-
Asymm
on all cores.
-
Asymm
on large core(s),
Sync
on other cores.
To verify that a process is requesting Async mode (with possible
auto-upgrade), check that the following line includes both
PR_MTE_TCF_SYNC
and
PR_MTE_TCF_ASYNC
:
debuggerd
| head -30 | grep tagged_addr
Unfortunately, there is no easy way to see the effective mode for a
process; but any process that shows both values listed above is
subject to the auto-upgrade behavior.