Message-ID: <D409ECAE-049E-4DE7-9B1B-D639BC344F37@nutanix.com>
Date: Mon, 20 Oct 2025 21:02:50 +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 4:40 PM, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> On Mon, Oct 20, 2025 at 07:54:41PM +0000, Jon Kohler wrote:
>> 
>> 
>>> 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
> 
> Since ITS is newer than BHI_CTRL, deploying ITS mitigation unnecessarily
> shouldn't be a problem for A) and B), right?

100%, this is much easier in that regard because it is not touching SPEC_CTRL

> 
>> 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).
> 
> This looks to be the main problem scenario.

Yes

>> 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.
> 
> That seems orthogonal to the problem at hand, but I feel the pain. IIUC,
> you are referring to the wrmsr(SPEC_CTRL) at guest entry/exit because that
> have different MSR values. Host with BHI_DIS_S=1 and guest without it? Do
> you think adding support for virtual-SPEC_CTRL in QEMU would help here?
> 
>>>> 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.
> 
> 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.
> 
> ---
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 1755f91a5643..e8fc4a4055bf 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1355,8 +1355,8 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
> if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> return false;
> 
> - /* None of the affected CPUs have BHI_CTRL */
> - if (boot_cpu_has(X86_FEATURE_BHI_CTRL))
> + /* None of the affected CPUs have BUS_LOCK_DETECT */
> + if (boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
> return false;
> 
> /*

Ok, thank you for the back and forth. I’ll do some more poking around and see
if I can double check this approach on other platforms, to see if I can smoke out
any other oddball edge cases.

Powered by blists - more mailing lists