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

[Pierre-Clément Tosi]

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.

-- 
Pierre