5.0
关注
AI SCORE
技术实践2026-04-22 19:48
Linux 内核采纳 AI 生成的安全报告
Hacker News · lwn.net#Linux#AI安全
Editor brief · 编辑速览
Linux 内核维护者基于 LLM 安全分析启动代码清理，展示了 AI 辅助开源维护的实践，但应用场景相对局限。
Linux 内核维护者基于 LLM 安全分析启动代码清理，展示了 AI 辅助开源维护的实践，但应用场景相对局限。
我们是否应该让"AI"告诉我们该做什么，还是保留人类自由的（作为言论自由的）有趣东西，无论它是否有缺陷。
我更喜欢有缺陷的业余无线电驱动而不是没有驱动
业余无线电真的需要驱动程序吗？
获取更多详情，请参考：https://lwn.net/ml/all/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6d...
安全审计 ISA 卡驱动程序。有什么意义？目标是什么？
这提出了一个问题：为什么要费力去寻找那里的安全 bug？考虑到我们过去几个月一直看到的情况，答案很明显——因为当然你会在那里发现它们！所有软件都有 bug，而使用越少的——被测试越少的——你会找到越多的，更不用说找到并报告它们的实际积极影响。这只是在推高数字。
一旦维护负担超过它提供的好处，移除这样的遗留代码肯定是有意义的，但我们这里谈论的不是这个。
作为补充，如果有人受到这个影响，direwolf 用软件做了业余无线电协议栈以前用硬件 TNC 等做的大量工作，使用你的收音机的声卡接口（你也会用于 FT8 和 JS8CALL 这样的事情）。
虽然这涉及到整个问题：是否存在某个根用户之上的安全边界，这样即使是根用户也不应该能够在内核中触发内存损坏。
你关于自动加载的观点很好——我想这是可能更加严格的东西（而且，在当今系统上，可能根本不值得费力了）。
让我成为根用户来加载驱动程序会有效，但随后你会陷入以前通过协议自动加载或类似东西工作的系统不再工作的困境。这也是一种回归，但会是一种在安全意义上很合理的回归——"你必须是根用户才能破坏你的系统安全"是比"任何能执行任意代码的用户都能破坏系统安全"更合理的立场。
类似地，开箱即用的配置不包括网络服务器，但你可以轻松将其打开。
我认为它还没有被解决，除了禁用自动加载。这往往有效，因为这些模糊的协议通常需要某个支持用户空间包，该包可以在启动时负责加载模块。
对于文件系统，自动挂载由用户空间守护进程（例如 udisks）驱动，他们负责选择将哪个文件系统驱动程序指向可移动设备。
对于其他驱动程序，我仍然不认为值得费力将它们分割这么多。我们对"云"风味做了某种程度的处理，我们知道只应该有很少一组仿真硬件设备，但那里的关注点是优化安装大小。我认为超越那个分割将像试图为"臃肿"应用程序制作"简单"替代品的错误一样：用户只使用 10% 的功能，所以我们可以跳过另外 90%！——但对于每个用户来说并不是相同的 10%。然后我们会面临无尽的支持问题，来自某种方式没有自动安装必要驱动程序的用户。
这让我们仍然有所有那些旧的硬件仿真模型可用于它们一直有用的目的，告诉用户在实践中他们可以信任什么，如果他们确实关心针对恶意客户的安全，并使快速分类大多数"安全问题"的人报告变得更容易，作为"只是一个 bug，去在 bug 跟踪器中提交它"。
我们在考虑将 agents.md 文件添加到树中，说（a）"不要为上游生成代码，看政策文档"和（b）"如果你正在寻找安全问题，看安全政策了解什么确实和不确实算数"。人们不总是阅读我们的文档，但希望他们的机器人无论如何都会：)
还有令人惊讶数量的情况，其中人们必须仿真东西才能让 Windows 这样的操作系统在虚拟机中工作。并非每个操作系统都有 virtio 驱动程序。
只要一个很少使用的无缺陷的用 C 写的驱动程序在树中，合并 Rust 替换的动机可能很低。在该驱动程序中有已知的安全 bug 创造了一个非常强的激励去做点什么，"做点什么"也可以是用 Rust 重写。
这甚至可能是一个很好且受欢迎的项目，用于内核开发新手和/或大学生。范围有限，合并工作的欲望，立即（好吧，相对于通常的内核时间"立即"）成功。唯一的（但相当重大的）缺点是必须有人在真实硬件上测试非仿真驱动程序。尽管如此，听起来可行。
重写并忘记不是一个选项。这些内核新手/大学生将不得不愿意承诺保持驱动程序的维护。
人们可能会争辩说在前一个从句后面加上"用 Rust"实际上会扩大基线，使其足够重要，但我非常怀疑。不是用可能甚至没有 Rust 抽象来基础基础的遗留硬件。
也许有人会花$$$$让 Claude 在 Rust 中重新实现这些东西。在那之前，当代码从内核中移除时，我们都会更好，恕我直言。但是，再次恕我直言，任何使用这东西的用户很可能已经移迁到在用户空间中做它了。
是的，Rust 是一个好语言。是的，Rust 是内存安全的。但 Rust 重写不会神奇地保证安全。Rust 重写不是代码并忘记。
令人沮丧的是这必须一次次地向 Rust 狂热者拼出来。
你通过应用 Rust 重写到模糊的内核模块所做的全部是用另一个技术债替换一个。
Rust 不是万灵药。未维护的代码就是未维护的代码。但完全移除一类 bug 是一个改进。未维护的代码（"代码并忘记"）是技术债，但我宁可要没有内存 bug 的技术债。
也许我提议的实现不太好，但我认为根本问题是一样的：有大量的攻击面安装在所有系统上，其中 99.9% 的系统不需要它。禁用自动加载是一个很好的第一步。
它因未收到更新而被关闭，但也许其中一些得到了解决？
也许现在是时候根据我们关于这些 LLM 的新数据重新审视或调整了？
内核 CVE 洪泛在 AI 狂潮之前开始，很明显在某个时刻内核开发者将不得不重新思考微内核的事情。或者人们无论如何都会通过将驱动程序隔离到虚拟机中来做。
回到 1996 年左右，吸引我的 Linux 内核的事情之一是对这些协议的非常支持，那是 iirc，Alan Cox 添加的。很遗憾看到这些消失。但考虑到这些协议缺乏维护者，也许这是正确的事情。
为 AX.25 倒一杯……
当然这将是发行版而不是上游内核要做的事情，但上游可以通过在 Kconfig 中标记这样的模块/驱动程序为"大多数未维护"来帮助。
我在过去 24 小时内一起拼凑了一个简单的 KISS<-->TUN 适配器，将 Direwolf 的 KISS-over-TCP 服务器连接到 TUN 接口。它似乎作为一个即插即用替换工作。它确实需要在用户空间中实现 ARP（现在仅限 IPv4）。但将 ARP 实现移动到专用 AX.25 实现意味着它（最终）可以被调整得对数据包无线电使用更合适（默认情况下内核 ARP 解析器对 1200 波特来说有点太激进）。
虽然失去它仍然很悲伤，但似乎并不是不可替代的。仍然可能在 Direwolf 和内核 IP 栈之间传输数据包。