Ease creating USB VM even if USB keyboard is used

[marmarek]

Even if the system have only one USB controller, and only USB keyboard, creating USB VM, with qubes.InputKeyboard service, part of input-proxy, enabled still makes some sense. While USB VM will be able to spy and/or subvert the keyboard, user will see resulting actions. Malicious USB device will not be able to exploit some dom0 kernel driver, silently in the background. And when bundled with some 2FA, malicious USB VM will not be able to unlock the screen on its own.

Besides enabling qubes.InputKeyboard service, there is one more problem: USB controllers are blacklisted in dom0 (specifically: connected to xen-pciback driver, before loading actual USB controllers drivers) - this prevents entering LUKS passphrase using USB keyboard.

For now, lets ease the basic thing:

• do not blacklist USB controllers early (only just before actual starting USB VM)
• enable qubes.InputKeyboard service

To (semi-)securely use it, user is responsible for disconnecting any untrusted USB device from the system for the boot time. Note that this (unfortunately) should be a standard routine even in non-USB keyboard case, because BIOS (also having USB drivers) potentially could be exploited by malicious device at early boot stage too.

Later, we can employ additional protection, using usb device authorization, to allow only HID devices and only for the LUKS passphrase entering time. This is still far less protection than USB VM + input-proxy, but something better than allowing all devices.

Some long term solution could be bundling minimal USB VM with input-proxy into initramfs, but at this level of complexity (and required work), it may be better to simply adjust hardware configuration instead (like installing separate USB controller for this).

This is related to #2959, #2116, #3203

[adrelanos]

Marek Marczykowski-Górecki:

Even if the system have only one USB controller, and only USB keyboard, creating USB VM, with [`qubes.InputKeyboard` service, part of input-proxy, enabled](https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard) still makes some sense.

In this situation (system with only one USB controller, and only USB keyboard) it also makes sense to use USBVM for features only: it allows one to assign specific USB devices to specific VMs, which is great! (Even if these are not mass storage, which would work even without USBVM.)

[adrelanos]

Marek Marczykowski-Górecki:

Even if the system have only one USB controller, and only USB keyboard, creating USB VM, with [`qubes.InputKeyboard` service, part of input-proxy, enabled](https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard) still makes some sense.

In this situation (system with only one USB controller, and only USB keyboard) it also makes sense to use USBVM for features only: it allows one to assign specific USB devices to specific VMs, which is great! (Even if these are not mass storage, which would work even without USBVM.)