Re: [PATCH v5 2/8] x86/bugs: Allow spectre_v2=ibrs on x86 vendors other than Intel

[Kim Phillips]

On 9/9/26 4:01 PM, Borislav Petkov wrote:
> On Wed, Aug 26, 2026 at 05:35:04PM -0500, Kim Phillips wrote:
> > Prepare for legacy IBRS toggling on AMD, where the BTB Isolation
> Same question as before: why?
>
> This commit message is explaining what the patch does. It needs to explain
> the why.
ok how about this as the new commit text?:

SPEC_CTRL.IBRS is architectural and behaves on AMD just like it does on
Intel, but the kernel offers spectre_v2=ibrs on Intel only: the option is
rejected at parse time on other vendors, and MITIGATION_IBRS_ENTRY cannot
even be built into an AMD-only kernel.

AMD's SNP BTB Isolation needs the kernel to toggle legacy IBRS in order to
optimize the VM exit-to-re-entry path, and right now there is no way to ask
for kernel IBRS on an AMD machine at all.

It happens for historical reasons only.  Commit 7c693f54c873
("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
gated the option on Intel because Intel was the only vendor that needed it
back then - there, kernel IBRS doubles as a RETBleed mitigation. Nothing
in the IBRS_ENTER/IBRS_EXIT mechanism itself is vendor-specific.

Fix it by dropping the vendor check from the command line parsing and
CPU_SUP_INTEL from MITIGATION_IBRS_ENTRY's depends line.

Keep the IBRS-trumps-retbleed logic in retbleed_update_mitigation()
Intel-only, though: legacy SPEC_CTRL.IBRS does not cover AMD's Branch Type
Confusion RETBleed variant because RET prediction comes from the Return
Address Predictor rather than from the indirect branch predictors IBRS
restricts.  Letting SPECTRE_V2_IBRS trump retbleed on AMD would silently
drop the UNRET/IBPB mitigation that does cover it.  RETBleed selection on
AMD never consults spectre_v2=, so spectre_v2=ibrs neither adds nor removes
RETBleed coverage there and the retbleed sysfs node keeps reporting the
truth on its own.

Two more things need handling once the option becomes reachable on AMD:

AutoIBRS-capable CPUs would take the EFER.AUTOIBRS path for any IBRS mode,
handing spectre_v2=ibrs the always-on AutoIBRS behaviour instead of the
toggleable SPEC_CTRL.IBRS the option asks for.  Restrict that path to the
eIBRS modes.

And EFER.AUTOIBRS survives kexec because head_64.S preserves the incoming
EFER bits, so a kernel that ran in AutoIBRS mode leaves the next one in
AutoIBRS mode while its sysfs reports "Mitigation: IBRS" or a retpoline
mode.  Clear the bit at the top of cpu_select_mitigations() next to the
existing SPEC_CTRL kexec cleanup - a cold boot has it clear already, and
that spot precedes the init_real_mode() EFER snapshot the AP trampoline
uses.

Thanks,

Kim