Hacker News Reader

Comment by TacticalCoder | Hacker News Reader

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

View on HN

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

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

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

That existed for a very short period of time before it became simpler to just ship everything all the time. I remember at least one distro booting with a single processor kernel and detecting that it could use an SMP kernel and did I want to pull it down?

and how would it get that module without network access. I'd say for network drivers specifically, this is tough one.

It would work for various other drivers though.

The standard method is for the installer to have the needful and then it knows what packages to install to give you the network drivers you need going forward (shades of slipstreaming in all the network drivers I could find into W2K custom ISOs so I'd not need to find floppies).

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.

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

It was always fun to get those when the hardware hadn't changed.

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

Reply on news.ycombinator.com