LWN：基于哈希对module进行完整性检查！

关注了就能看到更多这么棒的文章哦～

Hash-based module integrity checking

By Daroc Alden
March 7, 2025
Gemini-1.5-flash translation
https://lwn.net/Articles/1012946/

2024 年 1 月 20 日，Thomas Weißschuh 分享了一个新的 补丁集 (patch set)，实现了一种用于检查可加载内核模块 (loadable kernel module) 完整性的新的方法。这种机制基于构建时计算的哈希值来检查模块的完整性，而不是使用加密签名，从而可以在更多情况下实现可重现的内核构建 (reproducible kernel builds)。如果 Weißschuh 能够将其合入 内核，一些发行版已经表示对该补丁集感兴趣。

自 2012 年 David Howells 引入第一个相关代码以来，Linux 就支持对可加载内核模块进行签名。从那时起，该实现没有发生太大的变化。用户可以启用 CONFIG_MODULE_SIG 选项来开启模块签名；默认情况下，如果加载未签名的模块，这只会污染 (taint) 内核。启用 CONFIG_MODULE_SIG_FORCE 或 Lockdown Linux Security Module (LSM) 会阻止内核加载未签名的模块。验证签名所需的公钥在构建时被嵌入到内核中。构建过程可以配置为使用现有的密钥对，或者自动生成所需的非对称密钥。

这种自动生成密钥的方式是 Weißschuh 对当前代码不满的地方。可重现构建对于安全性非常重要，因为它们允许独立验证一个开源项目在编译时是否插入了额外的、恶意的修改。对于像 Linux 内核这样基础的东西，如果能够验证内核的构建未被修改，那就太好了。但是，当构建需要签名密钥时，如果不分发密钥，就无法实现可重现构建。目前，这让用户陷入两难的境地。他们不能同时启用可加载模块、可重现构建和签名验证。

寻找巧妙的加密解决方案是很诱人的，但目前还没有人提出这样的方案。如果签名密钥是公开可用的，可以用于重新创建构建，那么恶意行为者也可以使用它们来签名修改后的可加载模块。如果签名密钥不是公开可用的，那么构建就无法重现。因此，Weißschuh 的补丁集采用了一种更简单的方法：该补丁集没有尝试为可加载模块创建签名，而是计算所有与内核一起构建的模块的加密哈希值，并将这些哈希值嵌入为一个静态列表，以便在加载前验证潜在的模块。

这样做的好处是简单 —— 如果一个模块的哈希值与构建时的哈希值相同，那么它肯定没有被篡改 —— 但它不如基于签名的方法灵活。具体来说，Weißschuh 的补丁集只适用于与内核同时构建的模块。默认构建配置为每次构建生成新的密钥，也存在同样的限制，但用户可以选择使用他们自己的长期签名密钥。树外模块 (out-of-tree modules)、动态内核模块支持 (Dynamic Kernel Module Support, DKMS) 模块等无法将其哈希值包含在内核中，因此无法通过哈希值进行验证。

没有什么可以阻止用户同时启用 Weißschuh 的新代码 (使用 CONFIG_MODULE_HASHES) 和现有的签名验证支持，尽管在这种情况下，生成的内核是不可重现的。这将构建所有带有哈希值（但没有签名）的树内模块，并且仍然允许加载已签名（但没有哈希值）的树外模块。Arch Linux 贡献者 "kpcyrd" 总结了可能的选项。

组合模块哈希和模块签名的设置会产生四种可能性。当 CONFIG_MODULE_HASHES 和 CONFIG_MODULE_SIG 都没有启用时，内核不执行任何检查（因此 Lockdown 会拒绝加载任何模块）。当只启用 CONFIG_MODULE_SIG 时，行为与今天相同 —— 可以加载已签名的模块。当启用 CONFIG_MODULE_HASHES 时，可以加载具有已知哈希值的模块。当两者都启用时，可以加载具有已知哈希值或有效签名的模块。如果启用了 CONFIG_MODULE_SIG_FORCE=, =CONFIG_MODULE_SIG 必须同时启用。如果 CONFIG_MODULE_SIG_FORCE 和 Lockdown LSM 都没有启用，内核不会禁止没有有效签名或哈希值的模块，因此配置签名或哈希模块的意义不大。

对于 Arch Linux、Proxmox 和 SUSE 的用户 —— Weißschuh 表示基于 之前的讨论，这些项目对此项工作感兴趣 —— 最后一种选择是正常内核构建最可能的配置。NixOS 默认不启用模块签名，并且更有可能只启用 =CONFIG_MODULE_HASHES=, 但仍然很感兴趣。然而，该补丁集尚未完全准备好进入主线内核 (mainline, 也称主线)。Petr Pavlu 建议 Weißschuh 进行一些调整。还有一些人参与了对该补丁集的讨论，但鉴于不同发行版表现出的明显兴趣，并没有太多人反对该补丁集。一旦他修改了该补丁集，它似乎可能会消除部署可重现内核构建的为数不多的剩余障碍之一。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～