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

81–90 of 130 posts

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

#81

Post by badsectoracula »

tristor wrote: post #44

Realistically, that list of components are mostly things that have not been used in modern computing devices for over a decade. Nothing prevents someone from providing a module from out of the kernel tree to ship these drivers or delivering some of these capabilities in user space, and if they are unused and unmaintained I would rather they're not shipped in the kernel. Be real with yourself, do you know anyone using…

> They should be separated kernel modules in their own tree.

The main issue with this is that by being on a separate tree they do not benefit from the API breakage updates in the kernel. After all the main benefit that kernel devs mentioned over the years for keeping drivers in the kernel instead of separate trees is that the code gets updated whenever internal APIs change.

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

#82

Post by dezgeg »

devmor wrote: post #31
traceroute66 wrote: post #5

Earlier quoted context omitted.

> They can't maintain the code so they are no longer going to maintain the code. Yes, I don't see the point of maintaining technical debt just for the sake of it. The security environment in 2026 is such that legacy unmaintained code is a very real security risk for obscure zero-days to exploit to gain a foot in the door. Reading through the list I don't see it being an issue for the overwhelming majority of Linux us…

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

Do they use it via mainline Linux kernel's ISNDN drivers though (and not something proprietary)?

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

#83

Post by achierius »

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…

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

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

#84

Post by pocksuppet »

dymk wrote: post #78
warkdarrior wrote: post #56

Earlier quoted context omitted.

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”

Both can be true at once. It can be good at finding vulnerabilities, and also overhyped to pump the stock price.

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

#85

Post by brookst »

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.

You don’t see any issue with insecure drivers for obsolete hardware, exactly the kind of thing that is most prevalent in an industrial control type applications?

Stuxnet should have been a wakeup call to everyone: the boring, obsolete, “safe because nobody browses TikTok on it” hardware is exactly the highest risk.

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

#87

Post by cestith »

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 you only need 100 Mbps the 3Com 3c905 series of PCI Ethernet cards are still some of the most reliable hardware you can put into your industrial PC that still has PCI slots. ISDN and ax25 are still really useful if you have low-bandwidth but low-latency needs like sensor data.

Now those are niche use cases, but they do exist. However, what’s wrong with removing insecure code for these niche cases? Either someone will step up to actually maintain it, or newer versions of the kernel will be leaner and have less historical cruft.

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

#88

Post by SleepyMyroslav »

dymk wrote: post #25
pocksuppet wrote: post #22

Earlier quoted context omitted.

The reason Mythos isn't being released publicly is to drive up Anthropic's valuation by making big promises.

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.

I understand that they are trying to say that it is getting better... 271 vulnerabilities is a lot. I have been using FF for a long time. I am now considering if using it at all was a mistake or not. And I think it was.

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

#89

Post by cyanydeez »

KJs6ZxELzQM37O wrote: post #33

A lot of money seems to be placed to find bugs in open source projects right now... maybe they can spend just a little bit of this money on people to fix these bugs

You're arguing to pay your taxes instead of spending money on buying politicians.

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

#90

Post by jwitthuhn »

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 the LLMs run by these people are turning up real bugs then their confidence in touching kernel code seems pretty earned, imo.
Post reply on HN