Message-ID: <413D20D7-AB18-4D46-8128-6179F2565765@nutanix.com>
Date: Mon, 20 Oct 2025 16:05:57 +0000
From: Jon Kohler <jon@...anix.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        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 11:48 AM, Sean Christopherson <seanjc@...gle.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> On Thu, Oct 16, 2025, 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.
>> 
>> 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. This avoids false negatives
>> caused by VMMs that omit ITS_NO or BHI_CTL. For example, QEMU added
>> bhi-ctrl only in v9.2.0 [1], well after adding the Sapphire Rapids
>> model in v8.0.0 [2].
>> 
>> [1] 10eaf9c0fb7 ("target/i386: Add more features enumerated by CPUID.7.2.EDX")
>> [2] 7eb061b06e9 ("i386: Add new CPU model SapphireRapids")
>> 
>> Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
>> Fixes: 159013a7ca1 ("x86/its: Enumerate Indirect Target Selection (ITS) bug")
>> Signed-off-by: Jon Kohler <jon@...anix.com>
>> ---
>> .../admin-guide/hw-vuln/indirect-target-selection.rst       | 5 +++--
>> arch/x86/kernel/cpu/common.c                                | 6 ++++--
>> 2 files changed, 7 insertions(+), 4 deletions(-)
>> 
>> diff --git a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
>> index d9ca64108d23..3cfe4b9f9bd0 100644
>> --- a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
>> +++ b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
>> @@ -98,8 +98,9 @@ Mitigation in guests
>> ^^^^^^^^^^^^^^^^^^^^
>> All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
>> and Family/Model of the guest. This is because eIBRS feature could be hidden
>> -from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
>> -indicates that the guest is running on an unaffected host.
>> +from a guest. One exception to this is when a guest enumerates BHI_DIS_S or
>> +BUS_LOCK_DETECT, either of which indicates that the guest is running on an
>> +unaffected host and would not be migratable to an affected host.
>> 
>> To prevent guests from unnecessarily deploying the mitigation on unaffected
>> platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index c7d3512914ca..3de4b51d8681 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -1361,9 +1361,11 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
>> /*
>>  * If a VMM did not expose ITS_NO, assume that a guest could
>>  * be running on a vulnerable hardware or may migrate to such
>> -  * hardware.
>> +  * hardware, except in the situation where the guest is presented
>> +  * with a feature that only exists in non-vulnerable hardware.
>>  */
>> - if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
>> + if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
>> +     boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
> 
> Uh, don't you want something like this?
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index c7d3512914ca..8c4bc9b5d8ed 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1364,7 +1364,7 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
>         * hardware.
>         */
>        if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
> -               return true;
> +               return !boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT);
> 
>        if (cpu_matches(cpu_vuln_blacklist, ITS))
>                return true;
> 
> Functionality aside, this is quite heinous.  I don't see why the answer isn't
> "Fix the VMM to specify ITS_NO".

Yes, I know it isn’t the prettiest person at the ball; however, the problem I was trying
to solve is guests being deployed on “old” VMMs, so we could stop the bleeding
from that side. The bummer of all of this is that the guest does have enough info
to solve this from the guest side without VMM involvement, but I’m not going to
litigate that as the ITS_NO approach is clear. Is what it is.

Was running into some testing issues with my qemu change internally, but I’ll 
get that out this week once I clear them.

Powered by blists - more mailing lists