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 <PID> | 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.