What is the proper way of having `rd.qubes.hide_all_usb` and still being able to enter LUKS password using USB keyboard?

[DVM]

@balko

So, how reliable usbcore.authorized_default=0 is compared to having a separate PCI controller for keyboard?

It depends on your threat model. If you’re okay with your keyboard and mouse sharing a controller with other devices, then setting usbcore.authorized_default=0 is fine. However, if you want to isolate them, you can use a different controller and either keep it in dom0 with rd.qubes.dom0_usb or present it to sys-usb after LUKS unlocking.

@balko

As I see it, usbcore.authorized_default=0 looks like the best solution for average person with USB keyboard. So, is usbcore.authorized_default=0 set in R4.2+ by default instead of rd.qubes.hide_all_usb in case of USB keyboard?

The Qubes Installer automatically detects the use of a USB keyboard and adds the correct boot option. Check the file /etc/default/grub; it should include usbcore.authorized_default=0 if you have a USB keyboard or rd.qubes.hide_all_usb if you don’t.

@balko

What is =0 in usbcore.authorized_default=0? What are other values? Do you have any link to docs about it? Or should I search the project’s code?

This is a native kernel boot option that controls how the kernel handles USB devices:

# https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
usbcore.authorized_default=
                        [USB] Default USB device authorization:
                        (default -1 = authorized (same as 1),
                        0 = not authorized, 1 = authorized, 2 = authorized
                        if device connected to internal port)

USB devices are not authorized at boot when set to 0. USBGuard allows input devices manually at boot, so the keyboard and mouse can work until sys-usb takes over the controller(s).