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

▲

yjftsjthsd-h 4 hours ago | parent | next [-]

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

▲

bombcar 4 hours ago | parent | prev [-]

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.

▲

yjftsjthsd-h 4 hours ago | parent [-]

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 the kernel as desired" is more reasonable, though they have binary packages including for the kernel and I don't see why the same idea shouldn't work there.

▲

Muromec 2 hours ago | parent | next [-]

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

	▲	patmorgan23 2 hours ago \| parent \| next [-]
		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.
	▲	tardedmeme 2 hours ago \| parent \| prev [-]
		On older versions of Windows you used to get popups saying new hardware is detected, would you like to install the driver now?

▲

PunchyHamster an hour ago | parent | prev [-]

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