linux-kernel - Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval

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

Date: Thu, 4 Apr 2024 08:26:29 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Javier Pello <devel@...eo.eu>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval_t
 to avoid split locks

On Wed, Apr 03, 2024, Dave Hansen wrote:
> On 4/3/24 08:54, Javier Pello wrote:
> > - The third way would be to disable split lock detection on x86-32.
> > This can be as simple as setting the default to "none" in
> > sld_state_setup(). Not the most elegant of solutions, but beats
> > having unresponsive tasks.
> > 
> > Would going for the first one be worth the trouble?
> 
> No, it's not worth it.  Let's just disable split lock detection on
> 32-bit and move on with life.

Please don't paper over the kernel flaw by disabling split lock detection.  As
Brian alluded to with his question:

 : What would happen if you ran a 32-bit VM on such hardware?  If the
 : split lock detection on the guest were disabled, would the host get
 : the fault instead?

running these kernels under a hypervisor that has enabled split-lock detection,
or Intel's newfangled BUS_LOCK_DETECTION VM-Exit, will result in silently
degraded performance for the guest kernel.  The split-lock will trap to the
hypervisor, which will likely throttle the vCPU to guard against a DoS attack,
e.g. under KVM, IIRC the default behavior for split-lock is to stall the task
for 10 _milliseconds_.

In other words, practically speaking this isn't about supporting a new hardware
feature on 32-bit kernels, it's about preserving performance in real world
scenarios when running 32-bit kernels on new hardware.  And that means keeping
split-lock detection enabled on 32-bit kernels is a good thing, as kernels bugs
that would cause hard-to-debug _customer_ issues when running 32-bit Linux in a
VM will show up as easy-to-debug splats when running 32-bit kernels on bare
metal.   I doubt there are many people that are still running 32-bit kernels on
bare metal, but any coverage we can get would be very nice to have.