很多Ubuntu用户在开启SecureBoot的UEFI电脑上安装系统时，会遇到“无法安装这个第三方软件包”或“安全启动阻止了未签名的驱动加载”这类错误。核心问题是Ubuntu的安装内核和某些硬件驱动（如NVIDIA、VirtualBox或无线网卡驱动）必须经过微软的UEFI安全启动密钥签名才能被系统固件信任并加载。解决方法很直接：要么在UEFI设置中临时禁用SecureBoot，完成安装并配置系统后，再通过安装签名的内核和驱动来重新启用它；要么在安装过程中，手动导入Ubuntu的MOK（机器所有者密钥）到固件中，以允许系统加载自签名的内核模块。
SecureBoot与UEFI固件验证究竟是什么？
SecureBoot是现代UEFI（统一可扩展固件接口）固件的一项安全功能。你可以把它想象成固件层面的一道“安检门”。当电脑启动时，UEFI固件会检查每个要加载的软件组件（如引导加载程序、操作系统内核、关键驱动）的数字签名。这些签名必须由受固件信任的证书颁发机构（默认通常是微软的UEFI CA）签发，才能通过验证并执行。其根本目的是防止恶意软件（如rootkit）在操作系统启动前被加载，从而保护启动链的安全。Ubuntu作为一个主流Linux发行版，其官方内核和引导加载程序（如GRUB）已经获得了微软的签名，因此可以在开启SecureBoot的电脑上正常启动基础系统。矛盾点在于用户后续安装的许多第三方内核模块（DKMS驱动）并没有这个“通行证”。
Ubuntu安装过程中如何处理SecureBoot？
当你使用Ubuntu官方ISO安装系统时，安装程序会检测SecureBoot状态。如果它处于开启状态，安装程序会采取一个关键步骤：它会将名为“shim”的经过微软签名的引导加载程序安装到EFI系统分区。Shim是一个小巧的“二级信任代理”，它本身由微软签名，固件信任它；而它的任务是去验证并加载由Ubuntu Canonical公司密钥签名的GRUB和内核。对于安装阶段必须加载的第三方驱动（例如某些无线网卡固件），Ubuntu安装程序可能会提示你创建一个MOK。你需要设置一个密码，并在首次重启后，在UEFI固件界面出现的蓝色MOK管理界面（MokManager）中，根据提示选择“Enroll MOK”并输入密码，将密钥加入固件信任列表。完成这一步，这些驱动才能被加载，安装才能继续。
安装后配置：在启用SecureBoot下使用第三方驱动
系统安装完成后，若你需要使用未签名的驱动（最典型的是NVIDIA私有驱动），就必须进行手动签名操作。这是一个标准流程：首先，你需要生成自己的密钥对；然后，用私钥为你编译的内核模块签名；最后，将公钥注册到UEFI固件和系统中。以下是具体命令示例：
# 1. 创建密钥对（需要安装mokutil和openssl） openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Personal MOK/" # 2. 将公钥导入系统，并设置下次启动时注册 sudo mokutil --import MOK.der # 执行后会提示设置一个一次性密码。 # 3. 重启电脑。在启动过程中，UEFI界面会弹出MokManager蓝屏。选择"Enroll MOK" -> "Continue" -> 输入上一步设置的密码，完成密钥注册。 # 4. 为已安装的特定内核模块签名（以NVIDIA驱动为例） sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n nvidia) # 每次内核更新或驱动重编译后，都需要重新执行此签名命令。 # 5. 配置系统，让后续新编译的模块自动签名 # 将私钥和公钥放到安全目录，并在/etc/dkms/signature.sh中配置自动签名脚本。
完成这些步骤后，你的自定义驱动就能在SecureBoot开启的环境下无缝工作了。对于通过DKMS管理的驱动（如VirtualBox），可以配置DKMS自动调用签名脚本。
深入分析：Ubuntu与SecureBoot的协作与权衡
从技术生态角度看，Ubuntu对SecureBoot的支持是一种务实的妥协与合作。Canonical与微软合作，为其核心组件获取商业签名，这确保了Ubuntu在绝大多数预装Windows的PC上能够“开箱即用”，极大地降低了用户门槛，是Linux桌面普及的重要一环。然而，这种依赖也带来了中心化风险，并将部分控制权让渡给了微软的证书策略。从安全视角看，SecureBoot确实增强了物理接触场景下的启动安全，但它主要防御的是启动阶段的恶意代码，对于操作系统运行后的威胁无能为力。对于高级用户和安全研究人员，完全自签名的方案（即不依赖微软，只用自己生成的平台密钥PK、KEK和db）虽然更自主，但过程复杂且通用性差。因此，Ubuntu当前采用的“Shim+MOK”模式，在用户便利性、系统安全性和自主权之间取得了较好的平衡。
故障排除与常见问题解决
如果你在SecureBoot环境下遇到问题，可以按以下步骤排查：首先，使用mokutil --sb-state命令确认SecureBoot确实已启用。其次，使用dmesg | grep -i secure或journalctl -k | grep -i signature查看内核日志中关于签名验证失败的详细错误。一个常见的问题是内核升级后，之前签名的驱动失效。此时需要重新为新版内核下的驱动模块签名。另一个棘手情况是某些笔记本的UEFI固件实现有缺陷，可能导致MOK管理界面无法弹出。这时可以尝试在固件设置中彻底重置安全启动密钥为出厂默认值，或者暂时禁用SecureBoot以完成MOK注册流程。对于必须使用闭源驱动但又不想处理签名的用户，最直接的方案是使用Ubuntu官方仓库中已预签名的“hardware enablement”内核和受限驱动包，但这可能不是最新版本。
最佳实践与安全建议
对于大多数Ubuntu用户，我们建议保持SecureBoot开启以获取基础层面的安全保护。管理密钥和签名的最佳实践是：
(1)将生成的MOK.priv和MOK.der密钥对进行加密备份，并妥善保管密码；
(2)定期检查已注册的密钥列表（使用mokutil --list-enrolled），移除不再使用的密钥；
(3)优先使用Ubuntu官方仓库中经过审核和签名的驱动版本；
(4)在物理安全风险较低的个人设备上，如果驱动兼容性问题无法解决，将禁用SecureBoot作为最后手段，并意识到这会略微降低启动安全性。企业部署则应考虑使用统一的平台密钥和镜像签名策略，以实现集中化管理。
总而言之，理解并妥善配置SecureBoot是在现代硬件上流畅使用Ubuntu的关键技能。它不再是一个无法逾越的障碍，而是一个可以通过标准工具链进行管理的安全特性。通过上述的步骤和深入理解，你不仅能解决安装和驱动问题，还能更主动地掌控自己系统的启动安全。
