3. DPU启动与固件安全链

DPU（Data Processing Unit）在服务器中承担网络、存储、虚拟化与安全卸载等关键职责，其固件一旦被篡改，攻击者就可能获得与主机同等级甚至更高的控制能力。因此，Marvell DPU 从加电到操作系统加载的整个过程，都建立在一套逐级验证的“安全启动链”之上。理解这条链的每一环——信任根、固件签名、启动模式与防篡改机制——是评估 DPU 安全隔离能力的基础。

信任根：整条安全链的起点

信任根（Root of Trust, RoT）是安全启动中“无需验证即可信任”的起点。Marvell DPU 的信任根通常由芯片内部一块不可修改的 Boot ROM 代码和一组固化在一次性可编程（OTP/eFuse）区域的公钥哈希组成。Boot ROM 在芯片流片时即被固化，无法通过固件更新改写；OTP 区域写入后不可逆，用于存放厂商或客户烧录的根公钥摘要。

信任根的核心逻辑是：Boot ROM 使用 OTP 中保存的公钥哈希，去校验第一阶段引导程序（通常称为 BL1 或 FSBL）的签名。只有签名验证通过，BL1 才会被允许执行。这样，即使攻击者能够改写外部 Flash 中的固件，也无法让芯片执行未签名的代码，因为验证公钥的哈希被锁死在芯片内部。

安全启动流程：逐级验证的信任传递

Marvell DPU 的安全启动通常分为多个阶段，每个阶段验证下一阶段的镜像，形成一条信任传递链。典型流程如下：

1. 上电复位：芯片从复位向量开始执行 Boot ROM 代码。
2. BL1 验证与加载：Boot ROM 读取 OTP 中的根公钥哈希，校验 BL1 镜像的签名。验证通过后，BL1 被加载到内部 SRAM 执行。
3. BL2 验证与加载：BL1 使用自身携带的公钥（或从 OTP 派生的密钥）验证 BL2 镜像签名，BL2 通常负责初始化 DDR、时钟等基础硬件。
4. BL3x / U-Boot 验证：BL2 验证并加载 BL3x 或 U-Boot，完成更复杂的硬件初始化和启动介质选择。
5. 操作系统镜像验证：U-Boot 验证内核与设备树镜像的签名，验证通过后跳转执行。

每一级验证都包含两个动作：用公钥解密镜像的签名摘要，再对镜像本身计算哈希，两者比对一致才允许执行。任何一级失败，启动流程都会中止，芯片进入安全锁定状态或等待恢复模式。

固件签名验证：算法与密钥管理

Marvell DPU 固件签名通常采用非对称加密算法，常见选择包括 RSA-2048/3072 或 ECDSA P-256/P-384。签名过程在厂商或客户的签名服务器上完成：先对固件镜像计算 SHA-256 或 SHA-384 哈希，再用私钥对哈希值签名，最后将签名与镜像打包。验证时，Boot ROM 或上一级引导程序用对应公钥解密签名，得到原始哈希，再对镜像重新计算哈希并比对。

密钥管理是签名验证能否真正生效的关键。Marvell 平台通常支持多级密钥体系：根密钥（Root Key）的哈希烧录在 OTP 中，根密钥用于签名中间密钥，中间密钥再用于签名实际固件。这样可以在不更换根密钥的前提下轮换签名密钥，降低密钥泄露风险。实际部署中，建议将根密钥保存在 HSM（硬件安全模块）中，签名操作在 HSM 内完成，私钥永不导出。

Marvell 特定启动模式与防篡改机制

Marvell DPU 提供多种启动模式，通过硬件引脚或 OTP 配置选择。常见模式包括：

• 安全启动模式：强制逐级验签，任何未签名或签名不匹配的镜像均被拒绝。这是量产环境的默认模式。
• 恢复模式：当安全启动失败时，芯片可进入恢复模式，允许通过受控接口（如 UART、USB 或网络）加载恢复镜像。恢复镜像本身也必须经过签名验证，防止被用作绕过安全启动的入口。
• 调试/开发模式：允许加载未签名固件，通常仅在实验室使用，量产设备应通过 OTP 永久关闭。

防篡改机制方面，Marvell DPU 通常包含以下设计：

• OTP 一次性写入：根公钥哈希、安全启动使能位、调试禁用位等关键配置写入 OTP 后不可更改，防止攻击者通过改写配置绕过验证。
• 安全锁定状态：验签失败后，芯片可进入锁定状态，拒绝执行任何未验证代码，并可通过寄存器或日志记录失败原因。
• 运行时完整性校验：部分 Marvell DPU 支持在启动后对关键固件区域进行周期性哈希校验，检测运行时篡改。
• 防回滚机制：通过版本号或单调计数器，防止攻击者将固件降级到存在已知漏洞的旧版本。

实操示例：检查与配置安全启动状态

在 Marvell DPU 的 U-Boot 或 Linux 环境中，可以通过以下命令检查安全启动状态和 OTP 配置（示例参数为合理假设，实际寄存器地址和命令因芯片型号而异）：

# 查看安全启动使能状态（示例）
mw.l 0xF0A00000 0x1        # 假设安全启动使能寄存器
md.l 0xF0A00000 1          # 读取确认

# 查看 OTP 中根公钥哈希（示例）
otp read 0x100 32          # 读取 32 字节根公钥哈希
# 输出示例：a3f1...9c2e

# 查看当前启动阶段验签日志
dmesg | grep -i "secure boot"
# 输出示例：secure boot: BL1 signature verified
#          secure boot: BL2 signature verified
#          secure boot: OS image signature verified

判断安全启动是否生效，可以观察三个信号：一是启动日志中每一级都出现“signature verified”记录；二是尝试加载未签名镜像时启动被拒绝并进入锁定或恢复模式；三是 OTP 中安全启动使能位为 1 且调试禁用位为 1。如果日志中缺少某一级验签记录，或未签名镜像仍能执行，则说明该级验证可能被跳过或配置有误。

信任链的边界与常见误区

安全启动链的信任边界止于操作系统内核加载。内核启动后，是否继续验证用户态组件、容器镜像或卸载固件，取决于上层安全策略。DPU 的安全隔离能力不仅依赖启动链，还需要运行时隔离、内存保护与访问控制配合。常见误区包括：认为“安全启动开启即万事大吉”，忽视 OTP 中调试位未关闭；或只验证内核而忽略设备树与卸载固件，导致攻击者通过篡改设备树改变硬件行为。正确做法是将启动链视为基础设施安全的第一道门，而非唯一防线。