linux-kernel - Re: [PATCH 2/2] arm64: mte: Defer disabling of TCO until user_access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWDpSNFnZC2nj4KS@willie-the-truck>
Date: Fri, 9 Jan 2026 11:40:56 +0000
From: Will Deacon <will@...nel.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Carl Worth <carl@...amperecomputing.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Taehyun Noh <taehyun@...xas.edu>, andreyknvl@...il.com,
	pcc@...gle.com, yeoreum.yun@....com
Subject: Re: [PATCH 2/2] arm64: mte: Defer disabling of TCO until
 user_access_begin/end

On Thu, Jan 08, 2026 at 06:45:30PM +0000, Catalin Marinas wrote:
> 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.

Hmm, you could argue it's an ABI break, no? You can write a userspace
program that will behave differently before and after the change.
Conversely, you could argue that a syscall using uaccess is an
unstable implementation detail of the syscall, but it feels a bit fragile
(for example, signal delivery is always going to use the uaccess routines
to access the signal stack)

Will