[PATCH] arm64: Optionally disable EL0 MTE via command-line
Pierre-Clément Tosi
ptosi at google.com
Tue Feb 17 03:20:02 PST 2026
Hi Catalin,
On Tue, Feb 17, 2026 at 10:51:24AM +0000, Catalin Marinas wrote:
> On Fri, Feb 13, 2026 at 12:51:07PM +0100, Pierre-Clément Tosi wrote:
> > Although it is currently possible to fully disable MTE on MTE-capable
> > CPUs (with arm64.nomte or id_aa64pfr1.mte=0) and to only use MTE in
> > userspace (with kasan=off), there is no way to limit the use of MTE to
> > the kernel because CPU capabilities are traditionally exposed directly
> > to userspace.
> >
> > To address this, introduce a new cmdline argument (inspired by the
> > existing arm64.nomte) to only expose the MTE capability of the CPU to
> > the kernel. Combined with KASAN, this results in only the kernel using
> > the feature, while HWCAP2_MTE and the corresponding MSR ID_AA64PFR1_EL1
> > field are hidden from userspace.
> [...]
> > + arm64.nomte_el0 [ARM64] Unconditionally disable Memory Tagging Extension
> > + support for userspace
>
> Why would we need this? It's a user-space choice whether it uses MTE or
> not. It's not like the kernel is forcing it onto the user processes.
Correct. This patch is useful when working with a pre-compiled distribution to
ensure that a MTE-enabled userspace falls back to untagged allocations, without
the need to introduce system-wide policies (and ABIs) for said distribution,
which would also be inherently less robust than this kernel-level gating.
In Android, we can simply append the flag to the kernel cmdline instead of
relying on sysprops (or similar early userspace concepts) and hoping that all
users are properly gated on that sysprop, etc. This can be used for A/B testing
of the feature or as a highly-reliable "remote kill switch", for example.
I should have mentioned this in the commit message and will in an eventual v2.
>
> --
> Catalin
--
Pierre
More information about the linux-arm-kernel
mailing list