Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs

[Pawan Gupta <pawan.kumar.gupta@linux.intel.com>]

On Thu, Apr 09, 2026 at 02:06:36PM -0700, Jim Mattson wrote:
> On Thu, Apr 9, 2026 at 1:36 PM Dave Hansen <dave.hansen@intel.com> wrote:
> >
> > On 4/7/26 17:47, Jim Mattson wrote:
> > > On Tue, Apr 7, 2026 at 4:41 PM Dave Hansen <dave.hansen@intel.com> wrote:
> > >> On 4/7/26 16:27, Jim Mattson wrote:
> > >>> What is your proposed BHI_DIS_S override mechanism, then?
> > >> Let me make sure I get this right. The desire is to:
> > >>
> > >> 1. Have hypervisors lie to guests about the CPU they are running on (for
> > >>    the benefit of large/diverse migration pools)
> > >> 2. Have guests be allowed to boot with BHI_DIS_S for performance
> > >> 3. Have apps in those guests that care about security to opt back in to
> > >>    BHI_DIS_S for themselves?
> > > I just want guests on heterogeneous migration pools to properly
> > > protect themselves from native BHI when running on host kernels at
> > > least as far back as Linux v6.6.
> > >
> > > To that end, I would be satisfied with using the longer BHB clearing
> > > sequence when HYPERVISOR is true and BHI_CTRL is false.
> >
> > If the guests can't get mitigation information from model/family because
> > the hypervisor is lying (or may lie), then it's on the hypervisor to
> > figure it out.
> >
> > I'm not sure we want to just assume that all hypervisors are going to
> > lie all the time about this.
> 
> Without any information, that is exactly what we must assume. There is
> precedent for this.
> 
> In vulnerable_to_its():
> 
>         /*
>          * 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.
>          */
>         if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
>                 return true;
> 
> 
> In cpu_set_bug_bits():
> 
>         /*
>          * Intel parts with eIBRS are vulnerable to BHI attacks. Parts with
>          * BHI_NO still need to use the BHI mitigation to prevent Intra-mode
>          * attacks.  When virtualized, eIBRS could be hidden, assume vulnerable.
>          */
>         if (!cpu_matches(cpu_vuln_whitelist, NO_BHI) &&
>             (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) ||
>              boot_cpu_has(X86_FEATURE_HYPERVISOR)))
>                 setup_force_cpu_bug(X86_BUG_BHI);
> 
> ...and...
> 
>         if (c->x86_vendor == X86_VENDOR_AMD) {
>                 if (!cpu_has(c, X86_FEATURE_TSA_SQ_NO) ||
>                     !cpu_has(c, X86_FEATURE_TSA_L1_NO)) {
>                         if (cpu_matches(cpu_vuln_blacklist, TSA) ||
>                             /* Enable bug on Zen guests to allow for
> live migration. */
>                             (cpu_has(c, X86_FEATURE_HYPERVISOR) &&
> cpu_has(c, X86_FEATURE_ZEN)))
>                                 setup_force_cpu_bug(X86_BUG_TSA);
>                 }
>         }
> 
> 
> In check_null_seg_clears_base():
> 
>         /*
>          * CPUID bit above wasn't set. If this kernel is still running
>          * as a HV guest, then the HV has decided not to advertize
>          * that CPUID bit for whatever reason. For example, one
>          * member of the migration pool might be vulnerable. Which
>          * means, the bug is present: set the BUG flag and return.
>          */
>         if (cpu_has(c, X86_FEATURE_HYPERVISOR)) {
>                 set_cpu_bug(c, X86_BUG_NULL_SEG);
>                 return;
>         }
> 
> The hypervisor could provide more information so that the guest can
> determine when it's safe to use the short sequence, but that's just
> icing on the cake. The default, out-of-the-box configuration must be
> safe.

In the above cases there was no practical way a VMM could have mitigated
the guest. So the only option for the guest was to take a conservative
approach. Secondly, in the BHI case, real world scenarios of migration
between pre and post ADL CPUs were unknown.

Nevertheless, Intel guidance covers this case by having KVM deploy
BHI_DIS_S for the guest using virtual-SPEC_CTRL. I understand that support
is missing currently, I am working on it. Hopefully, I will be able to
share the draft after this series settles down. We can workout the details
there.

In retrospect, it would have been ideal if this discussion had happened at
the time when virtual-SPEC_CTRL series was introduced.