☰

为什么内核在安全启动系统上拒绝我的自签名模块？

tag-icon • tag-icon linux openssl secure-boot
为什么内核在安全启动系统上拒绝我的自签名模块？

我在 Intel NUC 上安装了启用了安全启动的 Linux。它使用特殊发行版 (Balena 物联网) 不使用shim并且只注册了此发行版的密钥（没有 Microsoft 密钥）。为了进行测试，我想注册自己的 MOK 来加载自签名模块。这就是我准备密钥的方式（在我的普通 Debian 机器上）：

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=TLA gru MOK/" -keyout MOK.key -out MOK.crt -days 3650 -nodes -sha256
openssl x509 -in MOK.crt -out MOK.cer -outform DER

由于没有shim，（并且发行版不提供）我无法使用mokutil。相反，我将 NUC 重新启动到固件并注册MOK.cer为附加密钥。再次重新启动后，我检查了它是否有效：

root@692ff14:~# grep gru /proc/keys
393652e5 I------     1 perm 1f010000     0     0 asymmetri TLA gru MOK: 48dab8f63ef41164535c15799cea88cb216f52df: X509.rsa 216f52df []

root@692ff14:~# dmesg | grep "TLA gru MOK"
[    2.851781] integrity: Loaded X.509 cert 'TLA gru MOK: 48dab8f63ef41164535c15799cea88cb216f52df'

据我所知，它起作用了。所以我从 NUC 中挑选了一个随机模块，删除了现有签名，strip -g btrfs.ko并用我的密钥对其进行了签名（同样，在我的 Debian 机器上）：

/usr/lib/linux-kbuild-6.1/scripts/sign-file sha256 MOK/MOK.key MOK/MOK.cer btrfs.ko

我将其转移到 NUC，检查签名是否可用并尝试insmod：

root@692ff14:/tmp# strings btrfs.ko | tail -n 5
TLA gru MOK
>e],
6P({
#G\:q
~Module signature appended~
root@692ff14:/tmp# lsmod | grep btrfs
root@692ff14:/tmp# insmod ./btrfs.ko 
insmod: ERROR: could not insert module ./btrfs.ko: Key was rejected by service

这真令人失望。为什么这不管用？我误解了 MOK 概念吗？

非常感谢您的帮助。

答案1

这只是部分答案，因为我仍然不清楚 Linux 内核将哪些 EFI 变量加载到哪些密钥环中。

然而，将密钥注册为 MOK不是与将其注册到安全启动“db”中相同。它们是两个单独的列表，内核只从其中一个列表导入密钥，而不从另一个列表导入密钥。

（尽管它肯定不依赖于安全启动密钥，因为基本的无论如何，它都是模块验证的来源——它有一个在内核构建时生成的编译密钥。 MOK 只是一个次要来源。

但 MokManager 需要 Shim 的原因是因为 MOK 是一个与 Shim 相关的概念 - 它是不是标准安全启动功能；在 EFI 中，它仅由 Shim 注入的附加安全启动策略使用。

（并且，很有可能 - 尽管我没有检查过 - 如果 Linux 内核发现 Shim 不存在，它也可能会跳过导入 MOK，即使它实际上并不依赖 Shim 或 EFI 进行模块验证。）

因此，如果您因为没有 Shim 而无法使用 MokManager，我相信答案是安装 Shim，以便您可以使用 MokManager。

相关内容