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

61–70 of 130 posts

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

#61

Post by bitwize »

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 they're saying is that the capabilities of Mythos to find overlooked vulnerabilities in large code bases are real.

We're in a new era for security. You're either using AI to catch vulnerabilities in your code... or someone else is, and 0wning you.

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

#62

Post by anthk »

ajross wrote: post #50
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…

> 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.

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

#64

Post by rwmj »

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.

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.

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

#65

Post by rwmj »

doubled112 wrote: post #42
cozzyd wrote: post #12

Seems like there should be some "level of maintenance" metric for modules and distros can pick which they include by default and which are packaged separately based on what they care about. Arch users will build the world but an EL user who needs an unmaintained module would have to explicitly install kmod-isdn or even build it themselves

Red Hat already removes a bunch of modules/drivers from the RHEL kernel that they don't consider enterprise. Xbox/PS controllers, for example. I believe some old RAID controller and WiFi drivers are removed too. Whatever they don't want to support.

(Working for Red Hat) We actually opt devices in to our kernel. A couple of years ago an overzealous kernel maintainer removed the watchdog drivers used by qemu from the kernel and it took me ages to get those added back in.

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

#66

Post by socratic_weeb »

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.

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

#67

Post by traceroute66 »

stratos123 wrote: post #20
traceroute66 wrote: post #10

Earlier quoted context omitted.

> well-trained LLMs are more efficient in finding security holes than all but the best developers out there, even for OS kernel code? No. Like everything else an LLM touches, it is prone to slop and hallucinations. You still need someone who knows what they are doing to review (and preferably manually validate) the findings. What all this recent hype carefully glosses over is the volume of false-positives. I guarante…

A 0% false-positive rate is not necessary for LLM-powered security review to be a big deal. It was worthless a few months ago, when the models were terrible at actually finding vulnerabilities and so basically all the reports were confabulated, with a false positive rate of >95%. Nowadays things are much better - see e.g. [1] by a kernel maintainer. Another way to see this is that you mentioned "LLM found this seriou…

> A 0% false-positive rate is not necessary

To be clear, I'm not saying 0% false-positive because that will always be impossible with any LLM.

However, to greatly over-simplify what I already said ...

The presence of >0 false-positives means you still need someone who knows what they are doing behind the keyboard.

The presence of an LLM, no matter how good, will never remove the need for a human with domain expertise in security analysis.

You cannot blindly fix stuff just because the LLM says it needs fixing.

You cannot report stuff just because the LLM says it needs reporting.

There may well be scope for LLM-assisted workflows, but WHO is being assisted is a critical part of the equation.

That is the fundamental point I am making.

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

#68

Post by toast0 »

ferguess_k wrote: post #7

Are we already in the time, or close to the time, that well-trained LLMs are more efficient in finding security holes than all but the best developers out there, even for OS kernel code? Can someone educate me on this?

Efficiency in finding isn't really the metric to consider. I'm sure a good security person could look at these and find the bugs, but nobody did.

IMHO, if you were to do a manual audit of the Linux kernel, the first thing to do is exclude all the stuff you're never going to run, because why spend time on it?

These scans are looking at everything, because once you set it up, the incremental cost to look at everything is not so bad.

This is going to push lesser used stuff out of the mainline, which sucks for people who were using it, but is better for everyone else.

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

#69

Post by brookst »

xbar wrote: post #30
mmsc wrote: post #19

Unmaintained code is a security issue in of itself, so this is of course a net benefit.

This can be accurately generalized: code is a security issue in and of itself.

That’s reductionism, not generalization.

Generalizations that lose accuracy are not valid. “Ice cream is sweet, and candy is sweet, so food is sweet” is reductive.

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

#70

Post by devmor »

traceroute66 wrote: post #39
devmor wrote: post #31

Earlier quoted context omitted.

> Who, for example, still uses ISDN in 2026? Most TV and radio stations.

> 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.

Post reply on HN