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

Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

gentoo.org

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#51

Post by graemep »

siwatanejo wrote: post #46
graemep wrote: post #6

Earlier quoted context omitted.

Public goods are not generally funded by large corporations.

Errr.. are you saying that Linux contributors are only affiliated to small companies or volunteers? Well, last time I checked, some contributors were RedHat(IBM) and Microsoft employees ;)

I am saying that big company funding of some FOSS is exceptional compared to the economy at large. Most public goods are not funded by bug companies. They do not do the same for roads or public health services, or free education or public libraries etc.

Even with FOSS few projects get the funding or contributions the Linux kernel does.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#52

Post by c7b »

ordu wrote: post #35
c7b wrote: post #26

Earlier quoted context omitted.

Linux itself, major Linux distros, npm - none of these were designed with a security-first approach. Even the things that do help with security, like package maintenance or containerization, were more incidental to other primary goals like stability, reproducibility and so on rather than being born from a comprehensive security-first strategy. They could have been, but then things would have moved slower. They even e…

I technically agree, but it seems too abstract to me. How could look a distro maintenance, if it was built with a security-first approach? Maybe I have not enough fantasy and/or creativity, but trying to imagine it, I see just a bit more of oversight built into protocols of approving changes to repositories. I mean, it doesn't seem that improved security needs an approach "destroy everything and build it from scratch…

If we were to start from security first, we would be asking questions like 'how can we make sure that new code is safe?'. Manual review is great, but we can likely think of some desirable invariants for program behavior that could be tested automatically, or even formally verified. Those would come at the very start. The entire mindset right now is that the existing code is probably unsafe and we'll ship fixes as we discover its vulnerabilities. Not immediately applying updates is seen as a kind of moral failure. All major OS and most software projects were developed with this mindset of crossing your fingers at launch and then changing the tires while driving. So much so that we think of it as the natural state of software. If you start from a base of verified code, the mindset shifts. Not that there are zero vulnerabilities guaranteed in the existing code, but you become a lot more suspicious of new code.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#53

Post by walletdrainer »

markus92 wrote: post #50
walletdrainer wrote: post #47

Earlier quoted context omitted.

> Can we make the kernel vulns less important? Local kernel vulns are totally unimportant in any vaguely reasonable environment.

They absolutely suck in HPC environments. Bunch of users running all types of code that can just LPE themselves to root, not a good scenario.

Yes, but academic HPC environments are very 90s and are far from what is generally considered reasonable in 2026.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#54

Post by Muromec »

patmorgan23 wrote: post #20
Muromec wrote: post #19

Earlier quoted context omitted.

>but then package those modules into separate packages. If you don't need somedriver.ko, then you don't `apt install linux-driver-somedriver But I don't want to know what drivers I need and will need next. Tomorrow I could buy a different wifi module and then what? Spend 3 hours googling which rtl378326973268632aahaxhabt.ko to install? Thanks but no thanks.

So why can't someone (probably the distro) build a utility that detects the hardware and installs the required kernal module? We can have security and convenience.

I'm not sure what we get in terms of security then.

Now, when kernel finds a USB device with product vendor id 123:456 it asks userspace for a driver for this id. Every .ko file has this metadata saying which device ids it supports. Notice that important part of being able to trigger the device load event here is physical access to plug in the device.

If each module has to be installed, then what? We would have the index of all modules, but not the modules themselves, so each time a new usb device is plugged in, the thing will do apt-get install something something and wait for a minute or three. Where is the upside really?

Maybe what you want is being in the loop for what modules are loaded and approve them manually? That will suffer from the usual operator fatigue and requires understanding what each of 225 modules (I just checked lsmod | wc -l) is doing.

Re: Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

#55

Post by akimbostrawman »

ordu wrote: post #32
ahartmetz wrote: post #17

Earlier quoted context omitted.

Whenever you read about an incredibly unlucky criminal, there's a chance that the unlucky event is a parallel construction to the classified real reason why they were caught. Not sure how exactly that would have worked in this case.

Yes, it could be. But it is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals? Are you arguing that the system may be more resilient than it seems? Like, maybe there is a conspiracy working on security. And they keep themselves secret so attackers would be susceptible to under-appreciate the real level of security and make mistakes that inevita…

>is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals?

Its always amusing to me when people use "conspiracy theory", a word deliberately popularized and weaponized by said agencies (CIA Memo 1035-960) to mock people for doubting and asking questions about there supposed operations and tactics.

Post reply on HN