MTE Configuration

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 applications are included as well: currently, Nfc, Bluetooth and SecureElement. These binaries and applications 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.

Applications

The three system applications listed above are the only ones using MTE at this time. In order for a third party application 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 applications 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.