主页 / unix / 问题 / 769760
Accepted
Dave
Asked: 2024-02-21 05:44:23 +0800 CST

如何为使用 yocto 构建的 Linux 版本启用 UEFI 安全启动？

  • 772

我正在生成 yocto 版本，并希望在我正在使用的英特尔机器上启用 UEFI 安全启动。这是一个非常基本的 yocto 构建，使用 core-image-minimal 和 meta-intel。它产生的工件如下所示：

./core-image-minimal-intel-corei7-64.wic
./bzImage-intel-corei7-64.bin
./bzImage--6.1.38+git0+d62bfbd59e_11e606448a-r0-intel-corei7-64-20240208204456.bin
./core-image-minimal-intel-corei7-64.manifest
./OvmfPkKek1.crt
./OvmfPkKek1.pem
./systemd-bootx64.efi
./core-image-minimal-intel-corei7-64-20240215181510.rootfs.tar.xz
./microcode.cpio
./modules-intel-corei7-64.tgz
./core-image-minimal-intel-corei7-64-20240215181510.rootfs.manifest
./microcode_20230808.cpio
./modules--6.1.38+git0+d62bfbd59e_11e606448a-r0-intel-corei7-64-20240208204456.tgz
./bzImage
./core-image-minimal-intel-corei7-64-20240215181510.testdata.json
./grub-efi-bootx64.efi
./ovmf.vars.qcow2
./core-image-minimal-intel-corei7-64.qemuboot.conf
./ovmf.secboot.code.qcow2
./linuxx64.efi.stub
./OvmfPkKek1.key
./ovmf.secboot.qcow2
./core-image-minimal-intel-corei7-64.tar.xz
./core-image-minimal-intel-corei7-64-20240215181510.rootfs.wic
./ovmf.code.qcow2
./core-image-minimal.env
./core-image-minimal-systemd-bootdisk-microcode.wks
./ovmf.qcow2
./core-image-minimal-intel-corei7-64-20240215181510.qemuboot.conf
./core-image-minimal-intel-corei7-64.testdata.json

我的启动分区如下所示：

./loader
./loader/loader.conf
./loader/entries
./loader/entries/boot.conf
./EFI
./EFI/BOOT
./EFI/BOOT/bootx64.efi
./bzImage

我不知道如何使用这些文件启用安全启动。有一个选项可以注册签名，当我使用 bootx64.efi 文件执行此操作，然后尝试启动时，我收到某种 bzImage 错误，然后收到有关安全策略违规的信息。

当我尝试在 USB 驱动器上随机安装 Kali Linux 时执行相同的过程时，我遇到类似（但不同）的错误。

还有 uefi 选项，如“注册签名”、“注册 PK”、“注册 KEK”等，我尝试了这些选项，希望能够选择 yocto 正在生成的 OvmfPkKek1* 文件，假设这些是密钥，但它们通过 uefi 界面浏览启动分区时，即使我复制了它们，也不会显示在磁盘上。我不知道为什么。

有什么想法可以让此安装与安全启动一起使用吗？

linux

1 个回答

  1. Best Answer

    在尝试输入其他密钥之前，请尝试清除 PK（主密钥）。这应该将安全启动置于设置模式，其中对密钥更新的限制应该最小。更新任何其他安全启动密钥变量以满足您的需求后，输入您的密钥作为 PK 以将安全启动返回到正常模式。

    首先，您需要将密钥放在dbkey 变量中，因为它是白名单：除非特别列入黑名单，否则任何*.efi使用白名单变量中的密钥签名的内容都将允许安全启动执行。

    关键dbx变量是黑名单：当加载任何使用黑名单密钥签名的文件或其哈希与黑名单哈希匹配时，固件将阻止其加载和/或不允许其执行。

    当安全启动处于正常模式时，关键KEK变量控制（编程？）更新为 和db。dbx如果可能的话，您也希望您的密钥位于此变量中。

    该PK变量控制对 KEK 变量的更新，并且仅保存一个密钥 - 最好是您的密钥，而不是系统制造商的默认密钥。

    您的OvmfPkKek1.pem文件可能是 UEFI 所需的文件，但它可能期望多种可能的格式。

    如果固件无法读取 PEM 文件（按原样或带有*.cer​​或*.crt后缀），请尝试将其转换为 DER 格式：

    openssl x509 -in OvmfPkKek1.pem -inform PEM -out OvmfPkKek1.cer -outform DER

    DER 文件的后缀可能必须是*.cer或*.crt。

    某些 UEFI 用户界面需要专门的EFI 签名列表文件 ( *.esl)，您可以使用efisiglist可能在包中找到的命令pesign或cert-to-efi-sig-list包中的命令生成这些文件efitools。

    要将 DER 格式的证书转换为 EFI 签名列表：

    efisiglist --outfile OvmfPkKek1.esl --add --certificate=OvmfPkKek1.cer

    或者

    cert-to-efi-sig-list OvmfPkKek1.cer OvmfPkKek1.esl

    当不处于安全启动设置模式时（即设置 PK 时），固件用户界面可能只接受使用安全启动密钥签名的 ESL 文件，该密钥的证书位于 KEK 或 PK 密钥变量中。这遵循与从正在运行的操作系统以编程方式更新安全启动密钥时相同的规则。如果是这样，这些文件的预期后缀可能是*.auth.

    sign-efi-sig-list包中的命令可以efitools从s生成*.auth文件*.esl。*.auth请注意，即使您使用相同的实际密钥，您也必须为每个密钥变量创建一个单独的文件：

    sign-efi-sig-list -a -c OvmfPkKek1.pem -k OvmfPkKek1.key db OvmfPkKek1.esl signed-key-for-db.auth
sign-efi-sig-list -a -c OvmfPkKek1.pem -k OvmfPkKek1.key KEK OvmfPkKek1.esl signed-key-for-KEK.auth
sign-efi-sig-list -a -c OvmfPkKek1.pem -k OvmfPkKek1.key PK OvmfPkKek1.esl signed-key-for-PK.auth
    • 1

相关问题