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

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.

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.

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.

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

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.

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

You can run emerge -u sys-kernel/whatever-kernel-u-use, maybe followed by `cd /usr/src/linux; make bzImage modules install modules_install...` well, probably you'd use genkernel or something like that, instead of hand-crafted scripts.

The point is: `emerge -u @world` can run into issues esp. if you customized a lot, it can't be automated fully, but I've never run into any issues with updating the kernel, and it can be automated.

It is not so hard to upgrade kernel, the issue is with the reboot you need do automate. Or with live patching, which doesn't seem encouraging, as you say.

> Can we make the kernel vulns less important?

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

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

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/             metadata.xml         udev-hid-bpf/
    cryptodev/           hurd/                mips-sources/        ugrd/
    dkms/                installkernel/       modprobed-db/        vanilla-kernel/
    dracut/              kci-dev/             pf-sources/          vanilla-sources/
    dracut-crypt-ssh/    kergen/              raspberrypi-image/   virtme-ng/
    genkernel/           kpatch/              raspberrypi-sources/ zen-sources/
    gentoo-kernel/       linux-docs/          rt-sources/
    gentoo-kernel-bin/   linux-firmware/      rumpkernel/
    gentoo-sources/      linux-headers/       scx/