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

21–30 of 55 posts

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

#21

Post by belorn »

yjftsjthsd-h wrote: post #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…

If we are looking at things like gvisor or firecracker, SELinux might be an alternative. From what I can see, SELinux prevented both copy fail and dirty frag, and maybe also fragnesia but I couldn't find any definitive answer on that one.

Last time I tried it was a pain to setup and a pain to use, but as a sysadmin there is a lot of thing that share those attributes. The only question if its worth it. If the current avalanche of patches continues it might.

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

#22

Post by tardedmeme »

Muromec wrote: post #19
yjftsjthsd-h wrote: post #12

Earlier quoted context omitted.

It seems like a reasonable middle ground for most distros is to put things in kernel modules, but then package those modules into separate packages. If you don't need somedriver.ko, then you don't `apt install linux-driver-somedriver`; if you do need it, just install the package and it just works without needing to compile anything and you get automatic updates and everything. For Gentoo , of course, "just recompile…

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

On older versions of Windows you used to get popups saying new hardware is detected, would you like to install the driver now?

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

#23

Post by tardedmeme »

ordu wrote: post #15
clircle wrote: post #2

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

All of them need to do it. There maybe differences, like different number of versions of kernel supported, so less of backporting, but still distros have to provide fixed kernels. With Gentoo I believe it is more fun, because of all the options gentoo provides out of a box. More kernels, more work to do. ls /var/db/repos/gentoo/sys-kernel/ asahi-sources/ git-sources/ linux-next/ scx-loader/ bliss-initramfs/ gnumach/…

When I used Gentoo the normal was to install gentoo-sources, which gives you the kernel source code but doesn't compile it. You then have to compile and install the kernel yourself without any support from the package manager.

If you're running on a different platform then perhaps you need the raspberrypi or asahi kernel

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

#24

Post by fsflover »

yjftsjthsd-h wrote: post #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…

> Can we make the kernel vulns less important?

How about strong virtualization? https://qubes-os.org

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

#25

Post by elevation »

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

> live patching should become part of the linux kernel

Services where uptime matters tend to be designed so they can tolerate the reboot of a single node for other reasons besides kernel maintenance. I can't imagine a situation where I can't tolerate the downtime of a reboot but I would be willing to risk the system locking up with brain surgery gone wrong.

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

#26

Post by c7b »

ordu wrote: post #13
c7b wrote: post #7

Earlier quoted context omitted.

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.

Linux distros are not npm. It doesn't mean they are infallible to malicious actors, but I believe it is possible to make them infallible for some small set of packages at least. Attacks are still possible, but if we look at xz backdoor attack[1] it was insanely complicated attack and it still failed. Its fail doesn't look promising, attack could succeed just the attacker was unlucky. Still it shows that the success i…

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 exist, like Alpine, OpenBSD, RedoxOS, but the major ones, the ones we're talking about today, were the ones who moved faster and managed to take over. That's the fundamental issue I'm talking about, the mindset shift that would be required before we could even start the Herculean effort of rebuilding much of the existing stack with different architectures, in different languages and using different development models, always knowing that, in the past, the ones who moved fast and broke things instead tended to be the ones who succeeded.

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

#27

Post by PunchyHamster »

elevation wrote: post #25
himata4113 wrote: post #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…

> live patching should become part of the linux kernel Services where uptime matters tend to be designed so they can tolerate the reboot of a single node for other reasons besides kernel maintenance. I can't imagine a situation where I can't tolerate the downtime of a reboot but I would be willing to risk the system locking up with brain surgery gone wrong.

We've used ksplice for good amount of years (till bought by Oracle and they stopped publishing patches for other Linux distros) and all in all it was very stable technology 10 years ago

> I can't imagine a situation where I can't tolerate the downtime of a reboot but I would be willing to risk the system locking up with brain surgery gone wrong.

Because you haven't worked at that level in organization. Doing restart in some case might involve paperwork with your client and maintenance window outside of working hours even if service is redundant. And some customers are fine with a little bit of downtime and don't want active/active level of redundancy but still insist of maintenance windows for any work like that.

Live patching makes that a whole lot easier

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

#28

Post by edelbitter »

throwa356262 wrote: post #18
himata4113 wrote: post #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…

I dont belive in live patching unless you are AWS. But I absolutely belive we should have a method for changing kernel configuration (e.g. kernel module blacklists) and syscall firewalls and alike.

Easier: Do not start with a "allow all" configuration in the first place.

Maybe all of those userspace-work-done-in-kernel-because-muh-performance features should be restricted to (the "real") CAP_NET_ADMIN, unless positively enumerated as free-for-all-containers. And then subtract from that free-for-all list every time you learn that some kernel module in its currently available version cannot be trusted to do its own memory shuffling.

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

#29

Post by PunchyHamster »

yjftsjthsd-h wrote: post #12
bombcar wrote: post #11

Earlier quoted context omitted.

It used to be relatively standard even on the "big" distros to compile your own kernel if you needed something outside of the bog-standard. Modularization and all the related auto-detect auto-mod tools have resulted in most distros shipping a "works for almost everyone" kernel that has everything available as a module. Perhaps we should tend toward the first.

It seems like a reasonable middle ground for most distros is to put things in kernel modules, but then package those modules into separate packages. If you don't need somedriver.ko, then you don't `apt install linux-driver-somedriver`; if you do need it, just install the package and it just works without needing to compile anything and you get automatic updates and everything. For Gentoo , of course, "just recompile…

That's in generally available distro a huge PITA.

You can do blacklists easy enough if you want to, just add few lines of text into /etc.

I'd also like option for whitelisting, like whitelisting every single NIC driver is harmless enough coz they just won't be loaded, but anything that can be loaded by non-root userspace action should have option to be only loaded if it is on whitelist.

Tho all that is easily doable by just changing userspace AFAIK

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

#30

Post by toast0 »

elevation wrote: post #25
himata4113 wrote: post #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…

> live patching should become part of the linux kernel Services where uptime matters tend to be designed so they can tolerate the reboot of a single node for other reasons besides kernel maintenance. I can't imagine a situation where I can't tolerate the downtime of a reboot but I would be willing to risk the system locking up with brain surgery gone wrong.

> Services where uptime matters tend to be designed so they can tolerate the reboot of a single node for other reasons besides kernel maintenance. I can't imagine a situation where I can't tolerate the downtime of a reboot but I would be willing to risk the system locking up with brain surgery gone wrong.

I've run systems with live code updates for userland, and would have considered live kernel updates if it was reasonable on our systems.

The thing is you typically build your system to tolerate reboot or unscheduled stop of a single node. Scheduled stop is nicer, but systems sometimes lock up even when you're not doing risky behaviors, so you know.

But just because the system can tolerate a reboot or restart doesn't mean it's not disruptive. A lock up / etc during hot load is also disruptive, of course. But when you can push code without having to stop anything, with limited impact on users, it makes it easier and faster to do updates. You can use whatever rollout pattern you like to contain risk too; same as you would for an upgrade with restarts.

For us, we have servers with hundreds of thousands or millions of tcp connections from mobile clients. Restarting a server would make all those clients have to reconnect and connecting is expensive. Restarting all the servers would result in many clients reconnecting several times. It was better to avoid it when possible.

Post reply on HN