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

101–110 of 130 posts

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

#101

Post by notepad0x90 »

I think "won't fix" should be normalized, even for critical security bugs.

Software exists to be used, not to be secure. These are not useless pieces of code. If they were useless, then no one is using them, so there is no security risk. This is equivalent to turning off (or destroying) a computer to secure it.

Alternatively (and I'm disappointed Linux/Greg K.H. haven't done this), drivers and other isolated modular code should be marked as unmaintained, and for those with reported vulnerabilities, a similar config flag set. Require explicit acknowledgement by kernel builders to include them in the build config.

Things have been trending badly with Linux in this area, it feels like it's lost it's original calling, and is now heavily influenced by PR and corporate interests. The desktop Linus used in the 90's to write Linux should be able to run the current Linux kernel. But it doesn't even support the CPU architecture any more!

Some of us have perfectly good old hardware we can put to modern (non-networked) use, but we have to either use netbsd (if it supports the task/program), or generate more e-waste and dump the hardware in the bin. And buy yet another RPI, and waste money and resources. But at least, so long as it is simple use cases that don't require modern software, you can just slap an old version of Linux on it, but at least in my experience, stability was more of an issue for older drivers than it is today, so Windows 98 or XP is a better choice sometimes for x86.

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

#102

Post by mike_hearn »

traceroute66 wrote: post #92
devmor wrote: post #70

Earlier quoted context omitted.

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 everyth…

No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. It's a huge pita for him because the telcos don't want to know indeed, but it's the usual story with legacy workflows.

I think it's also a fully switched system so you are guaranteed bandwidth with no packet drops or buffering which is clearly useful for broadcast work.

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

#103

Post by anthk »

pixl97 wrote: post #91
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.

"Get Pwn3d server times faster!" Seemingly we've been writing kernels for years, and they still are full of security holes.

p0wned from where? Where's the vector attack?

Do you realize AX25 it's just something loaded on demand when the user requires it, and not by default? Do you know the basics on how the systems work bellow your shiny UI's and IDE's?

First, AX25 modules would just lie down in the disk harmless, no AX25 stuff it's loaded unless some user modprobe thems in order to setup some hamradio stack with HamNet and the like.

I see far more security issues with blobs loaded in a so-called GPLv2 kernel everywhere where the tarball almost weights more in blobs than in libre source code. Yet these LLM bootlickers will happily accept whichever non-free firmware on their noses.

Somehow propietary Radeon, Nvidia, some Intel audio drivers for SOCs and the tons of ARM related firmware blobs are not a security issue. At all. Just kick random bits over the BUS without knowing what really happens with the device. Even if some of them can have full access to the RAM and CPU and the like. That's pretty fine. Ah, yes, IOMMU's and the like. Not enough for some cases. Sorry, but these people can't be serious where the actual multi-CPU based networked computer it's full of opaque bits where you have no control on what they do at all.

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

#104

Post by anthk »

varispeed wrote: post #76
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.

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

Also releasing the so-called GPLv2 kernel full of propietary blobs where GPU's and even SOC's can take over the whole initialization process (and some devices talk to the CPU directly since DMA times, and I don't think IOMMU's will be 100% safe for this) it's perfecly fine for security.

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

#105

Post by anthk »

traceroute66 wrote: post #92
devmor wrote: post #70

Earlier quoted context omitted.

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 everyth…

Telecos still use tons of legacy code and even encapsulate internet connections over Media standards.

If you have that nickname you would already know that, for sure.

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

#106

Post by traceroute66 »

mike_hearn wrote: post #102
traceroute66 wrote: post #92

Earlier quoted context omitted.

>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 everyth…

No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. It's a huge pita for him because the telcos don't want to know indeed, but it's the usual story with legacy workflows. I think it's also a fully switched system so you are guaranteed bandwidth with no packet drops or buffering which is clearly useful for broadcast work.

> No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link.

