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 功能。
安全建议不容忽视
保护私钥
bash chmod 600 ~/vbox/x509/private_key.priv
避免被其他用户或程序读取。定期轮换密钥
长期使用同一密钥增加风险。建议每 1～2 年更换一次，重新导入 MOK。避免公开公钥
虽然理论上公钥可公开，但上传到 GitHub 或论坛可能引来不必要的关注甚至针对性攻击。清理旧模块
升级 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 等主流发行版处理第三方内核模块的事实标准。
虽然初始配置稍显繁琐，但它带来的不仅是功能恢复，更是对系统底层机制的深入理解。当你亲手建立起这条信任链时，你就不再只是一个使用者，而成了系统的掌控者。
