Live data from Hacker News

Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

gentoo.org

1–10 of 55 posts

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

#3
post #2

Is Gentoo an outlier or do all Linux distributions deal with this problem?

Many distros deal with the problem of learning about these issues the same time as the public. Some have fast track processes to ensure patches can get into their stable/rolling releases but it is still a lot of work (especially as kernel updates usually mean that automatic updates won't fully shipped you (without alsp automatically rebooting after an update)).

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

#4
Expanding on gentoo's recommendations:

I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already have that at a lower level with normal application updates.

Canonical has thus far proved that it can be safe, but they're also a massive organization that is locking this feature for $200/yr for any commercial use.

It would be neat if such patches could retroactively replace tagged functions that have identical sematics so that means it would automatically get backported without extra effort from the maintainers.

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

#5

Expanding on gentoo's recommendations: I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already…

Why would the source of the patches be less trusted than the source of (updated) kernels? I expect it to be the same, your distro.

$200/year is peanuts for any commercial use worth the name. The problem, of course, is the whole non-free infrastructure it has to introduce.

I wonder when large and critical OSS projects will start to be seen as a public good they are, with large corporations willingly financing them because not doing so is bad PR.

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

#6
post #5

Expanding on gentoo's recommendations: I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already…

Why would the source of the patches be less trusted than the source of (updated) kernels? I expect it to be the same, your distro. $200/year is peanuts for any commercial use worth the name. The problem, of course, is the whole non-free infrastructure it has to introduce. I wonder when large and critical OSS projects will start to be seen as a public good they are, with large corporations willingly financing them bec…

Public goods are not generally funded by large corporations.

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

#7

Expanding on gentoo's recommendations: I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already…

After the npm supply chain attacks people suggested automating delays before installing updates, now we're talking about automating update delivery... I'm afraid there won't be any easy or quick fix after decades of treating security as an afterthought.

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

#8

Expanding on gentoo's recommendations: I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already…

> I wonder if we should just universally accept that live patching should become part of the linux kernel?

I think we can learn many lessons from the recent SNAFUs before going all wild on auto-patching.

One lesson for example is that you shouldn't compile into the kernel modules that only about 0.00001% of all Linux installations out there are ever going to use.

Another lesson is that even if the modules are compiled, but not into the kernel, they should probably be blacklisted (preventing them from loading) by default and only removed from the blacklist by people who really know they'll need these rarely used modules.

We're way past the "but it needs to work on all cases": we're now into the "users installing our distro are getting hacked left and right" territory.

In any case I think many things can be done before Linux distros reproduce the "security" practices of the NPM ecosystem.

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

#9
> We recommend exploring ways to automate upgrading your kernel

Like, running emerge -u @world on a regular basis, or ...

/me searches

Okay, so https://wiki.gentoo.org/wiki/Live_patching exists but says,

> A note of caution: Kernel live patching is risky. Count on hard freezing or panics to become normal...

That's not encouraging.

---

Another approach: Can we make the kernel vulns less important? Has anyone had luck moving more things to run under gvisor or firecracker or such?

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

#10

Expanding on gentoo's recommendations: I wonder if we should just universally accept that live patching should become part of the linux kernel? An automatic job that updates (much like some system packages in some distros) that installs (signed) live patches from upstream? Of course we would run into a problem where a malicious patch can now be distributed reliably to hundreds of thousands of machines, but we already…

> I wonder if we should just universally accept that live patching should become part of the linux kernel? I think we can learn many lessons from the recent SNAFUs before going all wild on auto-patching. One lesson for example is that you shouldn't compile into the kernel modules that only about 0.00001% of all Linux installations out there are ever going to use. Another lesson is that even if the modules are compile…

> we're now into the "users installing our distro are getting hacked left and right" territory

Are we? Are users actually getting hacked, or have they theoretically been exposed to problems that could allow local privileged escalation if exploited but that nobody's seen used in the wild?

(Edit: To be clear, I'm skeptical but this isn't a completely rhetorical question. If there are actual reports of these vulns causing problems, that would strongly incentivize a stronger response.)

Post reply on HN