AMD Zen 1-3 CPUs don't flush return predictions on IBPB, allowing
cross-process Spectre attacks even with IBPB-on-entry active. The kernel
fix (v6.12+, backported) adds RSB fill after IBPB on affected CPUs.
Detect this gap by checking CPUID IBPB_RET bit and kernel ibpb_no_ret
bug flag, and flag systems relying on IBPB without the RSB fill fix.
Downfall:
- added `--kernel-config` support for all three Kconfig variants seen over all kernel versions up to now
- added `--kernel-map` support for `gds_select_mitigation` in `System.map`
- fixed the `--sysfs-only` mode
- added verbose information about remediation when `--explain` is used
- implemented `--paranoid mode`, requiring `GDS_MITIGATION_LOCKED` so that mitigation can't be disabled at runtime
- fixed offline mode (was wrongly looking at the system `dmesg`)
- better microcode status reporting (enabled, disabled, unsupported, unknown)
- fixed unknown (EOL) AVX-capable Intel family 6 CPUs now defaulting to affected
- fixed 2 missing known affected CPU models: INTEL_FAM6_SKYLAKE_L and INTEL_FAM6_SKYLAKE
- fixed case when we're running in a VM and the hypervisor doesn't let us read the MSR
Spectre V2:
- fix: affected_cpu: added Centaur family 7 (CentaurHauls) and Zhaoxin family 7 (Shanghai) as immune
- fix: added Centaur family 5 (CentaurHauls) and NSC family 5 (Geode by NSC) to is_cpu_specex_free()
- enh: offline mode: added detection logic by probing System.map and Kconfig
The state of the mitigations for spectre v2 has been
updated several times in the kernel, this commit brings
up the script to par with the view of the most recent kernels.
When run on old kernels, that might deem the vulnerability as
mitigated, we'll reclassify it as vulnerable if applicable, unless
the `--sysfs-only` parameter is passed, which instructs the script
to blindly trust what the kernel has to say.
A full inventory of all mitigation strings found in mainline,
stable and redhat kernels since the first spectre v2 mitigation
has been added as a gigantic comment to help understanding the context.
Gory details below:
1. New structured sub-mitigation parsing ("Mitigation 3")
A new section parses the sysfs message into discrete variables for each sub-mitigation component:
- v2_base_mode: The primary mitigation (eibrs, eibrs_lfence, eibrs_retpoline, ibrs, retpoline, lfence, none) - parsed from sysfs with hardware fallback
- v2_stibp_status: STIBP state (always-on, forced, conditional, disabled, eibrs-implicit, etc.)
- v2_ibpb_mode: IBPB mode (always-on, conditional, disabled)
- v2_pbrsb_status: PBRSB-eIBRS mitigation (not-affected, sw-sequence, vulnerable)
- v2_bhi_status: BHI mitigation (not-affected, bhi_dis_s, sw-loop, retpoline, vulnerable)
- v2_vuln_module: Whether a non-retpoline kernel module is loaded
- v2_is_autoibrs: Distinguishes AMD AutoIBRS from Intel eIBRS (they have different cross-thread properties)
2. Rewritten verdict logic (Phase 4)
The old flat if/elif chain is replaced with per-base-mode branches, each checking all relevant sub-mitigations:
- LFENCE: Always VULN (reclassified in kernel v5.17)
- eIBRS path: Checks BHI, PBRSB (VMM-only), AutoIBRS STIBP, vulnerable modules, paranoid mode (IBPB always-on + SMT off)
- IBRS path: Checks IBPB, STIBP+SMT, RSB filling on Skylake+, BHI, paranoid mode
- Retpoline path: Checks compiler, runtime enable, RSB filling, BHI+RRSBA, IBPB, vulnerable modules, paranoid mode
3. Caveat accumulation pattern
A _v2_add_caveat helper collects all gaps into a single string, producing verdicts like "eIBRS active but insufficient: BHI vulnerable; STIBP not active with SMT on AMD AutoIBRS" instead of the old single-issue messages.
4. Other changes
- check_has_vmm called early in Phase 2 (for PBRSB VMM-awareness)
- explain_hypervisor variable removed - its advice is now folded into the per-path explain calls
- Offline mode gains eIBRS/AutoIBRS detection via cap_ibrs_all/cap_autoibrs
- smt_enabled variable added (via is_cpu_smt_enabled) for cross-thread checks
