LWN: Comments on "A firewall for device drivers"

A firewall for device drivers

ras — Tue, 24 Aug 2021 02:07:03 +0000

> As long drivers are built as modules, you can just not include banned drivers in the initrd, and stick modprobe blacklists.

Unfortunately the VM itself can change the blacklists, and obtain the modules from somewhere and insmod them. When your goal is to ensure someone who has taken over the VM can't escape from it, that's not a solution.

However, a simple sysfs "blown fuse flag" (ie, one you can not change back) that turns off module loading would work. You just run set it in the initrd, after it's loaded all the modules. There already is a corresponding capability.

A firewall for device drivers

pabs — Sat, 21 Aug 2021 00:52:11 +0000

ISTR Linux has a localmodconfig make target that could be used for this; build a full kernel, boot it on the hardware you want, note the loaded modules, and using localmodconfig build a kernel config with those modules and then turn CONFIG_* with =m into =y and build the result.

A firewall for device drivers

bustervill — Fri, 20 Aug 2021 13:49:14 +0000

> A nice idea. I sort of tried to achieve that goal until I realized it would take an insane amount of time to reach it and to stay at it at every release of a new kernel.

I used to do it as well, spending large amounts of time and attention. I think this is exactly the problem and the reason people (including me) prefer not to have do it anymore.

An XKCD comic is worth a thousand words: https://xkcd.com/1671/

A firewall for device drivers

ssmith32 — Mon, 16 Aug 2021 23:23:36 +0000

Or toggle the sysfs knob:

> There is also a new driver attribute in sysfs (called allowed) that can be used to change a driver's status at run time.

A firewall for device drivers

dullfire — Mon, 16 Aug 2021 11:45:28 +0000

