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

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

[Pierre-Clément Tosi]

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.

Implement it as a software-only feature override, similar to nokaslr.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 3 +++
 arch/arm64/include/asm/cpufeature.h             | 1 +
 arch/arm64/kernel/cpufeature.c                  | 8 ++++++++
 arch/arm64/kernel/pi/idreg-override.c           | 2 ++
 4 files changed, 14 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0869294363b3..4d138c1826f0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -564,6 +564,9 @@ Kernel parameters
 	arm64.nomte	[ARM64] Unconditionally disable Memory Tagging Extension
 			support
 
+	arm64.nomte_el0	[ARM64] Unconditionally disable Memory Tagging Extension
+			support for userspace
+
 	arm64.nopauth	[ARM64] Unconditionally disable Pointer Authentication
 			support
 
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 4de51f8d92cb..0944ff5084a2 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -18,6 +18,7 @@
 #define ARM64_SW_FEATURE_OVERRIDE_NOKASLR	0
 #define ARM64_SW_FEATURE_OVERRIDE_HVHE		4
 #define ARM64_SW_FEATURE_OVERRIDE_RODATA_OFF	8
+#define ARM64_SW_FEATURE_OVERRIDE_NOMTE_EL0	12
 
 #ifndef __ASSEMBLER__
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6044d463d3fb..81ea00050e56 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2412,6 +2412,14 @@ static void user_feature_fixup(void)
 		if (regp)
 			regp->user_mask &= ~ID_AA64PFR1_EL1_SSBS_MASK;
 	}
+
+	if (arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_NOMTE_EL0)) {
+		struct arm64_ftr_reg *regp;
+
+		regp = get_arm64_ftr_reg(SYS_ID_AA64PFR1_EL1);
+		if (regp)
+			regp->user_mask &= ~ID_AA64PFR1_EL1_MTE_MASK;
+	}
 }
 
 static void elf_hwcap_fixup(void)
diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index bc57b290e5e7..758141bf9e37 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -211,6 +211,7 @@ static const struct ftr_set_desc sw_features __prel64_initconst = {
 		FIELD("nokaslr", ARM64_SW_FEATURE_OVERRIDE_NOKASLR, NULL),
 		FIELD("hvhe", ARM64_SW_FEATURE_OVERRIDE_HVHE, hvhe_filter),
 		FIELD("rodataoff", ARM64_SW_FEATURE_OVERRIDE_RODATA_OFF, NULL),
+		FIELD("nomte_el0", ARM64_SW_FEATURE_OVERRIDE_NOMTE_EL0, NULL),
 		{}
 	},
 };
@@ -244,6 +245,7 @@ static const struct {
 	  "id_aa64isar2.gpa3=0 id_aa64isar2.apa3=0"	   },
 	{ "arm64.nomops",		"id_aa64isar2.mops=0" },
 	{ "arm64.nomte",		"id_aa64pfr1.mte=0" },
+	{ "arm64.nomte_el0",		"arm64_sw.nomte_el0=1" },
 	{ "nokaslr",			"arm64_sw.nokaslr=1" },
 	{ "rodata=off",			"arm64_sw.rodataoff=1" },
 	{ "arm64.nolva",		"id_aa64mmfr2.varange=0" },
-- 
2.53.0.273.g2a3d683680-goog


-- 
Pierre

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

[Catalin Marinas]

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.

-- 
Catalin

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

[Pierre-Clément Tosi]

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

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

[Will Deacon]

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...

Will

Re: [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

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

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

[Marc Zyngier]

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.