qubes-pciback: add optional support for PCI device whitelisting

[3hhh]

This feature can be used by advanced users to assign devices to pciback in a policy-like manner based on various PCI device attributes.

References QubesOS/qubes-issues#7886 QubesOS/qubes-issues#7792

[marmarek]

First of all, please s/whitelist/allowlist/;s/blacklist/blocklist/.
But then, I don't like the file embedded into initramfs as the only configuration option - this is incompatible dracut --no-hostonly (which should produce universal initramfs, independent of local hardware). There should be an option to use cmdline for that.
Additionally, asking the user to use regex directly sounds like a massive footgun. It's easy to match vendor/product id instead of device class for example. Better go with more constrained approach: for example list of allowed classes, or maybe just list of allowed devices directly (list of BDF, as for rd.qubes.hide_pci).

[3hhh]

On 11/23/22 02:35, Marek Marczykowski-Górecki wrote: First of all, please `s/whitelist/allowlist/;s/blacklist/blocklist/`. But then, I don't like the file embedded into initramfs as the only configuration option - this is incompatible `dracut --no-hostonly` (which should produce universal initramfs, independent of local hardware). There should be an option to use cmdline for that.

cmdline doesn't support complex character combinations (i.e. regex & newlines) well. Double quotes are an issue, too. An alternative would be to mount `/boot/` in initramfs and load the configuration from there, but I didn't want to make that call.

Additionally, asking the user to use regex directly sounds like a massive footgun. It's easy to match vendor/product id instead of device class for example. Better go with more constrained approach: for example list of allowed classes, or maybe just list of allowed devices directly (list of BDF, as for `rd.qubes.hide_pci`).

Yes, well it's powerful (it can express everything you mentioned and combinations thereof), but also dangerous. Personally I use something like ``` #host bridge ^[^"]+ "0600" ... #allow certain USB controllers ^[^"]+ "0c03" "8086" "ffff" ... ``` I'm not saying it's a cup of tea for everyone though.

[3hhh]

I think I now implemented what you probably meant.

Anyway if you don't like the overall approach, please close it down.

[marmarek]

I still don't like regex as configuration format. It's way too easy to produce both a) something that doesn't work at all (unpleasant but usually you can boot alternative kernel and fix your config), and b) config that appears to work, but does something completely different than you wanted (like not exclude devices you meant to exclude).

As for hostonly-mode compatibility, there should be a way to configure it purely on command line (yes, it's pretty much incompatible with using regex like you did), without embedding any extra config file.

Anyway, while this version probably is fine for you, it isn't something I want to introduce (and promise to maintain) into standard Qubes setup. If you want, you can open another PR with simplified (less powerful, but also less of a footgun) interface.

[3hhh]

Well, the only other relatively simple variant that might work as syntax language in bash would be globbing statements.

One could try that, but it still leaves the issue of PCIE hotplugging: Currently hotplugged PCIE devices (Expresscard, Thunderbolt, ...) will land in dom0 and may exploit whatever dom0 kernel bug there.
Maybe Xen PCIE hotplugging is disabled, but that won't stop the dom0 kernel from parsing the device and loading drivers etc.

IMHO that issue could only be solved with some sort of dom0 kernel driver that makes policy decisions. This driver should then also be used at boot time. So hopefully there's no need for the functionality of this PR in the long run.