【8-2】OptionROM如何满足Secure Boot

0. 启用Secure Boot的平台加载、校验、运行Option ROM 流程

1. 背景与问题说明（Why）

在启用 UEFI Secure Boot 的平台上（包括 x86 与 ARM）：

• PCIe 设备的 Option ROM（EFI 驱动） 在 UEFI DXE 阶段加载前 必须通过平台的 Secure Boot 签名校验

否则会出现典型现象：

• 设备在 PCIe 枚举阶段可见
• Option ROM 未被自动加载
• 但在 UEFI Shell 中用 loadpcirom 手动加载可运行

👉 这是“签名未被平台信任”的典型表现

2. 总体原则（所有平台通用）

2.1 Secure Boot 的本质

Secure Boot 不是“能不能执行”，

而是“是否被平台信任并允许自动执行”。

平台通过以下数据库判断信任关系：

2.2 Option ROM 的加载规则（简化版）

PCIe 枚举
  ↓
发现 Option ROM
  ↓
UEFI 验证签名
  ↓
✔ 通过 → 自动加载
✘ 失败 → 忽略（但不报错）

3. x86 平台 Option ROM 签名机制

3.1 主流 x86 平台的事实标准

👉 这不是厂商选择，是行业共识

3.2 x86 平台的可行签名路径

✅ 路径一（推荐 / 通用）

Microsoft UEFI CA 签名

• Option ROM EFI：
  • 提交给 Microsoft
• Microsoft：
  • 使用 UEFI CA 证书签名
• 结果：
  • 几乎所有 x86 主机 即插即用

❌ 路径二（理论存在，工程不可控）

• OEM 自定义 db
• 用户手工导入证书

👉 不适合商用设备 / 量产

3.3 x86 平台实施步骤（摘要）

1. 准备符合规范的 EFI Option ROM
2. 使用 公司代码签名证书
3. 在 Microsoft Hardware Dev Center 提交
4. 获取微软签名后的 EFI
5. 烧录到 Option ROM

4. ARM 平台（飞腾 S2500）Option ROM 签名机制

4.1 ARM 平台的共性

👉 ARM 没有统一的“全球 CA”

4.2 飞腾平台的可行签名路径

路径一：使用飞腾平台信任的 CA（理想）

• 获取：
  • 飞腾 db 中信任的 CA
• 用该 CA 给 Option ROM 签名

⚠️ 现实难点：

• CA 私钥通常不对外
• 厂商流程复杂

路径二（实际最优）：Microsoft UEFI CA

越来越多 ARM 服务器平台

已将 Microsoft UEFI CA 加入 db

优势：

• x86 / ARM 统一方案
• Option ROM 一次签名，多平台使用
• 行业兼容性最好

5. Option ROM 技术与签名要求 Checklist

5.1 Option ROM 本身必须满足

• PE32+/EFI Binary
• 正确的 Machine Type（x86_64 / AArch64）
• 使用 EDK2 RELEASE 构建
• 含 EFI ROM Header
• 不包含 DEBUG_PRINT

5.2 签名层面的硬性要求

• 使用 Authenticode（PKCS#7）
• SHA-256
• 不能二次修改二进制
• 不使用自签证书

6. 签名实施的统一推荐方案

6.1 方案概述

采用 Microsoft UEFI CA 作为统一信任根，
对 PCIe Option ROM 进行签名，
同时支持 x86 与 ARM 服务器平台。

6.2 需要准备的资源

6.3 成本与收益

成本：

• 证书费用：¥2000–6000 / 年
• 一次性流程学习成本

收益：

• Secure Boot 下自动加载
• x86 / ARM 双平台通用
• 消除客户环境差异问题
• 满足合规 / 安全要求