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

91–100 of 130 posts

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

#91

Post by pixl97 »

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.

"Get Pwn3d server times faster!"

Seemingly we've been writing kernels for years, and they still are full of security holes.

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

#92

Post by traceroute66 »

devmor wrote: post #70
traceroute66 wrote: post #39

Earlier quoted context omitted.

> Most TV and radio stations. I doubt it. And as I said, telcos have ceased new sales of ISDN and will be shutting down copper networks within 3–5 years. Therefore if there are still TV and radio stations still using it, they will be forced to stop using it by circumstance, i.e. they will find their ISDN will cease working after the telco shuts down the kit in the exchange.

You can doubt it all you want, ISDN is used internally in broadcast all over the world. Telcos shutting it down has nothing to do with them and won’t affect them. Losing support in software however, does.

>You can doubt it all you want, ISDN is used internally in broadcast all over the world

Since you claim to be a domain expert, give me hard named examples with independently verifiable links. At this stage I want facts, not anecdotes.

Because right now, my semi-educated guess is they are all using IP-based streaming codecs and protocols for remote contributions, outside broadcast, studio links and pretty much everything else under the sun.

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

#93

Post by robocat »

chuckadams wrote: post #17
stratos123 wrote: post #11

Earlier quoted context omitted.

In terms of quantity, definitely yes (a single person managing a swarm of Opusi can already find much more real bugs than a security researcher, hence the rise in reports). In terms of quality ("are there bugs that professional humans can't see at any budget but LLMs can?") - it's not very clear, because Opus is still worse than a human specialist, but Mythos might be comparable. We'll just have to wait and see what…

> Opusi The plural of "Opus" is "Opera". Might be a tad confusing tho :)

Opuses is also correct English, and clearer in non-academic contexts.

Opera is the traditional plural from Latin, now perhaps for more scholarly use in English.

Results from a quick search.

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

#94

Post by chuckadams »

robocat wrote: post #93
chuckadams wrote: post #17

Earlier quoted context omitted.

> Opusi The plural of "Opus" is "Opera". Might be a tad confusing tho :)

Opuses is also correct English, and clearer in non-academic contexts. Opera is the traditional plural from Latin, now perhaps for more scholarly use in English. Results from a quick search.

I'll do the faux German thing then: Opusen :)

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

#95

Post by segmondy »

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.

what do you mean nobody? there are a few of us using it, and we are completely broken when support is taken away.

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

#97

Post by ahepp »

achierius wrote: post #83
drewg123 wrote: post #45

Earlier quoted context omitted.

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…

GP meant moving the driver into userspace, which is much less painful due to the stable userspace APIs.

I’m not sure the GP did mean that, but I agree it’s a much better solution than maintaining an out-of-tree kernel module, which is generally a really bad idea

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

#98

Post by random__duck »

Legend2440 wrote: post #26
jcalvinowens wrote: post #18

Earlier quoted context omitted.

My experience with these tools is that they generate absolutely enormous amounts of insidiously wrong false positives, and it actually takes a decent amount of skill to work through the 99% which is garbage with any velocity. Of course some people don't do that, and send all the reports anyway... and then scream from the hilltops about how incredible LLMs are when by sheer luck one happens to be right. Not only is th…

This is incorrect. Here's the curl maintainer talking about dozens of bugs found using LLMs: https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyz...

You mean the same curl that have been crying from the hilltops that they are being DDOSed with slop security reports? That curl?

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

#99

Post by duskwuff »

rwmj wrote: post #64
anthk wrote: post #62

Earlier quoted context omitted.

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

I don't think this is actually true (eg. DPDK), but even if it is, you can put the driver in userspace (tun/tap + vfio/libusb/ioport/...) and still use TCP/IP in the kernel.

Speed certainly certainly isn't an issue for AX.25. The protocol typically runs at <10 kbps; the overhead of processing packets in userspace is negligible.

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

#100

Post by notepad0x90 »

segmondy wrote: post #96

Seems there should be a "hobbyist kernel" with all that kernel code, you run at your own risk but get all the toys for your obscure use cases.

There really shouldn't, people don't have to include things in their kernel builds they don't need.
Post reply on HN