Re: [PATCH] arm64: Optionally disable EL0 MTE via command-line

[Will Deacon]

On Tue, Feb 17, 2026 at 01:31:49PM +0100, Pierre-Clément Tosi wrote:
> On Tue, Feb 17, 2026 at 12:03:01PM +0000, Will Deacon wrote:
> > On Tue, Feb 17, 2026 at 12:20:02PM +0100, Pierre-Clément Tosi wrote:
> > > 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.
> > 
> > Why isn't arm64.nomte sufficient for that? It seems weird to insist on
> > tag-based KASAN support for the purposes of userspace A/B testing...
> 
> For a given architecture (and product goals), profiling of MTE might lead to the
> performance overhead being acceptable in the kernel - where security concerns
> are more prominent - but not in userspace, resulting in tag-based KASAN being
> required while a robust switch is needed to disable MTE in userspace but
> arm64.nomte is too coarse for that.

Then tell userspace not to use it? As Catalin pointed out, the kernel
doesn't force MTE on for userspace.

So the existing kernel cmdline option solve your A/B testing scenario
and I would've thought you could use SECCOMP to block the relevant
prctl()s if userspace isn't doing what you want.

Also, using MTE as a security feature is a joke.

Will