最权威的实时检查方式是直接读取 /sys/devices/system/cpu/vulnerabilities/ 目录，内核根据cpu型号、微码版本、内核配置和启动参数动态生成各漏洞状态文件；输出中“vulnerable”表示未启用软件缓解，“mitigation:...”表示已启用对应缓解，文件缺失通常意味着硬件不支持该漏洞变体或内核过旧。
直接读取 /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
-
Vulnerable表示未启用软件缓解——但不等于没打补丁，可能是启动参数禁用了（如mitigations=off），也可能是微码太旧导致硬件级缓解（如 IBRS）无法启用 -
Mitigation: ...表示对应缓解已生效，但具体效果还取决于微码版本和超线程开关状态 - 某漏洞文件（如
spectre_v2）不存在，通常说明 CPU 硬件不支持该变体，或内核太老（
用 spectre-meltdown-checker.sh 交叉验证硬件与内核上下文
仅看 /sys/.../vulnerabilities/ 会漏掉关键上下文：比如微码是否最新、内核是否编译了 CONFIG_RETPOLINE、启动参数是否覆盖了默认行为。
克隆并运行：
git clone https://github.com/speed47/spectre-meltdown-checker.git cd spectre-meltdown-checker && sudo ./spectre-meltdown-checker.sh
重点关注三处输出：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 每段末尾的
STATUS行（如OK、VULNERABLE），比单纯读文件更可靠 -
microcode行：若显示microcode is not the latest，即使内核打了补丁，Intel CPU 上的 IBRS 缓解仍可能失效 -
Kernel is compiled with和Boot parameters：确认retpoline是否启用、mitigations=on是否被显式关闭
检查内核启动参数是否禁用缓解
很多系统更新了内核却仍显示 Vulnerable，根本原因是启动时加了关闭参数。这些参数会强制覆盖内核默认行为。
检查命令：cat /proc/cmdline | grep -E "(mitigations|spec_store|pti|retpoline)"
- 出现
mitigations=off或spec_store_bypass_disable=off→ 缓解被手动关掉 - 出现
pti=off或retpoline=off→ 对应漏洞缓解被单独禁用 - 没有这些参数 ≠ 自动启用：某些旧发行版默认不启用
mitigations，需显式加mitigations=on
确认微码是否更新（尤其 Intel CPU）
微码过旧会导致硬件级缓解（如 IBRS、IBPB）无法启用，只能退化到纯软件方案（如 retpoline），性能损耗大且防护面窄。
查看当前微码版本：sudo dmesg | grep "microcode"
对比 Intel 官方发布的最新微码（2020 年后版本才完整支持 IBRS）：
- RHEL/CentOS：安装
microcode_ctl包并重启 - Ubuntu/Debian：安装
intel-microcode或amd64-microcode包 - 更新后必须重启，微码加载发生在 BIOS/UEFI 阶段，热更新无效
微码更新和内核补丁是两件事：缺一不可。只更新内核而忽略微码，spectre_v2 很可能仍显示 Vulnerable 或降级为 Retpoline。
