From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Carl Worth <carl@os.amperecomputing.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Taehyun Noh <taehyun@utexas.edu>,
andreyknvl@gmail.com, pcc@google.com, yeoreum.yun@arm.com
Subject: Re: [PATCH 2/2] arm64: mte: Defer disabling of TCO until user_access_begin/end
Date: Thu, 8 Jan 2026 18:45:30 +0000 [thread overview]
Message-ID: <aV_7Sm96Zf1Gfg9v@arm.com> (raw)
In-Reply-To: <aV_H9h-nSM1HlWnR@willie-the-truck>
On Thu, Jan 08, 2026 at 03:06:30PM +0000, Will Deacon wrote:
> On Thu, Oct 30, 2025 at 08:49:32PM -0700, Carl Worth wrote:
> > The PSTATE.TCO (Tag Checking Override) register, when set causes MTE
> > tag checking to be disabled. The TCO bit is automatically set by the
> > hardware when an exception is taken.
> >
> > Prior to this commit, mte_disable_tco_entry would clear TCO (enable
> > tag checking) for either of two cases: 1. When the kernel wants tag
> > checking (KASAN) or 2. when userspace wants tag checking (via
> > SCTLR.TCF0).
> >
> > In the case of userspace desired tag checking, (that is, when KASAN is
> > off), clearing TCO on entry to the kernel has negative performance
> > implications. This results in excess kernel space tag checking that
> > has not been requested.
I would have expected the hardware to avoid any tag checking if
SCTLR_EL1.TCF is 0. I guess the Arm ARM isn't entirely clear (D10.4.1
Tag Checked memory accesses), it seems to only mention TCF and TCMA with
a match-all tag for considering Unchecked accesses.
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 1aa4ecb73429..248741a66c91 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -417,11 +417,41 @@ static __must_check __always_inline bool user_access_begin(const void __user *pt
> > {
> > if (unlikely(!access_ok(ptr,len)))
> > return 0;
> > +
> > + /*
> > + * Enable tag checking for the user access if MTE is enabled
> > + * in the userspace task.
> > + *
> > + * Note: We don't need to do anything if KASAN is enabled,
> > + * since that means the tag checking override (TCO) will
> > + * already be disabled. In turn, the TCF0 bits will control
> > + * whether user-space tag checking happens .
> > + */
> > + if (!kasan_hw_tags_enabled() && user_uses_tagcheck())
> > + asm volatile(SET_PSTATE_TCO(0));
> > +
> > uaccess_ttbr0_enable();
> > return 1;
> > }
>
> What about all the uaccess routines that don't call user_access_begin? For
> example, copy_from_user().
We might as well ignore tag checking for all uaccess for specific
hardware. It's a relaxation but you get this with futex already and some
combination of read/write() syscalls with O_DIRECT.
Reading the Arm ARM section again, I wonder whether always setting TCMA1
does the trick for the Ampere hardware. With KASAN disabled in the
kernel, all addresses will star with 0xff... so behave as match-all. We
do this with KASAN_HW_TAGS enabled but it won't have any effect with
kasan disabled.
Carl, could you please try the patch below?
----------------8<----------------------------------------
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 01e868116448..8b1f0de00fd3 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -48,14 +48,14 @@
#define TCR_KASAN_SW_FLAGS 0
#endif
-#ifdef CONFIG_KASAN_HW_TAGS
-#define TCR_MTE_FLAGS TCR_EL1_TCMA1 | TCR_EL1_TBI1 | TCR_EL1_TBID1
-#elif defined(CONFIG_ARM64_MTE)
+#ifdef CONFIG_ARM64_MTE
/*
* The mte_zero_clear_page_tags() implementation uses DC GZVA, which relies on
- * TBI being enabled at EL1.
+ * TBI being enabled at EL1. TCMA1 is needed to treat accesses with the
+ * match-all tag (0xF) as Tag Unchecked, irrespective of the SCTLR_EL1.TCF
+ * setting.
*/
-#define TCR_MTE_FLAGS TCR_EL1_TBI1 | TCR_EL1_TBID1
+#define TCR_MTE_FLAGS TCR_EL1_TCMA1 | TCR_EL1_TBI1 | TCR_EL1_TBID1
#else
#define TCR_MTE_FLAGS 0
#endif
next prev parent reply other threads:[~2026-01-08 18:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 3:49 [PATCH 0/2] arm64: mte: Improve performance by tightening handling of PSTATE.TCO Carl Worth
2025-10-31 3:49 ` [PATCH 1/2] arm64: mte: Unify kernel MTE policy and manipulation of TCO Carl Worth
2026-01-08 15:05 ` Will Deacon
2026-01-08 16:28 ` Yeoreum Yun
2025-10-31 3:49 ` [PATCH 2/2] arm64: mte: Defer disabling of TCO until user_access_begin/end Carl Worth
2026-01-08 15:06 ` Will Deacon
2026-01-08 18:45 ` Catalin Marinas [this message]
2026-01-08 23:19 ` Carl Worth
2026-01-09 11:40 ` Will Deacon
2026-01-10 5:29 ` Taehyun Noh
2026-01-10 13:02 ` Catalin Marinas
2026-01-14 20:27 ` Carl Worth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aV_7Sm96Zf1Gfg9v@arm.com \
--to=catalin.marinas@arm.com \
--cc=andreyknvl@gmail.com \
--cc=carl@os.amperecomputing.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pcc@google.com \
--cc=taehyun@utexas.edu \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.