硬件信任根（rot）使配置文件全程可信，通过pcr绑定平台状态、tee内解析、tpm封存解封及ota闭环度量，将配置从静态数据升级为主动策略凭证。
硬件信任根（Root of Trust, RoT）不是只管开机那几毫秒的事，它能持续为配置文件的加载、解析和生效全过程提供可信支撑。关键在于把“静态存储”变成“动态可信”，让配置不只是“存在”，而是“始终可信”。
配置文件必须绑定平台运行状态
配置参数（如安全策略、密钥白名单、TLS证书路径、服务端口限制等）如果只是存进Flash或eMMC，攻击者可直接擦写回滚到旧版本绕过新策略。RoT要求这些配置在写入前必须与当前平台状态强绑定——比如将配置内容哈希值扩展进TPM的特定PCR寄存器（如PCR 7 或 PCR 12），且该扩展操作需由可信固件或TEE内运行的策略引擎触发。这样，哪怕配置文件本身没被篡改，只要平台状态（如Bootloader版本、内核启动参数）变了，PCR值就不匹配，系统拒绝加载该配置。
- 配置写入流程应包含：校验签名 → 计算哈希 → 扩展至对应PCR → 加密封存（Seal）到TPM
- 运行时读取流程应包含：解封（Unseal）前先比对当前PCR值是否与封存时一致
- 不支持PCR绑定的简单Key-Value存储（如普通NVM）不能作为可信配置载体
配置解析逻辑必须运行在可信执行环境（TEE）中
配置文件本身是数据，但它的解析器（如JSON parser、YAML loader、策略规则引擎）是代码。若解析逻辑跑在普通OS中，攻击者可通过hook libc函数或注入共享库篡改解析结果。正确做法是将配置解析模块放入TEE（如ARM TrustZone的Secure World、Intel SGX enclave或AMD SEV-SNP虚拟机），由RoT保障其加载完整性，并在隔离环境中完成：
- 验证配置数字签名（使用RoT保护的公钥）
- 校验字段语义合法性（如端口范围、证书有效期、权限位掩码）
- 将解析后的结构体直接映射进受保护内存，不暴露明文给Rich OS
例如，一个5G基站的QoS策略配置，必须在TEE中完成解析并生成硬件加速器可识别的流表规则，而非在Linux用户态生成后再传给驱动。
配置更新过程需纳入信任链度量闭环
OTA升级配置包不是简单解压覆盖。整个更新链路需逐级度量：
- UEFI Secure Boot验证更新签名工具的可信性
- Bootloader度量并加载配置更新代理（必须带签名）
- 代理在TEE中解包、验签、校验哈希、扩展PCR、封存新配置
- 最后由可信固件触发配置热重载，同时确保旧配置不可恢复
跳过任一环节（比如用adb push覆盖/etc/目录），都会导致PCR失配或签名失败，系统自动回退或进入降级运行模式。
本质上，硬件信任根把配置从“被动数据”变成了“主动策略凭证”——它不再孤立存在，而是与芯片身份、启动状态、执行环境深度耦合。不复杂但容易忽略。
