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: <EA2E1D80-07A3-459D-B330-A667821E7C05@nutanix.com>
Date: Mon, 20 Oct 2025 19:54:41 +0000
From: Jon Kohler <jon@...anix.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.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 Oct 20, 2025, at 3:44 PM, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> On Thu, Oct 16, 2025 at 06:12:49PM -0700, Jon Kohler wrote:
>> A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those
>> bits to determine whether they might be migrated to ITS-affected
>> hardware. Rather than depending on a control that may be absent, detect
>> ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire
>> Rapids and newer processors.
> 
> BHI_CTRL is also exclusive to Sapphire Rapids and newer processors. Why
> wouldn't it be exposed to guests but BUS_LOCK_DETECT would be?
> 
> Not exposing BHI_CTRL has another disadvantage that guests would deploy the
> BHB-clear sequence when they could have used cheaper hardware mitigation
> for BHI.

Yes, I know, but given that BHI_CTRL comes via a spec_ctrl value change, it
has a negative effect at any guests live migrated in that never A) updated their
guest kernel to know about the new speculation controls and/or B) have updated
but have not yet soft rebooted and/or C) have updated, have soft rebooted, but
the BHI_CTRL isn’t actually available because the system hasn’t cold-booted
the VM(s) (see comments below).

In any of those three situations, subsequent guest/host transitions become
penalized. Now, from a security perspective, thats irrelevant because one
could say that if you really want to be secure, you have to do the work to make
sure all these cold boots are done, but that is far easier said than done in general
enterprise virtualization workloads.

Meaning, *if* a host opts into enabling BHI at all, they will penalize any guest
workload that hasn’t done the work to do the proper enablement cover to cover.
Less of a problem for hyperscaler who could control what launch/where, much
much harder for non-hyperscalers who might live migrate in extremely long tailed
workloads that feel like a federal project just to get a guest reboot, not to mention
a guest cold boot.

> 
>> Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on
>> Sapphire Rapids+ parts and provides a reliable indicator that the guest
>> won't be moved to ITS-affected hardware.
> 
> I am puzzled why BUS_LOCK_DETECT is more reliable than BHI_CTRL?

Because BUS_LOCK_DETECT (or any other feature from commit [1]) was
available day 1 of the SPR QEMU model, whereas BHI_CTRL wasn’t added
until commit [2]. That means any VMM that added SPR support “day 1” has
the feature set from [1] at minimum, and it also means that if a guest VM was
*started* on that QEMU version, but never power cycled, it will never see 
BHI_CTRL, even if it is available to be picked up in the latest model scheme.

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.

[1] 7eb061b06e9 ("i386: Add new CPU model SapphireRapids")
[2] 10eaf9c0fb7 ("target/i386: Add more features enumerated by CPUID.7.2.EDX")