Take this opportunity to factorize all the greps in /proc/cpuinfo
into a helper that avoids using a pipe to entirely avoid SIGPIPE
on a possibly gigantic /proc/cpuinfo
When IA32_ARCH_CAPABILITIES (0x10a) can't be read from userspace (no msr
module, or kernel lockdown under Secure Boot), the FBSDP_NO/PSDP_NO/SBDR_SSDP_NO
bits were left at 0 ("explicitly not immune") instead of -1 ("unknown"). For a
recent CPU not in any kernel model list (e.g. Arrow Lake), this wrongly flipped
the MMIO Stale Data verdict into the "out of servicing period, Intel never
assessed this CPU" bucket.
Zenbleed (CVE-2023-20593) is mitigated either by up-to-date CPU microcode
or by the host kernel setting FP_BACKUP_FIX (DE_CFG MSR 0xc0011029 bit 9).
Both are applied at the host level. Inside a Xen dom0/domU (or any VM
guest) the script can't read that MSR and can't trust the microcode
version the hypervisor presents, so it wrongly concluded "kernel too old
+ microcode not fixed" and reported VULN even though the host had applied
the microcode fix (passing on bare metal).
In live mode, when the verdict would be VULN and we're running as a guest,
report UNK instead, explaining the mitigation is host-level and not
observable from inside the guest. Bare metal is unchanged (still VULN),
offline analysis is unchanged, and a guest with positively-confirmed
fixed microcode still reports OK.
Inside a Xen PVH domU (and any guest where the kernel sets
X86_FEATURE_HYPERVISOR), the kernel appends "; SMT Host state unknown"
to the MDS/MMIO sysfs vuln string: the host controls SMT scheduling and
the guest genuinely can't see it. The "SMT is either mitigated or
disabled" check only matched 'SMT (disabled|mitigated)', so this read as
"not mitigated" and --paranoid flipped the verdict to a misleading
VULN "you must disable SMT (Hyper-Threading)".
Make *_smt_mitigated a tri-state: 1 (disabled/mitigated), 0 (vulnerable),
and 2 (host state unknown). In paranoid mode, when the in-guest
mitigation is active but SMT host state is unknown, report UNK with an
explanation that cross-thread protection depends on the hypervisor host's
SMT/core-scheduling config, instead of VULN. PV DomUs (kernel reports
"SMT vulnerable", no HYPERVISOR bit) are unchanged and still flagged.
Better detect Xen guest type + add container detection
CVE-2017-5754: when we see Xen but we're inside a container,
/proc/xen/capabilities isn't exposed and dmesg is the host's,
so dom0 vs PV DomU can't be told apart. Don't report VULN in
that case, but UNKNOWN instead, and ask to rerun the script on the host.
Store the per-core implementer/part/arch/variant/revision lists
space-separated (no embedded newlines, which also cleans up JSON and
prometheus output) and dedup them for the human-readable display, so
homogeneous systems show e.g. "0x41" instead of repeating it per core.
Addresses issue #336: when running inside a VM (KVM, VMware, ESXi,
Hyper-V, VirtualBox), the hypervisor can present a fake CPUID and
microcode version to the guest, making the microcode up-to-date check
meaningless or misleading.
Changes:
- Add is_running_as_guest() to 370_hw_vmm.sh: detects VM guest status
by checking for the 'hypervisor' CPUID flag in /proc/cpuinfo, which
is exposed by KVM, VMware, Hyper-V, VirtualBox and most other
hypervisors. Result is cached in g_is_guest_vm / g_is_guest_vm_reason.
- Add "Running as VM guest: YES/NO" line to the CPU details block in
check_cpu() (400_hw_check.sh), shown for both x86 and ARM guests.
- Add a pr_warn block after the microcode-is-latest check in check_cpu()
advising the user to verify microcode information on the hypervisor
host when a VM guest is detected.
- Add minimal ARM CPU details block in check_cpu(): vendor, model name,
implementer(s), part(s), architecture(s), and VM guest status. ARM CPUs
previously got no output from check_cpu() due to the x86-only early
return guard.
- Expose guest VM status in JSON output (250_output_emitters.sh):
- system section: guest_vm (bool) and guest_vm_reason (string)
- cpu_microcode section: unreliable_in_vm (bool)
CVE_REGISTRY gains an optional fifth field that tags checks as x86-only or
arm-only, untagged entries apply everywhere. The main CVE dispatcher and the
affectedness summary both skip gated entries in default "all CVEs" runs,
removing the noise of arm64 errata on x86 hosts and of x86 CVEs on ARM hosts
across text, json, nrpe and prometheus outputs. Explicit --cve/--variant/--errata
selection bypasses the gate so manual queries still run anywhere.
The gate honours no-hw mode by ignoring the host CPU and keying off the
inspected kernel's architecture only, which handles cross-arch offline
analysis driven by --kernel/--config/--map.
Add detection for three speculation/security-relevant ARM64 errata
families that are tracked by vendor erratum IDs rather than CVEs: Speculative
AT TLB corruption (1165522/1319367/1319537/1530923), speculative unprivileged
load (2966298/3117295), and MSR SSBS not self-synchronizing (3194386 and
siblings). Reserves a new CVE-0001-NNNN placeholder range for vendor errata
and adds a --errata <number> selector alongside --variant/--cve.
CPU affection is determined per-core from (implementer, part, variant,
revision) tuples read from /proc/cpuinfo, matching the kernel's MIDR ranges
(including Kryo4xx Silver for erratum 1530923). Kernel mitigation detection
uses the erratum-specific CONFIG_ARM64_ERRATUM_NNNN symbols, kernel image
descriptor strings, and dmesg output (no sysfs for these)
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
Stéphane Lesimple