3. UEFI安全启动原理：固件启动流程、安全数据库与签名验证

安全启动（Secure Boot）这个话题，说白了就是解决一个问题：你怎么知道当前加载的这段代码是可信的？ 我刚开始接触UEFI时，觉得这玩意儿就是个开关，打开就安全，关上就裸奔。后来踩了几个坑才明白，它背后是一整套密码学信任链。

咱们这一章，就把UEFI安全启动的底裤扒开看看。从固件怎么启动，到数据库怎么存证书，再到签名怎么验，一条线捋清楚。

3.1 UEFI固件启动流程：信任链的起点

先看整体流程。我习惯把UEFI启动分成四个阶段，每个阶段都有一道签名验证的关卡。

嗯，这里要注意：SEC阶段是硬件信任根。CPU上电后第一条指令就在SEC里，它负责验证PEI阶段的代码。如果SEC被篡改，整个信任链就崩了。我在某款国产平台上就遇到过SEC阶段签名校验没做完整，结果被植入恶意PEI模块的情况。

3.2 安全数据库：db、dbx、dbt

安全启动的核心，就是三个数据库。它们存储在固件的非易失性变量里，由平台密钥（PK）保护。

3.3 签名验证机制：到底怎么验？

签名验证不是简单比个哈希。它分三步走：

1. 提取签名：从EFI镜像的WIN_CERTIFICATE结构中提取PKCS#7签名数据。
2. 查黑名单：先查dbx，看签名者证书或镜像哈希是否被吊销。如果命中，直接拒绝。
3. 查白名单：再查db，看签名者证书是否在信任链中。如果在，用公钥验签；如果不在，拒绝。

为什么会先查dbx再查db？你想想看，如果某个证书同时出现在db和dbx里，那应该以谁为准？dbx优先级更高。这是安全设计的基本原则——宁可错杀，不可放过。

3.4 代码示例：验证一个EFI模块的签名

下面是我在实际项目中写的一段验证逻辑（简化版），展示了核心流程：

// 伪代码：UEFI安全启动签名验证
EFI_STATUS VerifyImageSignature(
    IN  VOID   *ImageBase,
    IN  UINTN  ImageSize,
    OUT BOOLEAN *IsTrusted
) {
    WIN_CERTIFICATE *Cert;
    EFI_IMAGE_DATA_DIRECTORY *SecDir;

    // 1. 定位安全目录
    SecDir = GetSecurityDirectory(ImageBase);
    if (SecDir == NULL || SecDir->Size == 0) {
        *IsTrusted = FALSE;
        return EFI_UNSUPPORTED;
    }

    // 2. 提取PKCS#7签名
    Cert = (WIN_CERTIFICATE *)((UINT8 *)ImageBase + SecDir->VirtualAddress);
    if (Cert->wCertificateType != WIN_CERT_TYPE_PKCS_SIGNED_DATA) {
        *IsTrusted = FALSE;
        return EFI_INVALID_PARAMETER;
    }

    // 3. 计算镜像哈希（排除签名区域）
    UINT8 Hash[SHA256_DIGEST_SIZE];
    CalculateImageHash(ImageBase, ImageSize, Cert, Hash);

    // 4. 查dbx（黑名单）
    if (IsInDbx(Cert, Hash)) {
        *IsTrusted = FALSE;
        return EFI_SECURITY_VIOLATION;
    }

    // 5. 查db（白名单）并验签
    if (!VerifyAgainstDb(Cert, Hash)) {
        *IsTrusted = FALSE;
        return EFI_ACCESS_DENIED;
    }

    *IsTrusted = TRUE;
    return EFI_SUCCESS;
}

3.5 安全启动的三种模式

UEFI规范定义了三种安全启动模式，我习惯用一张表来对比：

我个人习惯在开发阶段用Audit Mode。这样既能看到哪些模块签名有问题，又不会直接导致系统启动失败。等所有驱动都验证通过后，再切到User Mode。

3.6 避坑指南：安全启动常见问题

• 签名算法不匹配：db里存的是RSA-2048证书，但镜像用的是SHA-1哈希。UEFI 2.5之后已经弃用SHA-1，建议统一用SHA-256。
• 证书链不完整：中间CA证书没导入db，导致叶子证书验签失败。我遇到过某厂商只导入了根证书，结果所有子CA签发的驱动都无法加载。
• dbx更新后无法回滚：这是设计如此——吊销就是不可逆的。所以更新前一定要备份原始固件，或者准备硬件恢复方案。
• 时间戳问题：dbt里的吊销时间戳如果比系统RTC时间还晚，会导致已吊销的签名仍然通过验证。嗯，这里要注意RTC电池没电的情况。