CPU 的安全能力通常不是一个开关，而是一组分布在硬件、固件、内核和系统配置中的特性。openKylin 社区 Trusted Computing SIG 最近推出 Platform Security Patrol（平台安全巡检工具），把这些检查项集中到一个入口中，帮助用户快速了解当前平台的安全状态。
该工具已经进入 openKylin 3.0 软件仓库。对使用 openKylin 3.0 的用户来说，安装后即可进行 CPU 硬件安全特性检测，并根据检测结果获得分层故障定位和配套修复指引。
CPU 安全体检解决什么问题
现代 CPU 通常原生提供多重硬件安全能力，但“处理器支持”不等于“系统已经启用并正确使用”。实际状态还可能受到 BIOS/UEFI 设置、微码、Linux 内核版本、启动参数和虚拟化环境的影响。
因此，一次有价值的安全巡检至少需要回答三类问题：
- CPU 硬件是否具备目标安全特性。
- 固件和操作系统是否识别并启用了这些特性。
- 如果检查未通过，问题更可能位于硬件、固件、内核还是系统配置层。
Platform Security Patrol 的重点就在于把这些信息组织起来，提供一键检测、分层定位和修复建议。对于桌面用户，它可以减少手工查询资料的成本；对于运维人员，它也可以作为安装验收和故障排查时的快速检查入口。
从“支持”到“生效”的多层检查
CPU 安全检查不能只看 /proc/cpuinfo 中是否出现某个 flag。一个特性可能在 CPU 层面存在，却因为固件关闭、内核不支持或运行在虚拟机中而无法实际生效。
可以把巡检结果理解为几个层次：
- 硬件层：处理器是否提供相关能力。
- 固件层：BIOS/UEFI 是否启用必要选项，微码是否处于可用状态。
- 内核层：内核是否识别并启用对应机制。
- 系统层：启动参数、软件包和运行环境是否满足要求。
- 修复层：根据失败层级给出下一步处理建议。
这种分层方式比简单输出“通过”或“不通过”更适合实际排障。比如，硬件支持但固件未启用时，继续修改用户态配置通常没有效果；而如果物理机正常、虚拟机中不可见，则需要进一步确认虚拟化平台是否透传了相关 CPU 特性。
安装前后的可复制检查
下面的命令不依赖 Platform Security Patrol 的内部接口，可以先确认系统版本、CPU 信息和仓库中是否已经提供相关软件包。命令适用于 openKylin 3.0，具体包名以本机软件仓库返回结果为准。
#!/usr/bin/env bash
set -u
echo '== OS release =='
cat /etc/os-release
echo
echo '== CPU summary =='
lscpu | sed -n '1,18p'
echo
echo '== Repository search =='
apt-cache search platform-security-patrol 2>/dev/null || true
apt-cache search 'platform.*security.*patrol' 2>/dev/null || true
echo
echo '== CPU security-related flags =='
grep -m1 -Eo 'flags[[:space:]]*:.*' /proc/cpuinfo \
| tr ' ' '\n' \
| grep -Ei 'aes|nx|smep|smap|ibrs|ibpb|stibp|ssbd|md-clear|flush_l1d|arch_capabilities' \
| sort -u || true
保存为 cpu-security-baseline.sh 后运行：
chmod +x cpu-security-baseline.sh
./cpu-security-baseline.sh
这段脚本只是人工基线检查，不能替代 Platform Security Patrol 的完整巡检。它的价值在于提供一个可留存的现场信息快照，方便安装工具前后对比，也方便把硬件和系统环境信息附加到问题报告中。
确认仓库已刷新后，可以这样安装：
sudo apt update
apt search platform-security-patrol
sudo apt install platform-security-patrol
如果 apt search 返回的实际包名不同，应将最后一条命令中的包名替换为仓库显示的名称。安装完成后，从应用菜单启动 Platform Security Patrol，执行平台安全检查，并按结果页提供的层级提示处理问题。
如何使用巡检结果
巡检工具的结果不应只被当作一次性的“绿灯检查”。更实用的做法是把它纳入设备交付和日常运维流程：
- 新装系统后记录一次完整检测结果，作为初始基线。
- 修改 BIOS/UEFI、升级内核或更新微码后重新检查。
- 对检测失败的项目先确认失败层级，再决定是否调整固件、系统配置或软件版本。
- 在虚拟机中运行时，区分“宿主机支持”和“当前虚拟机可见”两个事实。
- 涉及生产环境时，先在同型号测试机验证修复建议，再批量推广。
需要注意的是，检测工具可以帮助发现安全能力的状态，但不能替代完整的安全策略。CPU 硬件特性只是平台安全的一部分，账户权限、补丁管理、磁盘加密、网络隔离和应用安全同样需要单独治理。
落地建议
openKylin 3.0 用户可以把 Platform Security Patrol 作为平台验收和故障定位的第一道检查工具。它最大的实际价值不只是“一键检测”，而是把硬件支持、系统启用状态和后续修复方向放在同一条诊断链路中。
建议采用以下最小流程：
- 安装前保存
lscpu和系统版本信息。 - 从 openKylin 3.0 软件仓库安装 Platform Security Patrol。
- 执行完整 CPU 安全巡检并保存结果。
- 对失败项按照硬件、固件、内核和系统配置逐层处理。
- 修复后重新检测，并把结果纳入设备基线。
这样，CPU 安全能力就不再只是规格表上的描述，而能变成可检查、可定位、可复核的系统状态。