Debian从内核5.10版本开始，默认启用了内核模块签名强制验证机制（CONFIG_MODULE_SIG_FORCE），这意味着所有通过DKMS编译的第三方内核模块，如果没有经过有效的数字签名，将无法被加载到内核中。简单来说，如果你在Debian 12（Bookworm）或Debian 13（Trixie）上安装了NVIDIA显卡驱动、VirtualBox扩展、ZFS模块等通过DKMS自动编译的驱动，系统会直接拒绝加载它们，报错"module verification failed: signature and/or required key missing"。解决这个问题有几条路径：要么用MOK（Machine Owner Key）对模块进行签名，要么在启动时临时禁用安全启动，要么修改内核配置关闭强制签名。下面我把每种方案的具体操作、原理和适用场景全部讲清楚。

为什么Debian要强制验证内核模块签名

这不是Debian自己拍脑袋决定的，而是Linux内核社区从5.7版本开始逐步推进的安全策略。核心逻辑是：内核运行在最高权限级别（Ring 0），任何有漏洞的内核模块一旦被加载，就等于给攻击者开了一扇后门。过去，恶意软件可以通过加载未签名的内核模块来绕过所有用户态的安全防护。强制签名验证就是在内核层面建立一道"白名单"——只有持有合法私钥签名的模块才允许运行。

Debian作为最保守、最注重安全的发行版之一，在Bookworm中把CONFIG_MODULE_SIG_FORCE设为"y"，这是一个主动的安全加固选择。对于服务器环境和生产系统来说，这是好事。但对于桌面用户、开发者和需要频繁使用第三方驱动的场景来说，这确实带来了不小的麻烦。

DKMS机制和模块签名之间的冲突本质

DKMS（Dynamic Kernel Module Support）的作用是在内核升级后自动重新编译第三方模块。它的工作流程是：检测到新内核 → 触发编译 → 生成.ko文件 → 加载模块。问题出在最后一步。当CONFIG_MODULE_SIG_FORCE开启时，内核在加载.ko文件之前会检查其ELF段中是否包含有效的数字签名，以及签名是否在信任链中。DKMS编译出来的模块默认是没有签名的，所以直接被拦截。

这里有一个关键细节需要理解：DKMS本身不负责签名，签名是一个独立的步骤。Debian的dkms包也没有内置自动签名功能。所以你需要手动建立一套签名流程，或者接受模块无法加载的现实。

方案一：使用MOK密钥对DKMS模块进行签名（推荐）

这是最正规、最安全的解决方案，也是Debian官方文档推荐的方式。MOK（Machine Owner Key）是UEFI安全启动体系中专门为用户自定义签名设计的密钥对。你用自己的私钥签名模块，然后把公钥导入到UEFI固件的信任数据库中，这样模块就能通过验证。

具体操作步骤如下：

第一步，生成密钥对：

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Module Signing Key/"

第二步，将私钥和证书转换为UEFI可识别的格式：

cert-to-efi-sig-list -g "$(uuidgen)" MOK.der MOK.esl
sign-file -s MOK.priv -c MOK.esl /lib/modules/$(uname -r)/extra/your_module.ko /lib/modules/$(uname -r)/extra/your_module.ko

第三步，导入MOK公钥到系统。Debian提供了mokutil工具：

mokutil --import MOK.der

执行后会提示你设置一个临时密码，重启时在MOK管理器界面输入这个密码完成 enrollment。重启后，你签名的模块就可以正常加载了。

但这里有一个实际痛点：DKMS每次重新编译模块后，你都需要重新签名。因为内核升级触发DKMS重编译，生成的是新的.ko文件，旧的签名失效。你可以写一个DKMS的post-install钩子脚本来自动化这个过程：

# /etc/dkms/framework.conf.d/sign-modules.conf
POST_INSTALL="/usr/local/bin/sign-dkms-module.sh $kernelver $kernel_source_dir"
# /usr/local/bin/sign-dkms-module.sh
#!/bin/bash
KERNEL_VERSION=$1
KERNEL_SOURCE=$2
find /lib/modules/${KERNEL_VERSION} -name "*.ko" -exec sign-file -s /root/MOK.priv -c /root/MOK.esl {} {} \;

