Fedora 23下UEFI安全启动安装VirtualBox内核模块签名

Fedora 23下UEFI安全启动安装VirtualBox内核模块签名

在启用 UEFI 安全启动（Secure Boot）的现代 Linux 系统中，内核对加载第三方模块施加了严格限制：所有进入内核空间的代码必须经过数字签名验证。这一机制有效提升了系统安全性，但也给 VirtualBox 这类依赖动态编译内核模块的软件带来了实际困扰。

当你在 Fedora 23 上安装 VirtualBox 后尝试启动服务时，可能会遇到如下错误：

Starting VirtualBox kernel modules [失败] (modprobe vboxdrv failed. Please use 'dmesg' to find out why)

即使 DKMS 已成功为当前内核编译出vboxdrv.ko模块，它仍会被内核拒绝加载——原因正是缺少合法签名。这个问题并非 VirtualBox 的缺陷，而是 Secure Boot 设计逻辑下的必然结果。

要让 VirtualBox 正常运行，我们必须“说服”内核信任我们的模块。这需要一套完整的信任链构建流程：从生成专属密钥开始，到将公钥注册进机器所有者密钥（MOK），再到使用私钥对模块进行签名，最终实现模块的顺利加载。

整个过程听起来复杂，但只要一步步来，并理解每一步背后的原理，其实并不难掌握。

我们使用的环境是Fedora 23 x86_64，内核版本为4.4.6-301.fc23.x86_64，VirtualBox 版本为 5.0.18。首先确认安全启动已启用：

$ mokutil --sb-state SecureBoot enabled

如果显示禁用状态，则无需处理签名问题；但一旦开启，就必须面对这个绕不开的环节。

安装 VirtualBox 并触发模块编译

通过 DNF 安装官方提供的 RPM 包：

sudo dnf install VirtualBox-5.0-5.0.18_106667_fedora22-1.x86_64.rpm

安装过程中会自动调用 DKMS 编译适用于当前内核的驱动模块。虽然输出日志中提示“no precompiled module found”，并随后执行了编译动作，但最后仍然报错：

Starting VirtualBox kernel modules [失败]

这是预期行为。此时模块文件已经存在于/lib/modules/$(uname -r)/extra/vboxdrv.ko等路径下，只是尚未签名，无法被加载。

你可以用以下命令检查模块是否存在：

modinfo vboxdrv

若返回路径信息而非错误，则说明编译成功，接下来只需解决签名问题即可。

创建签名密钥对：信任的起点

我们需要一个 X.509 证书来签署模块。注意，这不是用于加密通信的 TLS 证书，而是一个专门用于内核模块签名的身份凭证。

先创建工作目录：

mkdir -p ~/vbox/x509 && cd ~/vbox/x509

然后准备 OpenSSL 配置文件：

cat << EOF > configuration_file.config [ req ] default_bits = 4096 distinguished_name = req_distinguished_name prompt = no string_mask = utf8only x509_extensions = myexts [ req_distinguished_name ] O = Organization CN = Organization signing key emailAddress = admin@example.com [ myexts ] basicConstraints=critical,CA:FALSE keyUsage=digitalSignature subjectKeyIdentifier=hash authorityKeyIdentifier=keyid EOF

这里的CN字段建议改为更具辨识度的名字，比如 “VirtualBox Module Signing Key”，方便后续识别。

接着生成密钥对：

openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \ -batch -config configuration_file.config \ -outform DER -out public_key.der -keyout private_key.priv

你会得到两个关键文件：
-public_key.der：公钥，需导入 MOK
-private_key.priv：私钥，用于签名，务必妥善保管

⚠️ 提示：不要将私钥提交到 Git 或任何共享位置。一旦泄露，攻击者可借此签名恶意模块并加载进你的系统。

注册公钥至 MOK：建立信任锚点

Linux 内核维护了一个名为.system_keyring的密钥环，其中包含所有被允许加载签名模块的公钥。由于 Secure Boot 的限制，普通用户不能直接向该密钥环写入数据，因此引入了 MOK（Machine Owner Key）机制——由用户自己管理的一组额外受信密钥。

使用mokutil将公钥加入待注册队列：

sudo mokutil --import public_key.der

系统会要求你设置一个临时密码。这个密码仅用于下次启动时的身份确认，不会持久保存。

验证是否登记成功：

mokutil --list-new

你应该能看到刚导入的证书指纹和基本信息。这意味着重启后系统将提示你完成注册。

重启并完成密钥导入：信任落地的关键一步

执行重启：

reboot

在 GRUB 菜单之后，系统会进入蓝色背景的MOK Management Interface。选择 “Enroll MOK” → “Continue” → “Yes”，然后输入之前设定的密码。

这一步非常关键。如果你跳过了这个界面（例如快速启动或 BIOS 设置问题），密钥就不会真正注册进系统。务必确保你在物理控制设备的前提下操作，防止他人恶意注入密钥。

验证公钥已加载：确认信任生效

重新登录系统后，检查.system_keyring是否包含了新添加的公钥：

sudo keyctl list %:.system_keyring

查找类似以下条目：

asymmetric: Organization signing key: 53976377753f4dcfd66877d53f7a9736a9bec764

如果有，说明你的公钥已被内核信任，现在可以放心地签名模块了。

使用 sign-file 对模块签名：赋予合法性

签名工具来自内核源码树中的scripts/sign-file，Fedora 默认已安装对应开发包。找到路径：

/usr/src/kernels/$(uname -r)/scripts/sign-file

