由LLM生成的安全报告驱动的内核代码移除
Kernel code removals driven by LLM-created security reports

原始链接: https://lwn.net/Articles/1068928/

本次讨论围绕最近一次内核代码移除展开,起因是错误报告数量增加——其中许多由LLM生成——以及维护遗留代码的更广泛问题。一个关键的争论点是,LLM生成的报告是*导致*代码移除的原因,还是仅仅凸显了现有问题。 多位评论员认为,核心问题是内核由于其庞大而存在未维护的代码,这些代码如果作为独立实体存在会更清晰可见。有人担心用户停留在较旧的内核上,以及在非常旧的硬件上运行现代系统的可行性。 一次具体的移除——对某些业余无线电驱动程序的支持——受到了批评,一些人认为这并不能提高安全性,反而会影响爱好者。一个反复出现的主题是,如果LLM标记了错误,也应该提出修复方案。另一些人则反驳说,仅仅识别一个错误就有价值,无论是否有补丁,而忽略报告是有害的。 最后,对话涉及潜在的解决方案,例如用Rust重写代码,以减轻安全风险,即使维护有限。

黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 LLM生成的安全报告驱动的内核代码移除 (lwn.net) 11 分,edward 1小时前 | 隐藏 | 过去 | 收藏 | 1 评论 帮助 staticassertion 5分钟前 [–] 他们无法维护代码,所以不再维护代码。回复 考虑申请YC 2026年夏季项目!申请截止至5月4日 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系 搜索:
相关文章

原文
to post comments

Slightly Ambiguous Title

The title sort of reads like the LLM-created security reports _helped_ remove the kernel code, whereas it's the problem of increasing number of LLM-created security reports which drove the kernel code being removed.

Slightly Ambiguous Title

No, the problem is all the unmaintained code in large projects like the kernel which has been pretending to be maintained by being part of some large project instead of being a separate project where the unmaintained status would have been visible years ago.

Slightly Ambiguous Title

Slightly Ambiguous Title

"Leaving people to be stuck on old kernels isn't great."

Can newer kernels boot on hardware that still has PCMCIA Ethernet cards? I mean software (including the Linux kernel) tend to require more and more resources over time and I'm not sure that a laptop from 1998 is able to run a Linux 7.0-based system anyway... Might as well stick to a kernel from that age and if security is required (who will want to pown that machine?), one can always put a firewall in front of it...

Slightly Ambiguous Title

I prefer bogus Amateur Radio than no driver

I prefer bogus Amateur Radio than no driver

This is less AI telling us what to do, and more AI pwning systems. Rather different thing.

Does Amateur Radio really need drivers?

I prefer bogus Amateur Radio than no driver

If you're willing to maintain all of those drivers and fix the bugs then I'm sure they can be kept in-tree. But just because they are functional doesn't mean they're secure. Finding security issues and reporting them isn't some AI conspiracy. But no matter in what subsystem issues are found they need to be fixed. If there is no maintainer willing to do so, then (especially when there are viable user-space solutions) the safest bet is to remove such drivers.

If they generate bug reports, they must also generate fixes

I would demand that LLMs used to generate bug reports MUST also generate patches to fix those, on pain of being ignored.

If they generate bug reports, they must also generate fixes

The bug exists independent of whether a patch is provided or not. This is brutally unfair on all the humans involved in developing the codebase and also ignoring the report is unfair on all the humans whose privacy and security depend on the codebase.

If they generate bug reports, they must also generate fixes

Removing support for HAM radio will not increase the security of anyone.

If they generate bug reports, they must also generate fixes

If they generate bug reports, they must also generate fixes

We will increase the security of HAM radio operators by removing their ability to operate their HAM radio.

If they generate bug reports, they must also generate fixes

You're not removing the ability to operate a ham radio - this doesn't remove CAT (serial port) or soundcard support, nor does it prevent userspace applications like direwolf, WSJT-X, nor are you preventing AGWPE (the current state of the art for AX.25 applications) from being used.

If they generate bug reports, they must also generate fixes

Security audits for ISA card drivers. What's the point? What's the goal here?

Security audits for ISA card drivers. What's the point? What's the goal here?

Actually I would expect the effort focused on security to depend on how easy it is for others to inject data that is then processed by that code so actually something handling data from a radio antenna where literally anyone could send data should be more hardened than most other code.

Security audits for ISA card drivers. What's the point? What's the goal here?

The radio antenna is less of a concern - more of a concern is that if I can load the modules on a system without ham radio gear installed (e.g. via protocol module autoloading), I can exploit bugs in them that allow me to get privileged access I should not have.

As an aside, if someone's affected by this, direwolf does a lot of what the ham radio stack used to do with hardware TNCs and the like in software, using your radio's soundcard interface (the one you'd also use for things like FT8 and JS8CALL).

Security audits for ISA card drivers. What's the point? What's the goal here?

Security audits for ISA card drivers. What's the point? What's the goal here?

Rewrite-in-Rust projects

Rewrite-in-Rust projects

Rewrite-in-Rust projects

The idea is that even if the code stays unmaintained, no matter how horribly buggy it is, if implemented in safe Rust it won't be able to cause memory corruption in the wider kernel. (At most an attacker would be able to interfere with the functioning of that device, which I guess could be considered a security issue if you have an NFS filesystem mounted over your PCMCIA Ethernet link or ham radio.)

联系我们 contact @ memedata.com