最准确方式是读取 /sys/devices/system/cpu/vulnerabilities/ 目录，它反映当前运行态真实缓解状态；/proc/cpuinfo 的 bugs 字段仅表示硬件出厂缺陷快照，不体现软件缓解是否启用，且ARM平台该字段不可靠。
直接读 /sys/devices/system/cpu/vulnerabilities/ 目录，它反映的是当前运行态的真实缓解状态，不是“有没有打补丁”，而是“补丁是否生效”。
为什么不能只看内核版本或 /proc/cpuinfo 的 bugs 字段
/proc/cpuinfo 中的 bugs 字段只是 CPU 硬件能力快照，列出该型号出厂时已知缺陷（如 meltdown spectre_v2），但它完全不体现软件缓解是否启用。比如某 CPU 的 bugs 里有 spectre_v2，但 /sys/devices/system/cpu/vulnerabilities/spectre_v2 显示 Not affected，说明微码+固件已从硬件层面修复（常见于 Ice Lake 后 Intel CPU）。反之，bugs 为空也不代表安全——ARM 平台该字段常不可靠，必须依赖 vulnerabilities/ 目录。
怎么快速查看所有漏洞的当前状态
执行以下命令即可一次性输出全部结果：
grep . /sys/devices/system/cpu/vulnerabilities/*
典型输出类似：
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Enhanced IBRS, IBPB: conditional /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
-
Vulnerable≠ 可被利用，只表示未启用软件缓解（如没开pti=on或retpoline） -
Not affected表示硬件不支持该变体（如老 AMD CPU 无 Meltdown 风险） -
Mitigation:后的内容才是关键——它告诉你实际启用的防护机制，例如Enhanced IBRS比Full retpoline性能损耗小得多 - 如果某个漏洞路径缺失（如无
spec_store_bypass文件），可能是内核太旧（
为什么显示 Vulnerable 却打过补丁？常见原因
单纯看 vulnerabilities/ 目录无法解释“为什么是 Vulnerable”。真正原因往往藏在启动参数、微码或内核配置里：
- 检查内核启动参数：
cat /proc/cmdline | grep -E "(mitigations|spec_store|pti|retpoline)"—— 若含mitigations=off，所有漏洞都会强制标为Vulnerable - 确认微码是否最新：尤其 Intel CPU，旧微码会导致
IBRS失效，只能退到性能更差的retpoline；可用spectre-meltdown-checker.sh查microcode is not the latest提示 - 验证内核是否编译了对应缓解选项：运行
zcat /proc/config.gz | grep -w "CONFIG_PAGE_TABLE_ISOLATION\|CONFIG_RETPOLINE"（若无/proc/config.gz，查/boot/config-$(uname -r)） - 某些漏洞（如
spec_store_bypass）需用户主动启用：默认可能关闭，需加启动参数spec_store_bypass_disable=on
真正容易被忽略的是：缓解措施是否生效，取决于微码、内核参数、内核编译选项三者同时满足。缺一环，vulnerabilities/ 就会显示 Vulnerable，哪怕你刚升级完内核包并重启了系统。