While I have never gotten it to consistently work for GPUs (in theory there is a dependencies list you could jump through... I've never management to find it), for well written Wifi drivers, you should be able to unbind them (via sysfs), and then rebind them. Which should result in a new firmware request.

I believe buildin modules can also pull firmware from the initrd (since firmware loading has been move into the kernel, for reasons).

A firewall for device drivers

Wol — Sun, 15 Aug 2021 22:12:02 +0000

In that case (and I have the same problem with video card firmware), can't you include them in the kernel?

Cheers,
Wol

A firewall for device drivers

iabervon — Sun, 15 Aug 2021 20:47:31 +0000

The problem I've had with not having modules is with built-in wifi drivers detecting hardware before the root partition with the firmware is mounted, and not retrying later. Since everybody builds the drivers as modules, the assumption is that the firmware will be available as soon as the driver code is available. I could work around it (unbind and rebind the device once userspace is ready), but I don't really want to use an arrangement that clearly nobody else is testing.

A firewall for device drivers

jayalane — Sun, 15 Aug 2021 18:42:31 +0000

I used to do this also. Usually once you get a config that builds a kernel that boots your system you use it for the base of new kernels’ config, so the work is mostly one time (this as they mess with new config options etc. you might have to edit it a little, but not so frightful as the first one.

A firewall for device drivers

mokki — Sun, 15 Aug 2021 08:02:12 +0000

Could we instead tag each driver as "hardened". Then in virtualized (and other) environments we set a flag to allow only hardened drivers, built-in or not. Plus of course some whitelist, which should be hopefully smaller. At least the effort to review and harden drivers can be shared by community instead of each admin doing it separately.
Maybe the hardening flag could be a bit mask to tell what kind of hardenings have been done on it. Aka input validation, iommu support etc

A firewall for device drivers

dullfire — Sun, 15 Aug 2021 03:59:17 +0000

There are even nifty options like "make localmodconfig" which gives you an excellent starting point for selecting which modules you need.

Of course that only copies the currently loaded modules, but the thoery is if you currently running system supports most (or even all) the functionality you need, then those are a good base.

A firewall for device drivers

Wol — Sat, 14 Aug 2021 22:49:32 +0000

I still run a (almost) only static kernel. I think you're misremembering when kernels grew too big to fit in the space available for 32-bit. So a lot of stuff had to be compiled as modules to prevent there be loads of unused code that stopped the kernel from loading.

You'd need to do a bit of work, but not that much - gentoo users do it all the time :-) Just download the distro source kernel, do a lsmod to see what modules are loaded, then alter the config so those modules are compiled in. Leave out the "make modules" and "make modules_install" steps, and you should have a module-free kernel.

If you learn there are modules you missed, you can go down one of two routes. Either make a note of them to compile them into your kernel, or manually install them into /lib/modules or wherever they go.

Cheers,
Wol

A firewall for device drivers

ttuttle — Sat, 14 Aug 2021 21:31:32 +0000

I would read that if you wanted to write it and link to it here.

A firewall for device drivers

pebolle — Sat, 14 Aug 2021 20:56:19 +0000

> kernels that had only the exact device drivers I wanted

A nice idea. I sort of tried to achieve that goal until I realized it would take an insane amount of time to reach it and to stay at it at every release of a new kernel.

> This was a long time ago, so I could be misremembering, but I believe I was forced to stop doing this because the kernel stopped supporting static compilation; it was loadable modules or nothing.

That would mean CONFIG_MODULES (or its equivalent) was broken. I would be surprised if it still is.

A firewall for device drivers

malor — Sat, 14 Aug 2021 19:08:11 +0000

Back in the old days, I used to compile static kernels that had only the exact device drivers I wanted, on the theory that module loading was not secure.

I remain convinced that this is the case, and that static kernels would be safer, completely removing a giant attack space.

This was a long time ago, so I could be misremembering, but I believe I was forced to stop doing this because the kernel stopped supporting static compilation; it was loadable modules or nothing.

A firewall for device drivers

amboar — Sat, 14 Aug 2021 09:28:51 +0000

Perhaps the patch could exploit bootconfig

https://www.kernel.org/doc/html/latest/admin-guide/bootco...

A firewall for device drivers

pmulholland — Sat, 14 Aug 2021 00:37:57 +0000

I thought this article was going to be about hardware level firewalls, so I had prepared a comment about PCIe message signalled interrupts and the requirement to write directly to the interrupt controller from an external device... having RTFA, I see I’ll need to wait for another time to see how hardware firewalls are done. I can definitely see how a rough bus master or interrupt source could wreak havoc on a system.

A firewall for device drivers

dullfire — Sat, 14 Aug 2021 00:10:04 +0000

This sounds like a solution in search of a problem

I believe all mainstream distros let you select which drivers should go in the initrd (pretty sure most even have tooling to find a reduced, if not minimal set). As long drivers are built as modules, you can just not include banned drivers in the initrd, and stick modprobe blacklists.

The only situation that doesn't cover is built-in modules (which should both be rare, and usually/always nonsensical to blacklist).

Of course this doesn't include a solution to bootstrap it, but neither does the proposed solution.

A firewall for device drivers

Paf — Fri, 13 Aug 2021 22:05:17 +0000

This seems like a sound and simple solution except that I don’t think the kernel command line can take enough arguments.

A firewall for device drivers

bferrell — Fri, 13 Aug 2021 21:16:58 +0000

We could just abandon the concept of modular kernels, but then we're back to 1995... It's secure. The kernel will have an exactly known set of drivers, but a LOT of modern admins will NOT know how to recompile the kernel to change that set.

I'm all for it!

A firewall for device drivers

derobert — Fri, 13 Aug 2021 18:43:54 +0000

That has a similar problem as building different kernel versions. If on a VM I administer, what if I need to enable one extra driver? I might be using PCI pass through, for example. I'd have to either switch to the unrestricted set, decreasing security of the VM, or build a new kernel with a third set of signatures.

A firewall for device drivers

josh — Fri, 13 Aug 2021 18:08:50 +0000

This seems awkward to handle via a full list on the kernel command line. I wonder if this could use the existing driver signing infrastructure with a slight extension: Have two (or more) different signatures on each module, with different keys, and on the command-line pass which key "slot" to use to verify modules. That effectively allows selecting among "module sets" determined at compile time.