最准确的方式是直接读取 /sys/devices/system/cpu/vulnerabilities/ 目录，内核启动时依据CPU型号、微码版本、内核配置及启动参数自动生成各漏洞状态文件，真实反映当前运行态的缓解生效情况；值为Vulnerable仅表示未启用软件缓解，Not affected表示硬件不支持该变体，Mitigation后内容指示具体防护措施。
直接读取 /sys/devices/system/cpu/vulnerabilities/ 目录最准
内核在启动时会根据 CPU 型号、微码版本、内核配置和启动参数，自动生成该目录下每个漏洞的状态文件。它反映的是当前运行态的真实缓解状态，不是“有没有补丁”，而是“补丁是否生效”。
- 执行
grep . /sys/devices/system/cpu/vulnerabilities/*，输出类似：/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Enhanced IBRS, IBPB: conditional/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected - 值为
Vulnerable≠ 可被利用，只表示未启用软件缓解（比如没开 PTI 或 retpoline）；Not affected表示硬件不支持该变体（如老 AMD CPU 无 Meltdown 风险）；Mitigation后跟的具体措施才是关键 - 若某漏洞文件缺失（如无
spec_store_bypass），可能是内核太旧（
spectre-meltdown-checker.sh 能查出内核接口看不到的上下文
单纯看 /sys/devices/system/cpu/vulnerabilities/ 无法知道为什么显示 Vulnerable —— 是缺补丁？微码太旧？还是启动参数关了缓解？这个脚本能交叉验证。
- 运行
sudo ./spectre-meltdown-checker.sh后，重点看每段末尾的STATUS行（如OK、VULNERABLE），不是开头的 summary - 特别关注
microcode行：若提示microcode is not the latest，即使内核打了补丁，Intel CPU 仍可能因微码过旧导致 IBRS 失效，只能退到性能损耗更大的 retpoline - 检查
Kernel is compiled with和Boot parameters两节：确认是否启用了pti=on、spec_store_bypass_disable=on等参数；mitigations=off会强制所有漏洞标为Vulnerable
/proc/cpuinfo 的 bugs 字段是硬件能力快照
这个字段列出 CPU 硬件层已知缺陷（如 meltdown spectre_v1 spectre_v2），但它只反映 CPU 设计本身，不体现缓解是否启用。
- 执行
grep bugs /proc/cpuinfo | head -1即可看到当前 CPU 支持哪些漏洞变体 - 若
bugs里有spectre_v2，但/sys/devices/system/cpu/vulnerabilities/spectre_v2显示Not affected，说明该 CPU 微码+固件已从硬件层面修复（如部分 Ice Lake 后的 Intel CPU） - 注意：ARM 平台该字段可能为空或不规范，优先依赖
/sys/devices/system/cpu/vulnerabilities/
别忽略启动参数对漏洞状态的硬性覆盖
很多系统更新了内核却仍显示 Vulnerable，根本原因常是 GRUB 启动参数显式关闭了缓解机制。
- 检查当前生效参数：
cat /proc/cmdline | grep -E "(mitigations|spec_store|pti|retpoline)" - 常见干扰项：
mitigations=off（全局关所有缓解）、spec_store_bypass_disable=off（单独关 Speculative Store Bypass）、nopti（关 PTI） - 修改需编辑
/etc/default/grub中的GRUB_CMDLINE_LINUX，然后运行sudo update-grub && sudo reboot
Mitigation: Full retpoline 在微码旧的 Intel CPU 上性能损耗可能比新微码+IBRS 高 30%；而 Not affected 也不代表绝对安全——某些云环境的虚拟化层可能引入新旁路面。查清楚“谁在缓解、怎么缓解、有没有被绕过”，比只盯一个单词重要得多。 
