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

[Marc Zyngier <maz@kernel.org>]

On Tue, 17 Feb 2026 11:20:02 +0000,
Pierre-Clément Tosi <ptosi@google.com> 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.
> 
> I should have mentioned this in the commit message and will in an eventual v2.

What I find odd is that nothing seems to enforce this "disabled at
EL0" behaviour. It is not advertised, but crucially SCTLR_EL1.ATA0
appears to be set.

	M.

-- 
Without deviation from the norm, progress is not possible.