☰

Kali Linux 中安全启动时出现“错误：/boot/vmlinuz-6.6.9-amd64 签名无效”

tag-icon • tag-icon kali-linux grub2 uefi secure-boot signature
Kali Linux 中安全启动时出现“错误：/boot/vmlinuz-6.6.9-amd64 签名无效”

当我尝试在启用安全启动的情况下运行 Kali Linux 系统时，GRUB 返回“error: /boot/vmlinuz-6.6.9-amd64 has invalid signature.我不想关闭安全启动”。我已按照此处的指示进行操作：https://www.reddit.com/r/archlinux/comments/10pq74e/my_easy_method_for_setting_up_secure_boot_with
我用命令grub-install --target=x86_64-efi --efi-directory=/boot/efi --modules="tpm" --disable-shim-lock重新安装grub。
我正在双启动 Windows 11 和 Kali Linux。
我运行的是 HP Envy x360。

答案1

中的说明您链接的 Reddit 帖子grubx64.efi仅当安装的程序经过 Microsoft 签名后才有效grub-install- 显然 Arch 可能已经花费了时间和金钱来做到这一点。

Debian 选择以不同的方式做事，并且由于 Kali 基于 Debian，因此同样的方法可能也适用于 Kali。在 Debian 的安全启动解决方案中，只有shimx64.efiMicrosoft 签名：

/boot/efi/EFI/debian# pesign -S -i shimx64.efi 
---------------------------------------------
certificate address is 0x7f0756f2a498
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher  <--- Microsoft!
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------

Debian 实际上将 shim 构建为可重现的二进制文件，因此他们可以将分离的 Microsoft 签名作为单独的文件与 shim 源代码一起提供，如果您希望审核 shim，您可以自己构建它并向其添加签名，并且如果您使用了正确的编译器版本和确切的过程，生成的构建将与 Debian 100% 相同，因此签名在附加到它时将是有效的。

使用时，会将Debian的Secure Boot证书非持久性的添加到白名单中，然后系统就可以启动Debian的了grubx64.efi，这是由Debian的证书签名的。

/boot/efi/EFI/debian# pesign -S -i grubx64.efi 
---------------------------------------------
certificate address is 0x7f87b4b03008
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Debian Secure Boot Signer 2022 - grub2  <- no MS, just Debian
No signer email address.
Signing time: Wed Oct 04, 2023
There were certs or crls included.
---------------------------------------------

这使得 Debian 在 GRUB 更新方面具有更大的灵活性，因为他们不必等待 Microsoft 签署新版本。该填充程序应该是一段非常简单且经过彻底审核的代码，因此预计需要较少的更新。

Kali 必须拥有其发行版自己的签名，因为 Kali 发行版显然无法访问 Debian 的私钥。

Reddit 帖子中的食谱很大程度上依赖于sbctl.它似乎是systemd-boot引导加载程序的一部分，默认情况下只关心systemd-boot.这显然就是 Reddit 发帖者必须这样做的原因：

检查哪些文件需要签名才能使安全启动正常工作：

sudo sbctl verify

签署所有未签名的文件（以下是我需要签名的内容，根据您的需要进行调整）：

sudo sbctl sign -s /efi/EFI/GRUB/grubx64.efi

如果 Kali 遵循 Debian 的模型，那么 Kali 的内核已经签名 - 但不是使用sbctl.也许sbctl只是检测到内核已经签名，所以没有告诉您现在需要重新签名你的钥匙？

或者也许确实如此，并且生成的内核现在具有多个签名。这应该这是可能的，但这可能是安全启动规范中测试不充分的领域，因此某处可能存在错误。也许签名应用不正确，无法验证？或者，也许您的 UEFI 固件（只要固件例程用于磁盘访问，它最终负责验证安全启动签名 - 就像 UEFI 版本的 GRUB 一样）在处理多重签名启动文件时存在错误？

相关内容