But how much is this to do with either Channel 4 not supporting (in the "assistance" sense of the word, rather than "interop") his move to IP or potentially his personal reluctance to change ("ain't broke don't fix it" mindset).

Given he is in the UK and the incumbent telco (BT) are switching off ISDN in 2027, I really suspect there is more than meets the eye to your friend's story.

I am not seeking to judge, I just feel realistically that it highly unlikely that at this late stage (1 year to go to 2027) there really is no other option other than ISDN when collaborating with Channel 4...

The reason I say this is because even the briefest of internet search throws up hard publicly-available evidence that the broadcast world have indeed moved on in the world ....

Way back in 2008 the BBC were already investigating options to move away from ISDN...[1]

... and evidence is out there the BBC are using SIP for critical things like remote Radio contributions[2]

> guaranteed bandwidth with no packet drops or buffering

You can absolutely get this on IP.

[1] https://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP170... [2] https://support.inquality.com/kb/faq.php?id=144

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

#107

Post by sylware »

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…

kernel/user space context switching, in high performance context has to be seriously evaluated.

And this is very dependent on the hardware programming interface of the devices.

Look at AMD who is investigating hardware user-level queues for their GPUs (dunno if this is possible because of VMID stuff)

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

#108

Post by subscribed »

varispeed wrote: post #76
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.

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

With the current lead times and the prices of the fast, complicated silicone? I don't think so :)

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

#109

Post by mike_hearn »

traceroute66 wrote: post #106
mike_hearn wrote: post #102

Earlier quoted context omitted.

No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. It's a huge pita for him because the telcos don't want to know indeed, but it's the usual story with legacy workflows. I think it's also a fully switched system so you are guaranteed bandwidth with no packet drops or buffering which is clearly useful for broadcast work.

> No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. But how much is this to do with either Channel 4 not supporting (in the "assistance" sense of the word, rather than "interop") his move to IP or potentially his personal reluctance to change ("ain't broke don't fix it" mindset). Given he is in the UK and the incumbent…

I assume they have a migration plan or already migrated. I don't know, he told me this years ago. It wasn't his choice it is/was just the standard in the industry. I'm sure they're moving to IP at the moment, I was just pushing back on the idea that broadcast doesn't use it. If they've moved away from it, it's a relatively recent change (last five years or so).

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

#110

Post by traceroute66 »

mike_hearn wrote: post #109
traceroute66 wrote: post #106

Earlier quoted context omitted.

> No, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. But how much is this to do with either Channel 4 not supporting (in the "assistance" sense of the word, rather than "interop") his move to IP or potentially his personal reluctance to change ("ain't broke don't fix it" mindset). Given he is in the UK and the incumbent…

I assume they have a migration plan or already migrated. I don't know, he told me this years ago. It wasn't his choice it is/was just the standard in the industry. I'm sure they're moving to IP at the moment, I was just pushing back on the idea that broadcast doesn't use it. If they've moved away from it, it's a relatively recent change (last five years or so).

> If they've moved away from it, it's a relatively recent change (last five years or so).

So the TL;DR is we are not disagreeing then ? ;)

I never expressed any doubt that traditionally ISDN absolutely was the lifeblood of broadcast, there is zero doubt about that.

What I am saying is that was then and now is now. We are now sitting here in 2026 and the world of comms has moved on dramatically and the broadcast world has moved along with it and that those people still clinging on to legacy ISDN will be forced to shift to IP-based technologies because they will be forcibly disconnected by their telcos very soon (1–5 years).

The reality is also that here in 2026 we live in a world where (a) you have a 4k tv and high-end audio system in your home ... so there is a natural limitation on what utility ISDN has in this world, and (b) the general public is increasingly consuming the media produced by the broacaster via IP means (streams over 5G-IP to mobile, streams over IP to Apple TV boxes) ... so if a broadcaster can escape the un-necessary complexity (and cost) of transcoding ISDN-received content to IP and shift to an IP-to-IP environment, why would they not want to do that ?

Post reply on HN