Linux怎么查看系统的CPU漏洞状态 Linux下Spectre与Meltdown检测详解

判断Linux系统是否受Spectre或Meltdown漏洞影响，光看内核版本号或者发行版的更新日志是远远不够的。最靠谱的方法，是直接“问诊”当前正在运行的系统，看看它实际的漏洞暴露面和缓解措施到底启用了没有。

一句话总结：系统状态是动态的，必须实测运行态。

直接读取/sys/devices/system/cpu/vulnerabilities/目录

这是最直接、也最权威的实时检查窗口。系统启动后，内核会根据CPU型号、微码版本、自身配置以及启动参数，自动在这个目录下生成各个漏洞的状态文件。

• 执行命令 grep . /sys/devices/system/cpu/vulnerabilities/*，你会看到类似这样的输出：
  /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full retpoline
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
• 这里有个细节需要注意：如果某个漏洞对应的文件压根不存在（比如找不到spectre_v2），那通常意味着你的CPU硬件本身就不支持这个变体，或者你用的内核版本比较老（比如4.15之前），可能还没集成对应的检测逻辑。
• 另外，看到状态显示为Vulnerable也别立刻慌。这个值仅仅表示“系统没有启用软件层面的缓解措施”，但实际攻击能否成功，还得看微码版本新不新、超线程有没有关等其他因素。

使用spectre-meltdown-checker.sh脚本做交叉验证

内核接口反映的是“当前生效状态”，而第三方脚本能提供更全面的上下文信息，相当于一次交叉验证，可以有效避免误判。

• 使用方法很简单：先克隆仓库 git clone https://github.com/speed47/spectre-meltdown-checker.git，然后进入目录用root权限运行 sudo ./spectre-meltdown-checker.sh。
• 重点关注输出结果中关于Spectre v1、Spectre v2和Meltdown的三段。每段末尾的STATUS才是最终结论，比如STATUS: VULNERABLE (kernel is not patched)，这就比单纯一个Vulnerable更能明确告诉你问题出在“内核补丁缺失”。
• 脚本输出里有一行特别关键，就是microcode。如果这里显示microcode is not the latest，那么即使你的内核已经打了补丁，也可能因为微码太旧而导致硬件级缓解措施失效，这在Intel CPU上尤其常见。

确认缓解是否真正生效：看mitigations=内核启动参数

很多人明明更新了内核，可系统还是显示Vulnerablemitigations=off或spec_store_bypass_disable=off这类参数，就等于手动关闭了所有漏洞缓解。

• 检查当前生效的启动参数：cat /proc/cmdline | grep -E "(mitigations|spec_store|pti|retpoline)"。
• 只要里面包含mitigations=off，那么所有漏洞状态都会被强制标记为Vulnerable，哪怕你的内核和微码都是最新的也没用。
• 如果想临时测试关闭缓解对性能的影响，可以用sudo sysctl -w kernel.spec_store_bypass_disable=off。不过要记住，这个设置重启后就失效了，而且它并不完全等同于通过启动参数来关闭。

在实际生产环境中，最容易踩坑的其实是微码和内核的协同问题。举个例子，Ubuntu 20.04默认搭载Linux 5.4内核，它确实支持PTI和retpoline这些缓解技术。但是，如果系统里的intel-microcode这个包没有更新到2020年以后的版本，那么针对Spectre v2的硬件级分支预测隔离（IBRS）功能就无法启用。这样一来，系统就只能依赖软件层面的retpoline，性能损耗会相当明显。所以，别光顾着apt upgrade升级内核，也记得用sudo dmesg | grep microcode命令看一眼微码加载的版本号，确保两者都到位了。