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
Some old ARM processors (e.g., ARM926EJ-S) report CPU architecture
with suffix in /proc/cpuinfo (e.g., "5TEJ" for ARMv5TEJ).
This caused an "integer expression expected" error when comparing
against numeric values. Extract the numeric prefix before integer comparisons.
Fixes#505.
On ARM64 systems, /proc/cpuinfo uses different field names (CPU implementer,
CPU variant, CPU part, CPU revision) instead of x86-style fields (cpu family,
model, stepping). This left these variables empty, causing printf to fail
with 'invalid number' errors when formatting them as hex values.
Fixes#520.
Stéphane Lesimple