2. Ryzen Embedded硬件信任根剖析
在 Ryzen Embedded 平台上，安全启动并不是从操作系统加载器才开始的，而是从芯片上电那一刻就由硬件信任根（Hardware Root of Trust，HRoT）接管。理解 HRoT 的关键，是把它看成一组“不可被软件改写、且必须先于一切可写代码运行”的硬件与固件组合。本节围绕四个核心对象展开：AMD 安全处理器（AMD Secure Processor，AMD-SP）、平台安全处理器（Platform Security Processor，PSP）、硬件熔丝（eFuse）以及片上不可变 ROM（Boot ROM）。它们共同决定了“谁先运行、信任从哪里来、密钥如何被验证、启动链如何被逐级度量”。
一、四个对象的角色定位
AMD-SP 是集成在 SoC 内部的一个独立 ARM 微控制器子系统，拥有自己的 ROM、SRAM 和受限外设访问通道。它不运行 x86 主核代码，而是作为整个平台的“安全管家”，负责上电初始化、固件验证、密钥管理和安全服务。PSP 是 AMD-SP 在具体产品线中的实现称谓，在 Ryzen Embedded 文档与工具链中两者常互换使用；可以理解为：AMD-SP 是架构概念，PSP 是 Ryzen 平台上的落地实体。
硬件熔丝是一组一次性可编程（OTP）存储单元，位于芯片内部，出厂后不可逆。它保存的是“信任的起点”：根密钥哈希、安全启动使能位、调试端口锁定状态、芯片唯一标识等。熔丝内容在制造或产线烧录阶段写入，之后任何软件、固件甚至 AMD-SP 自身都无法修改。不可变 ROM 则是 AMD-SP 内部固化的第一段代码，芯片流片时即确定，不可擦写。它只做最少的初始化，然后从外部 SPI Flash 读取并验证下一阶段固件。
二、启动流程中的定位与信任传递
上电复位后，x86 主核处于复位保持状态，AMD-SP 率先从自己的 Boot ROM 开始执行。Boot ROM 读取 eFuse 中的根密钥哈希与安全启动策略，然后从 SPI Flash 的 PSP 目录区加载第一阶段引导程序（通常称为 PSP Bootloader 或 Stage1）。Boot ROM 使用熔丝中的根密钥哈希验证 Stage1 的签名，验证通过后才将控制权交给 Stage1。Stage1 继续加载并验证第二阶段固件（如 PSP OS 或安全监控固件），随后才释放 x86 主核复位，让主核从 BIOS/UEFI 固件开始执行。主核侧的固件同样由 AMD-SP 参与验证，形成一条从熔丝到 Boot ROM、到 PSP 固件、再到 x86 固件的完整信任链。
这条链的核心逻辑是：每一级代码在被执行前，都必须由上一级已可信的代码验证其签名或哈希。熔丝提供不可篡改的根，Boot ROM 提供不可篡改的验证逻辑，AMD-SP 提供执行验证的独立环境，SPI Flash 中的固件则是被验证对象。四者缺一不可。
三、关键参数与验证判断
在实际工程中，判断信任根是否正常建立，可以观察几个关键点。第一，eFuse 中的安全启动使能位必须为“已烧录”状态，否则 Boot ROM 会跳过签名验证，信任链退化为普通启动。第二，Boot ROM 验证 Stage1 时使用的根密钥哈希必须与熔丝中存储的值一致；若 SPI Flash 中的 Stage1 被替换或签名不匹配，AMD-SP 会拒绝加载，x86 主核保持复位，平台无显示输出。第三，Stage2 加载后，PSP 会通过安全邮箱接口向主核固件提供度量值，工程上可通过 AMD 提供的 PSP 工具或 BIOS 日志读取这些度量，确认每一级哈希与预期一致。
一个常见的教学示例参数是：假设某 Ryzen Embedded 板卡使用 RSA-4096 签名，Stage1 镜像大小约 256 KB，Boot ROM 验证耗时在毫秒级。若将 eFuse 中的调试锁定位置为“锁定”，则 JTAG 调试端口在启动后不可用，这既是安全要求，也会影响产线调试策略，需要在烧录熔丝前完成所有调试工作。
四、与后续启动阶段的关系
硬件信任根只负责“把第一块可信代码跑起来”。当 x86 主核开始执行 BIOS/UEFI 后，信任链进入软件阶段：UEFI 安全启动、操作系统加载器验证、内核模块签名等。但所有这些后续机制的前提，是 AMD-SP 已经成功完成了硬件级验证。如果熔丝、Boot ROM 或 PSP 固件任一环节被破坏，后续所有软件安全机制都失去意义。因此，在 Ryzen Embedded 安全启动工程中，硬件信任根不是可选项，而是整个安全体系的基座。
理解这四个对象的分工，也有助于排障：平台不上电、无显示、PSP 日志报签名错误，通常指向 SPI Flash 固件与熔丝策略不匹配；平台能启动但安全启动未生效，则要检查 eFuse 使能位是否真正烧录，以及 Boot ROM 是否走了验证分支。把问题定位到信任链的具体一级，比盲目更换固件更有效。