linux-kernel - Re: [PATCH] x86/its: use Sapphire Rapids+ feature to opt out

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: <225134fd-033f-4d63-b88c-772179054694@intel.com>
Date: Mon, 20 Oct 2025 15:09:41 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
 Jon Kohler <jon@...anix.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
 Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...hat.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org"
 <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
 Brian Gerst <brgerst@...il.com>, Brendan Jackman <jackmanb@...gle.com>,
 "Ahmed S. Darwish" <darwi@...utronix.de>,
 Alexandre Chartre <alexandre.chartre@...cle.com>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/its: use Sapphire Rapids+ feature to opt out

On 10/20/25 13:40, Pawan Gupta wrote:
>> I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do
>> it, but I suspect there are similar challenges around post-launch feature/bit
>> additions that require the VM to be completely cold-booted.
> Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it
> be better to replace BHI_CTRL with BUS_LOCK_DETECT.

Folks, I just think this kind of random feature spaghetti voodoo is a
bad idea. Suppose X86_FEATURE_BUS_LOCK_DETECT is in silicon on an
affected part but normally fused off. But a big customer shows up with a
big checkbook and Intel releases microcode to enumerate
X86_FEATURE_BUS_LOCK_DETECT on an affected part.

What then?

Your only choice is to convince Intel to make architectural the idea
that X86_FEATURE_BUS_LOCK_DETECT is never enumerated on an affected part.

Because even if we go forward with that patch we've *DONE* that in
Linux: we've made it de facto architecture and Intel can never change it.

Can someone try to boil down the problem statement for me again, please?

	VMs are slow because of mitigations for issues to which they are
	not vulnerable when running old kernels on old hypervisors.

Is that it?