linux-kernel - Re: [PATCH v2] x86/split_lock: Handle unexpected split lock as fatal

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: <olldkto6daapizzo3clcos7mey3tbusojbzjluy3rlve5li42e@ialbymvgebka>
Date: Wed, 7 Jan 2026 15:20:20 +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>, reinette.chatre@...el.com, 
	rick.p.edgecombe@...el.com, linux-kernel@...r.kernel.org, chenyi.qiang@...el.com, 
	chao.p.peng@...el.com
Subject: Re: [PATCH v2] x86/split_lock: Handle unexpected split lock as fatal

On Wed, Jan 07, 2026 at 09:49:55PM +0800, Xiaoyao Li wrote:
> The kernel can receive #AC fault on split lock access even when
> X86_FEATURE_SPLIT_LOCK_DETECT is not enumerated. For example, this can
> occur with a TDX guest running under a Linux host with split lock
> detection enabled.
> 
> The default "warning" mode of handling user split lock depends on being
> able to temporarily disable detection to recover from the split lock event.
> However, when X86_FEATURE_SPLIT_LOCK_DETECT is not enumerated, the MSR
> or the bit that disables detection is normally not accessible. This means
> the feature cannot be disabled and the "warning" mode will not work. The
> "fatal" mode, however, can still work properly.
> 
> Handle split locks as fatal in such cases.
> 
> Signed-off-by: Xiaoyao Li <xiaoyao.li@...el.com>
> ---
> Changes in v2:
> - handle it generally instead of special-casing TDX guest; [Kiryl]
> 
> v1: https://lore.kernel.org/all/20251126100205.1729391-1-xiaoyao.li@intel.com/
> 
> Notes:
> - Kiryl suggested to check cpu_model_supports_sld in v1, while this v2
>   checks X86_FEATURE_SPLIT_LOCK_DETECT. Because I found the latter can
>   cover the purpose of the former in current kernel. I also sent a patch
>   separately to clean up cpu_model_supports_sld. [1]
> 
> - Patch 2 of v1 is dropped in this v2, since v2 is not TDX specific
>   anymore. If anyone has interest on whether to enhance sld_state_show()
>   to call out the potential unexpected #AC behavior for TDX guest or
>   for more general cases, we can discuss here.
> 
> [1] https://lore.kernel.org/all/20251218080044.2615106-1-xiaoyao.li@intel.com/
> ---
>  arch/x86/kernel/cpu/bus_lock.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
> index dbc99a47be45..68721f1a2cb0 100644
> --- a/arch/x86/kernel/cpu/bus_lock.c
> +++ b/arch/x86/kernel/cpu/bus_lock.c
> @@ -316,9 +316,25 @@ void bus_lock_init(void)
>  	wrmsrq(MSR_IA32_DEBUGCTLMSR, val);
>  }
>  
> +static bool split_lock_fatal(void)
> +{
> +	/*
> +	 * If #AC occurs on split lock without X86_FEATURE_SPLIT_LOCK_DETECT
> +	 * the kernel cannot handle it by disabling the detection. Treat it as
> +	 * fatal regardless of the sld_state.
> +	 */

Nit: maybe some context here on why it is even possible.

Otherwise:

Acked-by: Kiryl Shutsemau <kas@...nel.org>

-- 
  Kiryl Shutsemau / Kirill A. Shutemov