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 for Android: free password hash cracker in your pocket

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

Message-ID: <6105befe-cb9c-45d3-8536-c0aab63e1b57@intel.com>
Date: Fri, 28 Nov 2025 10:40:14 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>, kas@...nel.org
Cc: bp@...en8.de, chao.p.peng@...el.com, chenyi.qiang@...el.com,
 dave.hansen@...ux.intel.com, hpa@...or.com, kvm@...r.kernel.org,
 linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org, mingo@...hat.com,
 reinette.chatre@...el.com, rick.p.edgecombe@...el.com, tglx@...utronix.de,
 x86@...nel.org
Subject: Re: [PATCH 1/2] x86/split_lock: Don't try to handle user split lock
 in TDX guest

Hi Andrew,

On 11/28/2025 12:55 AM, Andrew Cooper wrote:
>> I am not sure. Leaving it as produces produces false messages which is
>> not good, but not critical.
>>
>> Maybe just clear X86_FEATURE_BUS_LOCK_DETECT and stop pretending we
>> control split-lock behaviour from the guest?
> 
> (Having just played with this mess for another task) you're talking
> about two different things.
> 
> Sapphire Rapids has an architectural BUS_LOCK_DETECT (trap semantics,
> #DB or VMExit), and a model-specific BUS_LOCK_DISABLE.
> 
> It's BUS_LOCK_DISABLE which generates #AC, with fault semantics,
> preventing forward progress.  It also means the Bus Lock didn't happen,
> and there's nothing to trigger the BUS_LOCK_DETECT (trap) behaviour.
> 
> Given that TDX is enabling BUS_LOCK_DISABLE, it's probably also enabling
> UC_LOCK_DISABLE (causes #GP) too.

Well, more accurate, it's SPLIT_LOCK_DISABLE, not BUS_LOCK_DISABLE.(bus 
lock have two types: split lock and uc lock)

No, it's not TDX who is enabling SPLIT_LOCK_DISABLE, but the host. The 
default mode of Linux is "warn", so that by default the host Linux 
enables SPLIT_LOCK_DISABLE. And TDX module doesn't context switch 
MSR_TEST_CTRL when entering into the TDX vCPU because MSR_TEST_CTRL is 
not virtualizable. Thus SPLIT_LOCK_DISABLE remains enabled when TDX vCPU 
is running.

Regarding UC_LOCK_DISABLE, Linux doesn't enable it. Not sure if BIOS 
enables it or not (as far as I know, I don't see any bios enables it)

> Looking at the backtrace:
> 
>    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)
> 
> 
> First, "took a split_lock trap" is wrong.  It's a fault, not a trap.

Hi x86 maintainers,

Should we fix it?

> Second, because the attempt to disable BUS_LOCK_DISABLE was blocked,
> simply retrying the instruction will generate a new #AC and livelock.
> Linux probably ought to raise SIGSEGV with userspace, for want of
> anything better to do.

This patch is just achieving this, while it raises the SIGBUS to userspace.

> It looks like software in a TDX VM will simply have to accept that it
> cannot cause a bus lock.

If the host doesn't enable SPLIT_LOCK_DISABLE, then split lock might not 
be fatal to TDX guests.

> ~Andrew