Re: [PATCH v5 1/8] x86/bugs: Allow forcing Automatic IBRS with SNP active using spectre_v2=eibrs

[Kim Phillips]

On 9/2/26 11:03 PM, Borislav Petkov wrote:
> On Wed, Aug 26, 2026 at 05:35:03PM -0500, Kim Phillips wrote:
> > spectre_v2=eibrs currently enables retpolines when SNP is enabled,
> > instead of AutoIBRS (EIBRS) because the commit that disabled
> > AutoIBRS if SNP is enabled stopped short of enabling
> > X86_FEATURE_IBRS_ENHANCED.
> This and the comment below in spectre_v2_select_mitigation() is somewhat
> hinting on what you're trying to do here, and I can only guess. But
> I shouldn't be guessing. Rather, the text should explain it clearly.
>
> > Change the logic to enable X86_FEATURE_IBRS_ENHANCED, and move the
> > decision to switch to retpolines in the default/"auto" case in
> > spectre_v2_select_mitigation().  This allows the existing
> > spectre_v2=eibrs logic to work as intended.
> >
> > Condition that switch on CONFIG_MITIGATION_RETPOLINE being built in.
> > Otherwise spectre_v2_select_retpoline() returns SPECTRE_V2_NONE and an
> > SNP host with AutoIBRS available would be left completely unmitigated
> > against Spectre v2 in the default/auto case, which is worse than the
> > userspace indirect branch performance loss AutoIBRS costs.
> >
> > Also emit a performance loss warning for using AutoIBRS with SNP
> > enabled.  AutoIBRS is activated for all three eIBRS modes via
> > spectre_v2_in_eibrs_mode(), so use that helper to cover
> > spectre_v2=eibrs, spectre_v2=eibrs,lfence, and
> > spectre_v2=eibrs,retpoline uniformly.  Word the warning in terms of the
> > eIBRS mitigation enabling AutoIBRS, rather than naming AutoIBRS as the
> > selected mitigation, so it reads correctly for the ,lfence and
> > ,retpoline variants where another component is also active.
> This whole text is explaining the diff. Never write about the "what" - but the
> "why". Why does this patch exist?
>
> Please structure your commit message something like this:
>
> 1. Prepare the context for the explanation briefly.
>
> 2. Explain the problem at hand.
>
> 3. "It happens because of <...>"
>
> 4. "Fix it by doing X"
>
> 5. "(Potentially do Y)."
>
> And some of those above are optional depending on the issue being
> explained.
>
> But do not explain the patch. If there are questions about it, I will ask.
>
> Thx.
How about the following as the new commit text?:

AMD's AutoIBRS is the hardware implementation of eIBRS.  When SNP is
active, AutoIBRS also applies to host userspace, which costs indirect
branch performance there, so commit acaa4b5c4c85 ("x86/speculation: Do
not enable Automatic IBRS if SEV-SNP is enabled") made SNP hosts use
retpolines instead.

That fallback cannot be overridden.  An admin running an SNP host whose
workload is dominated by guest activity rather than host userspace may
well prefer AutoIBRS, but asking for it with spectre_v2=eibrs silently
yields retpolines instead.

It happens because the SNP check sits in cpu_set_bug_bits() and simply
leaves X86_FEATURE_IBRS_ENHANCED clear.  Without that feature bit, the
command line parser cannot distinguish "this CPU has no eIBRS" from
"this CPU has eIBRS but policy turned it off", so spectre_v2=eibrs has
nothing left to select and falls back to auto.

Fix it by setting X86_FEATURE_IBRS_ENHANCED whenever the hardware
supports AutoIBRS, and moving the SNP policy decision into
spectre_v2_select_mitigation() where it applies to the default/auto
case only.  The default behaviour stays as it is today, and
spectre_v2=eibrs now means what it says.

Keep AutoIBRS in the default case when CONFIG_MITIGATION_RETPOLINE is
not built in: there is nothing to fall back to and an unmitigated SNP
host is worse than the userspace performance loss.

Finally, warn when eIBRS does end up enabling AutoIBRS on an SNP host so
that the performance cost is not silent.

Thanks,

Kim