linux-kernel - [PATCH 0/2] x86/split_lock: Fix and enhancement for 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-next>] [day] [month] [year] [list]

Message-ID: <20251126100205.1729391-1-xiaoyao.li@intel.com>
Date: Wed, 26 Nov 2025 18:02:02 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Kiryl Shutsemau <kas@...nel.org>
Cc: 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,
	xiaoyao.li@...el.com
Subject: [PATCH 0/2] x86/split_lock: Fix and enhancement for TDX guest

Running a split lock test[1] inside a TDX guest under KVM triggers the
warning below. The test hangs but can be terminated.

  x86/split lock detection: #AC: split_lock/1176 took a split_lock trap at address: 0x5630b30921f9
  unchecked MSR access error: WRMSR to 0x33 (tried to write 0x0000000000000000) at rIP: 0xffffffff812a061f (native_write_msr+0xf/0x30)
  Call Trace:
  handle_user_split_lock
  exc_alignment_check
  asm_exc_alignment_check

It turns out that split lock detection is enabled (by the host) when the
TDX vCPU is running, and #AC is not intercepted but delivered directly to
the TDX guest. The default "warning" mode of split lock #AC handler in
the guest tries to handle the split lock by temporarily disabling
detection. However, the MSR that disables detection is not accessible to
a guest.

Patch 1 forces the TDX guest to always treat the split lock #AC as the
"fatal" mode. This prevents the TDX guest from attempting invalid MSR
writes.

Patch 2 enhances the sld_state_show() to indicate that the TDX guest can
receive #AC on split locks depending on the host's split lock detection
configuration.

Note that all the split lock issues on TDX guests are due to the
non-architectural behavior of TDX: a TDX guest can receive #AC even
though the split lock detection feature is not available and the
relevant MSR is not accessible.

One option is to make the behavior architectural for TDX guests by not
delivering the (unexpected) #AC to the TDX guest and letting the host
handle it instead. This is exactly how KVM handles split lock #AC for
normal VMs. This option also has the advantage that the TDX guest can
survive from split locks when the host mode is not fatal.

However, this option cannot replace current patches because it changes
the behavior of current TDX and would need to be opted-in by the host VMM
for compatibility. More importantly, it would be a new feature available
only in newer TDX modules, which means all existing TDX modules
cannot benefit from it.

We list the option here as an open to solicit feedback and determine
whether to pursue adding such feature to TDX module.

[1] https://github.com/xiaoyaoli-intel/splitlock/blob/main/splitlock.c

Xiaoyao Li (2):
  x86/split_lock: Don't try to handle user split lock in TDX guest
  x86/split_lock: Describe #AC handling in TDX guest kernel log

 arch/x86/kernel/cpu/bus_lock.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

base-commit: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d
-- 
2.43.0