这个脚本会在每次DKMS编译完成后自动遍历所有新生成的.ko文件并签名。设置好可执行权限即可。

方案二：在GRUB中临时禁用Secure Boot或模块验证

如果你不想折腾签名流程，或者只是在测试环境中使用，可以通过修改GRUB启动参数来临时绕过验证。编辑GRUB配置文件：

sudo nano /etc/default/grub

找到GRUB_CMDLINE_LINUX_DEFAULT这一行，添加以下参数：

GRUB_CMDLINE_LINUX_DEFAULT="quiet module.sig_enforce=0"

或者如果你想完全关闭安全启动：

GRUB_CMDLINE_LINUX_DEFAULT="quiet secureboot=0"

然后更新GRUB：

sudo update-grub

重启后模块验证就被禁用了。但要注意，这会降低系统整体安全性，生产环境不建议使用。而且Debian 12的新版本内核可能对module.sig_enforce参数做了调整，如果不生效，需要确认内核版本和参数是否匹配。

方案三：重新编译内核关闭CONFIG_MODULE_SIG_FORCE

如果你有完整的内核编译环境，可以从源码重新编译Debian内核，在menuconfig中把"Enforce module signatures"选项关闭。具体路径是：

Enable loadable module support --->
  [ ] Module signature verification
  [ ] Require modules to be validly signed
  [ ] Automatically sign all modules

编译安装后，系统就不再强制验证模块签名。但这个方案的代价是你失去了内核层面的模块安全防护，而且每次内核安全更新你都需要自己重新编译，维护成本很高。一般只在特殊嵌入式场景或完全受控的内网环境中使用。

Debian不同版本的差异和注意事项

Debian 11（Bullseye）默认没有开启CONFIG_MODULE_SIG_FORCE，所以升级到Debian 12后才会突然遇到这个问题。很多用户是在做dist-upgrade之后才发现驱动加载失败的。Debian 13（Trixie）作为测试分支，同样默认开启了强制签名。

另外需要注意，Debian的secureboot包会自动处理MOK enrollment流程，但它只在首次安装时触发。如果你后来才生成MOK密钥，需要手动运行mokutil --import。还有一点，Debian的shim-signed引导加载器会检查内核本身的签名，如果你自己编译的内核没有签名，即使关闭了模块验证，也可能无法启动。这是另一个层面的问题。

实际场景中的常见问题排查

很多用户在执行MOK签名后仍然遇到加载失败，通常有以下几个原因：第一，签名时使用的证书格式不对，必须是X.509 DER格式且包含正确的OID；第二，MOK公钥没有成功enroll，重启时没有进入MOK管理器界面确认；第三，DKMS编译的模块路径和签名脚本中指定的路径不一致，导致签名了错误的文件；第四，某些模块依赖其他模块，需要按顺序签名。

排查时可以用以下命令查看模块的签名状态：

modinfo -F signer your_module.ko
modinfo -F sig_key your_module.ko
modinfo -F sig_hashalgo your_module.ko

如果signer字段为空，说明没有签名。如果有签名但加载仍然失败，检查dmesg日志中的具体错误信息，通常会提示是密钥不在信任链中还是签名本身有问题。

对企业用户和运维的建议

如果你在管理大量Debian服务器，建议建立统一的MOK签名基础设施。用一个内部CA签发模块签名证书，所有服务器共享同一个MOK公钥。这样只需要维护一套密钥体系，而不是每台机器单独生成。同时，把DKMS签名自动化脚本纳入配置管理工具（如Ansible），确保内核升级后模块自动重新签名，避免人工遗漏。

对于桌面用户，如果你只是偶尔需要加载某个驱动，方案二的GRUB参数修改是最快的。但如果你长期使用，强烈建议花时间配置MOK签名，这是一次性投入，长期受益。

总结来说，Debian的内核模块强制签名机制是安全趋势的体现，不是故意为难用户。理解它的原理、掌握MOK签名流程、自动化DKMS签名过程，这三件事做好了，这个机制就不再是障碍，而是你系统安全体系的一部分。与其对抗它，不如把它用好。