Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kernel code removals driven by LLM-created security reports

lwn.net

Post reply on HN
Print view View original

71–80 of 130 posts

Re: Kernel code removals driven by LLM-created security reports

#71

Post by tssva »

socratic_weeb wrote: post #66
sscaryterry wrote: post #47

Here's the thing, all of these problems are pre-existing. All LLMs are doing is shining a big bright light on it.

We are talking about drivers for devices from the last century which nobody even uses anymore. This isn't "shining light" on important pre-existing issues that have been ignored for too long or something, it isn't helping. The only problem here, if any, is the false sense of confidence given by LLMs to people who have no business touching kernel code.

If they are drivers for devices from the last century which nobody even uses anymore why keep them in the kernel when they, as shown by LLMs, are potential sources of security vulnerabilities? Seems more logical to take the action being taken and remove them.

Re: Kernel code removals driven by LLM-created security reports

#72

Post by the_biot »

Create wrote: post #52

When LLM reports the bug, is should be used to fix it on the same occasion. Nobody will bother afterwards.

That's literally advocating for filling the kernel with AI slop.

Not that it's not going to happen; Linus is already a vibe-coder, and several maintainers have fallen for the LLM crap as well.

Re: Kernel code removals driven by LLM-created security reports

#73

Post by [deleted] »

anthk wrote: post #62
ajross wrote: post #50

Earlier quoted context omitted.

> more modern protocols (in userspace) That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve. The future, and we basically all agree, puts complexities like protocol handling a…

Except it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.

[deleted]

Re: Kernel code removals driven by LLM-created security reports

#74

Post by terryot »

drewg123 wrote: post #45
NooneAtAll3 wrote: post #38

can such drivers be moved out of kernel? what exactly stops that? why do they even need to be in kernel repo and not brought at/after install time?

Linux is actively hostile to out-of-tree drivers. There is no stable driver API, and interfaces change at the drop of a hat. Maintaining an out of tree driver is a constant nightmare where you're always dealing with interfaces changing out from under you. I wrote and maintained 10GbE drivers for a small company in the 2000s, and just the SHIM file for our driver on Linux to massage over API differences was well over…

A counterpoint: I recently asked Claude to port an obsolete ~2010 driver to latest kernel by asking Claude to "make it work". Few builds later and few crashes later, I had a working driver, with DMA, modern Io map protection, etc.

It's not a nightmare anymore to port drivers

Re: Kernel code removals driven by LLM-created security reports

#75

Post by varispeed »

s20n wrote: post #43

While I know that it may have been a security liability, I'm particularly sad that they're removing the AX.25 module from the kernel. > and since nobody stepped up to help us deal with the influx of the AI-generated bug reports we need to move it out of tree to protect our sanity. This thread from the linux-hams mailing list [2] has more insight into this decision. I guess the silver lining is that, more modern proto…

Oh remember playing with that protocol ages ago. Sad.

Re: Kernel code removals driven by LLM-created security reports

#76

Post by varispeed »

anthk wrote: post #62
ajross wrote: post #50

Earlier quoted context omitted.

> more modern protocols (in userspace) That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve. The future, and we basically all agree, puts complexities like protocol handling a…

Except it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.

But hardware manufacturers love it! Excuse to sell new faster machines.

Re: Kernel code removals driven by LLM-created security reports

#77

Post by convolvatron »

anthk wrote: post #62
ajross wrote: post #50

Earlier quoted context omitted.

> more modern protocols (in userspace) That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve. The future, and we basically all agree, puts complexities like protocol handling a…

Except it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.

that's strictly not true. if I move the code that does TCP from the kernel into the application (not some other daemon, which is perhaps what you're suggesting), then the performance is to the first order the same.

ok, what are the niggly details. we don't have interrupts, and we're running under the general scheduler, so there may be some effects from not getting scheduled as aggressively.

we still need to coordinate through the kernel wrt port bindings, since those are global across the machine, but that's just a tiny bit.

clearly we may be re-opening a door to syn-flooding, since the path to rejection is maybe longer. maybe not, but maybe we can leave the 3-way handshake in the kernel and put the datapath in userspace.

we probably lose rtt-estimates hanging off of routes.

none of that suggests 'several times slower'

Re: Kernel code removals driven by LLM-created security reports

#78

Post by dymk »

warkdarrior wrote: post #56
dymk wrote: post #25

Earlier quoted context omitted.

https://blog.mozilla.org/en/privacy-security/ai-security-zer... > As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week’s release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation.

So you're saying Mozilla is in on it, hyping up Anthropic. Are they getting a kickback?

What I’m saying is the youths call this “smoking copium”

Re: Kernel code removals driven by LLM-created security reports

#79

Post by gpm »

Create wrote: post #52

When LLM reports the bug, is should be used to fix it on the same occasion. Nobody will bother afterwards.

Performing the charity work of discovering bugs before someone evil uses them to cause damage does not somehow obligate you to perform more charity and fix those bugs.

Re: Kernel code removals driven by LLM-created security reports

#80

Post by skydhash »

tssva wrote: post #71
socratic_weeb wrote: post #66

Earlier quoted context omitted.

We are talking about drivers for devices from the last century which nobody even uses anymore. This isn't "shining light" on important pre-existing issues that have been ignored for too long or something, it isn't helping. The only problem here, if any, is the false sense of confidence given by LLMs to people who have no business touching kernel code.

If they are drivers for devices from the last century which nobody even uses anymore why keep them in the kernel when they, as shown by LLMs, are potential sources of security vulnerabilities? Seems more logical to take the action being taken and remove them.

I like OpenBSD for that. If there's something that no one uses and wants to maintain, it's removed. That happened with the bluetooth driver. It was too complicated and no one missed it enough to add it back.
Post reply on HN