📚 课程目录第4章 IGX启动与固件验证

4. IGX启动与固件验证

IGX平台的启动过程是一条从硬件信任根到操作系统加载器的严格信任链。生产测试中，任何一环的固件版本、签名状态或配置偏移都会导致启动失败或安全降级。理解这条链路的每个阶段及其可测试点，是产线快速定位问题的前提。

启动链路与信任根

IGX的启动分为四个主要阶段：BootROM、UEFI固件、BSP引导组件、操作系统加载器。BootROM固化在SoC内部，是绝对信任根，负责从eFuse读取安全启动配置、验证下一级固件的签名，并将控制权交给UEFI。UEFI阶段包含PEI、DXE、BDS三个子阶段，负责内存初始化、设备枚举和启动项选择。BSP提供平台特定的ACPI表、设备树和驱动，最终由GRUB或UEFI直接加载Linux内核。

安全启动的核心是密钥层级：NVIDIA签发的PKI密钥用于签名UEFI固件，OEM密钥用于签名BSP和内核。eFuse中的公钥哈希（PK Hash）和Secure Boot使能位决定了设备是否强制验证签名。生产测试必须确认这些一次性可编程位已正确烧录，且各级固件签名与密钥链匹配。

BootROM阶段测试

BootROM的行为由eFuse配置决定，产线无法修改其代码，但必须验证eFuse烧录结果。测试方法是通过JTAG或SoC内部寄存器读取以下关键位：SECURE_BOOT_EN（安全启动使能）、PK_HASH（公钥哈希，通常为256位）、ODM_PROD_MODE（生产模式标志）。若SECURE_BOOT_EN=0，BootROM将跳过签名验证直接加载UEFI，这在生产设备上属于严重安全缺陷。

实际操作中，可在U-Boot或Linux下通过devmem读取eFuse影子寄存器。例如，Tegra系列eFuse基址通常为0x0x7000F000附近，具体偏移需查阅对应SoC的TRM。读取后与烧录记录比对，确认PK Hash与OEM密钥哈希一致。若发现不一致，需检查烧录工装是否使用了错误的密钥文件。

UEFI固件验证

UEFI固件验证分为版本确认和签名验证两部分。版本确认可通过dmidecode -t bios或fwupdmgr get-devices获取当前UEFI版本号，与BSP发布说明中的推荐版本比对。签名验证则需确认UEFI固件由NVIDIA PKI密钥签名，且签名链可追溯至eFuse中烧录的PK Hash。

在Linux下，可使用sbverify工具检查UEFI固件签名：

sbverify --list /boot/efi/EFI/nvidia/grubaa64.efi
# 输出示例：
# signature 1
# image signature issuers:
#  - /C=US/O=NVIDIA Corporation/CN=NVIDIA UEFI Signing CA
# image signature certificates:
#  - subject: /C=US/O=NVIDIA Corporation/CN=NVIDIA UEFI Signing CA
#    issuer:  /C=US/O=NVIDIA Corporation/CN=NVIDIA Root CA

若签名验证失败，UEFI会记录到事件日志中，可通过efivar -l查看SecureBoot和PK、KEK变量状态。生产测试中应确认SecureBoot=1且PK非空。

BSP与内核签名验证

BSP包含设备树、ACPI表和内核模块，其签名由OEM密钥完成。测试时需确认BSP版本与UEFI版本兼容，可通过cat /etc/nv_tegra_release或dpkg -l | grep nvidia-igx-bsp获取BSP版本。内核模块签名可通过modinfo检查：

modinfo nvidia.ko | grep sig
# 输出示例：
# sig_id:         PKCS#7
# signer:         IGX OEM Signing Key
# sig_key:        3A:5B:...
# sig_hashalgo:   sha256

若内核模块未签名或签名密钥不在UEFI的db数据库中，模块加载将被拒绝，导致GPU驱动无法初始化。此时dmesg会输出"module verification failed: signature and/or required key missing"。

安全启动流程的故障排查

安全启动故障通常表现为启动挂起、串口输出安全违规信息或系统降级到非安全模式。排查时按以下顺序进行：

确认eFuse状态：读取SECURE_BOOT_EN和PK_HASH，确保与预期一致。
检查UEFI签名：使用sbverify验证UEFI固件签名链，确认签名者与eFuse中PK Hash匹配。
检查BSP签名：验证内核模块签名密钥是否已注册到UEFI db或MOK中。
查看启动日志：通过串口捕获UEFI阶段输出，关注"Security Violation"、"Image Authentication Failed"等关键字。
确认启动项顺序：使用efibootmgr -v检查启动项是否指向正确的已签名加载器。

注意：若设备已烧录eFuse且SECURE_BOOT_EN=1，则无法回退到未签名固件。产线测试必须在烧录eFuse之前完成所有固件版本和签名验证，避免不可逆的安全锁定。

产线测试用例示例

以下为一个可执行的产线测试脚本片段，用于自动化验证启动链关键状态：

#!/bin/bash
# IGX启动与固件验证测试用例
PASS=0; FAIL=0

# 1. 检查Secure Boot状态
SB=$(efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot -p | xxd -p | tail -c 2)
if [ "$SB" = "01" ]; then echo "[PASS] SecureBoot enabled"; ((PASS++));
else echo "[FAIL] SecureBoot disabled"; ((FAIL++)); fi

# 2. 检查UEFI版本
UEFI_VER=$(dmidecode -s bios-version)
echo "[INFO] UEFI version: $UEFI_VER"

# 3. 验证UEFI签名
if sbverify --list /boot/efi/EFI/nvidia/grubaa64.efi 2>&1 | grep -q "NVIDIA"; then
  echo "[PASS] UEFI signature valid"; ((PASS++));
else echo "[FAIL] UEFI signature invalid"; ((FAIL++)); fi

# 4. 检查内核模块签名
if modinfo nvidia.ko 2>/dev/null | grep -q "sig_id"; then
  echo "[PASS] nvidia.ko signed"; ((PASS++));
else echo "[FAIL] nvidia.ko unsigned"; ((FAIL++)); fi

# 5. 检查BSP版本
BSP_VER=$(dpkg -l | grep nvidia-igx-bsp | awk '{print $3}')
echo "[INFO] BSP version: $BSP_VER"

echo "Result: PASS=$PASS FAIL=$FAIL"

该脚本在产线烧录后自动运行，输出结果写入测试记录。若FAIL大于0，设备进入返修流程，需人工检查eFuse烧录记录和固件签名文件。

常见故障与处理

故障现象	可能原因	处理方法
串口输出"Security Violation"	UEFI签名与eFuse PK Hash不匹配	重新烧录正确签名的UEFI固件，或检查eFuse烧录密钥
启动挂起在BDS阶段	启动项指向未签名加载器	使用efibootmgr修正启动项，或重新签名加载器
nvidia.ko加载失败	模块签名密钥未注册到db/MOK	将OEM签名密钥导入UEFI db或MOK，重新签名模块
ACPI表解析错误	BSP与UEFI版本不兼容	升级BSP至与UEFI匹配的版本，或回退UEFI
SecureBoot显示为0	eFuse未烧录或烧录失败	检查烧录工装和eFuse烧录记录，重新烧录

产线测试中，建议将上述检查项集成到自动化测试框架中，每台设备启动后自动执行并记录结果。对于安全启动相关故障，优先通过串口日志定位失败阶段，再针对性检查对应固件的签名和版本。所有固件版本和签名状态应记录到设备测试档案中，便于后续追溯。