该工具接受哈希算法、私钥、公钥和模块路径作为参数，向.ko文件末尾附加一段 PKCS#7 格式的签名数据。

批量签名四个核心模块：

for mod in vboxpci vboxnetadp vboxnetflt vboxdrv; do sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \ private_key.priv public_key.der $(modinfo -n $mod) done

这里使用sha512是为了兼容性和强度考虑，尽管配置中用了 SHA-256，但签名过程支持更强的哈希。

📌 注意事项：
- 必须以 root 权限运行，否则无法写入模块文件。
-$(modinfo -n $mod)动态获取模块路径，避免硬编码错误。
- 公钥文件虽不参与签名计算，但用于提取指纹匹配已注册的 MOK 项。

如何验证签名是否成功？

最直接的方式是查看模块文件末尾是否有附加签名标记：

hexdump -C $(modinfo -n vboxdrv) | tail -n 5

正常输出应包含：

000845c0 ... 4d 6f 64 75 6c 65 20 73 69 67 6e 61 74 75 72 65 |Module signature| 000845d0 20 61 70 70 65 6e 64 65 64 7e 0a | appended~.|

这段文本是内核模块签名机制的标准标识，表明签名已正确附加。

不过要注意：modinfo命令不会显示签名信息。这是设计如此——签名是以独立段落形式附加在文件末尾，不影响 ELF 头部结构，因此modinfo解析不到相关内容。不要误以为没签上。

加载模块并启动 VirtualBox

现在尝试手动加载主模块：

sudo modprobe vboxdrv

如果没有报错，说明签名有效。继续加载其余模块：

sudo modprobe vboxnetflt sudo modprobe vboxnetadp sudo modprobe vboxpci

或者一次性启动服务：

sudo systemctl restart vboxservice

也可以直接运行 GUI：

virtualbox &

如果一切顺利，VirtualBox 应能正常创建虚拟机、配置网络桥接等功能。

常见问题排查指南

❌modprobe vboxdrv失败，提示 “Required key not available”

这是最常见的错误，意味着内核找不到匹配的公钥来验证签名。

检查点：
- 是否完成了 MOK 导入？运行mokutil --list-enrolled | grep "Organization"查看是否列出你的证书。
- 公钥指纹是否一致？可用openssl x509 -in public_key.der -inform DER -noout -fingerprint对比。
- 是否更换过内核？新内核需重新签名模块。

❌ MOK 管理界面未弹出

可能原因包括：
- 安全启动被关闭；
-mok_newEFI 变量未正确写入；
- 快速启动跳过了 MOK 提示。

解决方法：
- 确认mokutil --list-new有输出；
- 若无输出，重新执行sudo mokutil --import public_key.der；
- 进入 BIOS 检查 Secure Boot 是否启用。

❌ 找不到模块文件或编译失败

运行：

cat /var/log/vbox-install.log

常见问题是缺少内核头文件。请安装：

sudo dnf install kernel-devel kernel-headers

然后重建模块：

sudo /sbin/vboxconfig

此外，升级内核后旧模块会被清除，必须重新编译并签名。

自动化脚本提升效率

为了避免每次更新内核或重装 VirtualBox 都重复繁琐的手工步骤，推荐编写一个签名脚本：

#!/bin/bash KERN_VERSION=$(uname -r) KEY_DIR="$HOME/vbox/x509" if [[ ! -f "$KEY_DIR/private_key.priv" || ! -f "$KEY_DIR/public_key.der" ]]; then echo "Error: Private or public key not found in $KEY_DIR" exit 1 fi for mod in vboxdrv vboxnetflt vboxnetadp vboxpci; do mod_path=$(modinfo -n $mod 2>/dev/null) if [[ $? -ne 0 ]]; then echo "Module $mod not found. Skipping." continue fi echo "Signing $mod ($mod_path)" sudo "/usr/src/kernels/${KERN_VERSION}/scripts/sign-file" sha512 \ "$KEY_DIR/private_key.priv" "$KEY_DIR/public_key.der" "$mod_path" done echo "All modules signed successfully."

保存为sign-vbox-modules.sh，并赋予权限：

chmod +x sign-vbox-modules.sh

以后每当系统更新后，只需运行此脚本即可快速恢复 VirtualBox 功能。

安全建议不容忽视

1. 保护私钥
   bash chmod 600 ~/vbox/x509/private_key.priv
   避免被其他用户或程序读取。

2. 定期轮换密钥
   长期使用同一密钥增加风险。建议每 1～2 年更换一次，重新导入 MOK。

3. 避免公开公钥
   虽然理论上公钥可公开，但上传到 GitHub 或论坛可能引来不必要的关注甚至针对性攻击。

4. 清理旧模块
   升级 VirtualBox 后，旧版本模块仍可能存在。建议清理 DKMS 记录：
   bash sudo dkms remove virtualbox-host-modules/5.0.18 --all

这套方案的核心价值不仅在于解决 VirtualBox 的运行问题，更在于它揭示了 Linux 在 Secure Boot 环境下的模块信任模型。掌握了这套机制，你同样可以应用于 NVIDIA 私有驱动、ZFS on Linux、WireGuard 自定义编译等场景。

事实上，这种“自签名 + MOK 注册”的模式已成为现代 Fedora、Ubuntu 和 openSUSE 等主流发行版处理第三方内核模块的事实标准。

虽然初始配置稍显繁琐，但它带来的不仅是功能恢复，更是对系统底层机制的深入理解。当你亲手建立起这条信任链时，你就不再只是一个使用者，而成了系统的掌控者。