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: <lvobu4gpfsjg63syubgy2jwcja72folflrst7bu2eqv6rhaqre@ttbkykphu32f>
Date: Wed, 26 Nov 2025 11:25:43 +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 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?

>  	split_lock_warn(regs->ip);
>  	return true;
> -- 
> 2.43.0
> 

-- 
  Kiryl Shutsemau / Kirill A. Shutemov