How to boot without a PS/2 keyboard (only USB)?

[mxhq]

According to this post:

What is the proper way of having `rd.qubes.hide_all_usb` and still being able to enter LUKS password using USB 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. 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 usbc…

“The Qubes Installer automatically detects the use of a USB keyboard and adds the correct boot option.”

I take this to mean that if, as in my case, there is only a USB keyboard, then the installer will configure grub with

usbcore.authorized_default=0

and the appropriate bypass privilege granted to the attached USB controller.

However, when I try to boot, I just get the error message about rd.qubes.hide_all_usb due to USB being open. The boot process halts with this being the only message displayed, so I have no opportunity to run grub2-config in order to correct the problem with an updated config file (and wouldn’t have a usable keyboard even if I did).

I tried to boot from another live OS in order to get into the Qubes partition and manually correct this but then I ran into other problems. Intuitively, I’m off in the weeds and this should just work out of the box. Is there a better way to do this? I’m sure I’m not the only user to ever try Qubes without a PS/2 keyboard.

My understanding is that the installer would need to find the controller to which the USB input device(s) are attached, punch a hole in the security policy for this controller, and use grub2-mkconfig to modify the grub config accordingly, all automatically during install. This could get complicated if there is more than one input device or they happen to be sitting deep in the hub tree or distributed across separate trees. As a practical matter, it might therefore be acceptable to ignore input devices behind hubs, with the lower PCI controller address being used to choose which controller gets the bypass privilege in the event that there are multiple instances of this configuration discovered. But is this happening under the installer hood? I have no idea if it’s trying and failing, or just not trying.

[shantyspruce]

USB troubleshooting

To solve the problem, disable the USB qube by not having it autostart, or unassigning your USB controller(s) from it. If you had created the USB qube by checking the box in the installer, then your USB controller(s) are probably hidden from dom0. To unhide them, reverse the procedure described in how to hide USB controllers from dom0 (i.e., remove rd.qubes.hide_all_usb instead of adding it).

[mxhq]

I had given up on ever getting a reply and just happened to log in, so thanks for the feedback.

Unfortunately, there is no line in /etc/default/grub which has GRUB_CMDLINE_LINUX. Only GRUB_CMDLINE_LINUX_DEFAULT. And it doesn’t contain anything about hide_all_usb. I can’t even add it because then grub2-mkconfig complains about not being able to get the canonical path of my live OS root account (which I’m using in an attempt to target Qubes’ boot folder). In other words, it seems like grub2-mkconfig is forcing the assumption that I must be targetting the live OS instead of Qubes, regardless of the path to which I point it.

I didn’t see anything in the installer that would allow me to choose any sort of USB policy.

To be clear, after installation, Qubes halts with:

Warning: USB in dom0 is not restricted. Consider rd.qubes.hide_all_usb or usbcore.authorized_default=0.

Maybe my firmware is just not up to the task. Or maybe it is but I can’t conceive of what the workaround would be.