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: <20251020224159.xkhfs3phai5o6rzb@desk>
Date: Mon, 20 Oct 2025 15:41:59 -0700
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Jon Kohler <jon@...anix.com>, 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 Mon, Oct 20, 2025 at 03:09:41PM -0700, Dave Hansen wrote:
> 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.

Hmm, right.

> 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.

Using BHI_CTRL here was in agreement with CPU architects. Even though its a
heuristic, it is very unlikely to be broken by a microcode update.

I can't say for sure about BUS_LOCK_DETECT.

> 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.

>From what I understand:

  Unless a VM is cold-booted, it cannot see the new features/immunity bits
  exposed by the hypervisor. In this particular case, a guest gets the
  updated kernel with ITS mitigation, but can't see the immunity bit unless
  it is cold-booted.

  The other part of the problem is when host kernel/hypervisor is not
  updated. In this case immunity bit is not exposed to the guest at all.

My 2 cents: All of this makes me feel the instead of exposing the immunity
bit, a guest should be told about the bug presence. That way security
minded users who update regularly get the bug enumerations, and hence the
mitigations. OTOH, performance focused users who don't update/cold-boot
often don't get unnecessarily slowed down.