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
(cherry picked from commit 5bbffaf053)
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.
(cherry picked from commit 23ea5427b5)
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.
(cherry picked from commit 0b022ee253)
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.
(cherry picked from commit 1e33f40f0a)
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.
(cherry picked from commit 1211c21261)
Add RELEASE.md describing the manual sync -> draft -> publish release
procedure
Update DEVELOPMENT.md's Branch Model to reflect that source-build is copied
onto master by the manual `release` workflow instead of merged via PR.
Add Neoverse-V3 (0xd84) and Neoverse-V3AE (0xd83) to the Spectre
variant whitelist with the same profile as Neoverse-V1/V2 (affected by
Variant 1 only), per ARM's speculative processor vulnerability page.
Also add them to the SLS (CVE-2020-13844) speculative-core list,
consistent with V1/N2/V2.
Verified on AWS Graviton5 (Neoverse-V3, MIDR 0x410fd841): the kernel
reports all variants mitigated/not-affected, while the unpatched
checker false-flags Variant 3a (and Spectre v2 inside guests) because
0xd84 falls through to the unrecognized-CPU default.
Fixes#582
Signed-off-by: Jay Chung <jaehoc@amazon.com>
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)
Stéphane Lesimple
Jay Chung
speed47
github-actions[bot]
林博仁 Buo-ren Lin