linux-kernel - Re: [PATCH 1/2] x86/split_lock: Don't try to handle user split lock in TDX guest

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] [day] [month] [year] [list]

Message-ID: <qvsi3xht4kn3iwkx5xw2p7zsq4cvpg4xhq3ra52fe34xjpixfo@fsgchsobc343>
Date: Wed, 26 Nov 2025 13:35:31 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: Xiaoyao Li <xiaoyao.li@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>, linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev, 
	kvm@...r.kernel.org, Reinette Chatre <reinette.chatre@...el.com>, 
	Chenyi Qiang <chenyi.qiang@...el.com>, chao.p.peng@...el.com
Subject: Re: [PATCH 1/2] x86/split_lock: Don't try to handle user split lock
 in TDX guest

On Wed, Nov 26, 2025 at 08:17:18PM +0800, Xiaoyao Li wrote:
> On 11/26/2025 7:25 PM, Kiryl Shutsemau wrote:
> > On Wed, Nov 26, 2025 at 06:02:03PM +0800, Xiaoyao Li wrote:
> > > When the host enables split lock detection feature, the split lock from
> > > guests (normal or TDX) triggers #AC. The #AC caused by split lock access
> > > within a normal guest triggers a VM Exit and is handled in the host.
> > > The #AC caused by split lock access within a TDX guest does not trigger
> > > a VM Exit and instead it's delivered to the guest self.
> > > 
> > > The default "warning" mode of handling split lock depends on being able
> > > to temporarily disable detection to recover from the split lock event.
> > > But the MSR that disables detection is not accessible to a guest.
> > > 
> > > This means that TDX guests today can not disable the feature or use
> > > the "warning" mode (which is the default). But, they can use the "fatal"
> > > mode.
> > > 
> > > Force TDX guests to use the "fatal" mode.
> > > 
> > > Signed-off-by: Xiaoyao Li <xiaoyao.li@...el.com>
> > > ---
> > >   arch/x86/kernel/cpu/bus_lock.c | 17 ++++++++++++++++-
> > >   1 file changed, 16 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
> > > index 981f8b1f0792..f278e4ea3dd4 100644
> > > --- a/arch/x86/kernel/cpu/bus_lock.c
> > > +++ b/arch/x86/kernel/cpu/bus_lock.c
> > > @@ -315,9 +315,24 @@ void bus_lock_init(void)
> > >   	wrmsrq(MSR_IA32_DEBUGCTLMSR, val);
> > >   }
> > > +static bool split_lock_fatal(void)
> > > +{
> > > +	if (sld_state == sld_fatal)
> > > +		return true;
> > > +
> > > +	/*
> > > +	 * TDX guests can not disable split lock detection.
> > > +	 * Force them into the fatal behavior.
> > > +	 */
> > > +	if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
> > > +		return true;
> > > +
> > > +	return false;
> > > +}
> > > +
> > >   bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> > >   {
> > > -	if ((regs->flags & X86_EFLAGS_AC) || sld_state == sld_fatal)
> > > +	if ((regs->flags & X86_EFLAGS_AC) || split_lock_fatal())
> > >   		return false;
> > 
> > Maybe it would be cleaner to make it conditional on
> > cpu_model_supports_sld instead of special-casing TDX guest?
> > 
> > #AC on any platfrom when we didn't asked for it suppose to be fatal, no?
> 
> But TDX is the only one has such special non-architectural behavior.
> 
> For example, for normal VMs under KVM, the behavior is x86 architectural.
> MSR_TEST_CTRL is not accessible to normal VMs, and no split lock #AC will be
> delivered to the normal VMs because it's handled by KVM.

How does it contradict what I suggested?

For both normal VMs and TDX guest, cpu_model_supports_sld will not be
set to true. So check for cpu_model_supports_sld here is going to be
NOP, unless #AC actually delivered, like we have in TDX case. Handling
it as fatal is sane behaviour in such case regardless if it TDX.

And we don't need to make the check explicitly about TDX guest.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov