VMware虚拟机里装Linux驱动总报错？搞定‘Key was rejected by service’的保姆级避坑指南

VMware虚拟机中解决Linux驱动签名错误的终极指南

当你在VMware虚拟机中尝试加载自行编译的Linux驱动模块时，可能会遇到令人沮丧的"Key was rejected by service"错误。这个看似简单的提示背后，隐藏着虚拟机环境特有的安全机制和配置差异。本文将深入剖析这一问题的根源，并提供针对VMware环境的详细解决方案。

1. 理解错误背后的安全机制

在Linux系统中，内核模块签名是一项重要的安全特性，旨在防止未经认证的代码加载到内核空间。当系统启用了Secure Boot（安全启动）功能时，所有内核模块都必须经过有效签名才能加载。虚拟机环境中的这一机制与物理机存在显著差异，这也是许多用户在VMware中遇到问题的根本原因。

虚拟机特有的三个关键差异点：

1. UEFI固件实现不同：VMware使用虚拟化的UEFI固件，其配置界面和选项位置与物理主板不同
2. Secure Boot管理方式：虚拟机中的Secure Boot通常需要通过VMware设置界面而非传统BIOS配置
3. EFI变量支持：某些虚拟机配置可能默认不支持EFI变量存储，导致密钥管理工具无法正常工作

提示：即使在主机系统已禁用Secure Boot的情况下，虚拟机仍可能独立启用此功能，这是许多用户忽略的关键点。

2. VMware环境下的Secure Boot配置

针对VMware Workstation和Player用户，正确配置Secure Boot是解决驱动签名问题的第一步。以下是详细的操作步骤：

1. 关闭虚拟机电源：必须完全关闭虚拟机，不能仅是挂起或休眠
2. 打开虚拟机设置：
   • 右键点击虚拟机 → 选择"设置"
   • 切换到"选项"标签页 → 选择"高级" → 点击"UEFI固件"按钮
3. 禁用Secure Boot：
   • 在出现的UEFI设置界面中，使用方向键导航到"Boot"菜单
   • 找到"Secure Boot"选项，将其设置为"Disabled"
   • 按F10保存设置并退出

常见问题排查：

3. 构建虚拟机专用的签名环境

如果由于安全要求必须保持Secure Boot启用，则需要建立完整的模块签名流程。以下是针对VMware环境优化的步骤：

3.1 准备签名工具链

# 安装必要的软件包 sudo apt update sudo apt install -y mokutil shim-signed build-essential linux-headers-$(uname -r)

3.2 创建签名密钥

在虚拟机环境中，建议将密钥存储在持久化磁盘分区而非临时位置：

# 创建专用密钥目录 sudo mkdir -p /etc/module-signing cd /etc/module-signing # 生成RSA密钥对 sudo openssl req -new -x509 -newkey rsa:2048 \ -keyout MOK.priv -outform DER -out MOK.der \ -nodes -days 36500 -subj "/CN=$(hostname)/" # 设置严格的权限 sudo chmod 600 MOK.priv sudo chmod 644 MOK.der

3.3 处理虚拟机特有的EFI变量问题

当遇到"EFI variables are not supported on this system"错误时，需要检查并调整虚拟机配置：

1. 确认UEFI支持：

   [ -d /sys/firmware/efi ] && echo "UEFI已启用" || echo "UEFI未启用"

2. 调整VMware配置：
   • 编辑虚拟机.vmx文件，添加或修改以下行：

     firmware = "efi" efi.allowOldFirmware = "TRUE"

4. 完整的驱动签名与加载流程

以下是经过VMware环境验证的完整工作流程：

1. 导入公钥到MOK数据库：

   sudo mokutil --import /etc/module-signing/MOK.der

   注意：此处设置的密码将在重启后使用，建议使用简单易记的临时密码

2. 重启并完成密钥注册：

   • 虚拟机重启时，在GRUB菜单中选择"Enroll MOK"
   • 按照屏幕提示完成密钥注册（VMware中可能需要使用鼠标操作）

3. 签名驱动模块：

   sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \ /etc/module-signing/MOK.priv \ /etc/module-signing/MOK.der \ your_module.ko

4. 验证签名：

   modinfo your_module.ko | grep signature

自动化脚本示例：

#!/bin/bash # 保存为sign_module.sh MODULE=$1 SIGN_CMD="/usr/src/linux-headers-$(uname -r)/scripts/sign-file" if [ ! -f "$MODULE" ]; then echo "错误：模块文件不存在" exit 1 fi $SIGN_CMD sha256 /etc/module-signing/MOK.priv \ /etc/module-signing/MOK.der "$MODULE" echo "模块签名完成：$MODULE" modinfo "$MODULE" | grep -i signature

5. 虚拟机环境下的特殊考量

在VMware中处理驱动签名问题时，还需要注意以下特殊场景：

1. 快照与配置保存：

   • 密钥注册状态不会随快照保存
   • 每次恢复快照后可能需要重新注册密钥

2. 跨虚拟机迁移：

   • 导出的OVA/OVF文件不包含MOK数据库
   • 迁移后需要重新执行密钥注册流程

3. 嵌套虚拟化场景：

   • 在启用了嵌套虚拟化的环境中，内层虚拟机可能需要额外配置

性能优化建议：

• 为签名操作分配更多CPU资源
• 将密钥存储在虚拟SSD磁盘上
• 禁用不必要的虚拟机安全功能以提升编译速度

6. 高级技巧与疑难解答

对于需要频繁编译和测试驱动的开发者，以下技巧可以显著提升工作效率：

持久化MOK配置：

# 将MOK自动注册添加到启动脚本 echo 'mokutil --import /etc/module-signing/MOK.der <<< "password"' | \ sudo tee /etc/rc.local

内核升级后的自动化处理：

# 创建内核更新钩子脚本 sudo mkdir -p /etc/kernel/postinst.d sudo tee /etc/kernel/postinst.d/sign_modules <<'EOF' #!/bin/sh version="$1" /usr/src/linux-headers-${version}/scripts/sign-file sha256 \ /etc/module-signing/MOK.priv \ /etc/module-signing/MOK.der \ /path/to/your/module.ko EOF sudo chmod +x /etc/kernel/postinst.d/sign_modules

常见错误解决方案：

• 错误："Required key not available"

  • 原因：内核未使用相同密钥签名
  • 解决：重新编译内核或使用统一密钥

• 错误："Permission denied" on MOK.priv

  • 原因：权限配置不当
  • 解决：sudo chmod 600 /etc/module-signing/MOK.priv

• 错误：VirtualBox兼容性问题

  • 特殊处理：需要额外安装virtualbox-guest-dkms

在实际项目开发中，我发现将签名流程整合到Makefile中可以极大简化工作流程。例如，可以在Makefile中添加如下规则：

sign: @echo "签名内核模块..." $(SIGN_FILE) sha256 $(MOK_PRIV) $(MOK_DER) $(MODULE) @modinfo $(MODULE) | grep signature || echo "签名失败" load: sign sudo insmod $(MODULE)

这种自动化处理方式特别适合需要频繁修改和测试驱动模块的开发场景。