When I do an lsusb, my little NUC box has FOUR controllers. That looked promising; perhaps that lone USB2 port is on one of the controllers and of course that’s the one you’d want to plug a keyboard into, right?
However, every single outlet on the box belongs to the first USB controller. [correction–I don’t think I checked the USB-Cs or the two USB3-A ports on the front. I need to do that, just to be sure.]
What the heck are the other three for, I wonder?
I don’t really understand the amount of emphasis on PS/2 unless you are worried about a physical attacker.
When ALL modern desktop hardware is “not recommended” unless you buy a specific extra module it is not fun.
Not true, I use the Z690 with a 12th gen intel, it has both 1 PS/2 port and 3 USB ports.
Ok I admit modern hw with PS/2 ports does exist but it is rather… exotic. I did not even know it til today and never seen one.
It does greatly limit the candidates, but the hardware does exist.
Judging from the single decade old Compaq listed, it looks to me like it’s meant to be a list of fully built desktop systems like you buy from Lenovo or Dell.
Maybe I’m misunderstanding the list, but it seems to me that you would need to buy a ThinkCenter that works flawlessly with Qubes to be able to get it on the list, but it would also need to be confirmed by multiple people.
It’s just not very likely to happen, when you factor in how fast Lenovo discontinues their product lines, and that it is becoming increasingly difficult to find hardware that doesn’t require minimal troubleshooting by updating to current kernel and linux-firmware package.
My point is that I do not see this requirement crucial for most users. The actual reason why PS/2 is “recommended” is not security, it is stability. It prevents you from being locked out from your system by accident. And THAT should be fixed in other way than forcing people to buy exotic PS/2-enabled hardware which they do not actually need otherwise.
Having PS/2 makes it a lot easier to install Qubes OS with sys-usb, without PS/2 you are going to need to install the sys-usb yourself.
Assuming the list is meant for someone that needs an off the shelf fully build system, it makes sense they have the option to install qubes without having to worry about installing sys-usb, which easily can turn into a death trap.
It is not because PS/2 is good, it is because sys-usb workflow is broken and unreliable and should be fixed – and buying a PS/2 hardware is NOT the proper fix.
USB is a high security risk.
PS/2 is a low security risk.
Up until just recently desktops all had ps/2 connectors and 99% of laptop integrated keyboards/pointers were (effectively) ps/2.
This is why the Qubes developers recommend taking usb out of dom0 as it generally wasn’t necessary for a functioning system.
However if ps/2 is missing it cannot be added.
It’s been around so long it has been baked into the chipset (or even the CPU/APU). Pci/pcie came around much much later. Any ps/2 pcie/expresscard/thunderbolt ps/2 expansion you find is assuredly a usb controller with a ps/2->usb HID bridge->usb controller stack on it.
Usb device routing is a $#|+ show because usbip is rather terrible and it’s the only game in town (other than directly connecting usb controller pcie devices to VMs…and for keyboard/pointer, that would be dom0, which is to be avoided).
Best recommendation I have is an easily discovered boot option (not requiring knowledge of command line and usable since usb isn’t disabled yet) to allow usb controllers to be connected to dom0 for this boot but only allow dom0 to automatically enable keyboard/pointer HID devices.
A physical attacker could use this feature, sure, but with physical access they could do a lot more so this doesn’t seem substantially higher risk.
B
I think non-mitigatable part of USB HID risk is non-issue for the majority of users. And if it is so important as they say, I wonder why trivial software mitigations like USBGuard never made their way to Qubes upstream.
What I can’t quite figure out (and this may be a part of arkenoi’s complaint) is why, during installation, it doesn’t install the keyboard version of sys-usb if it finds you’re using a USB keyboard–rather instead it just doesn’t install any kind of sys-usb. (For that matter, I’d give the user the option of defaulting the mouse to being OK as well. I first turned on the USB qube last night and the mouse being useless until I keyboard navigated through a popup window to turn it on was an aggravation.)
At least provide the option.
I think in most (but not all–that’s why it should be an option) cases, a user is willing to trust their keyboard and mouse won’t hose dom0. Besides, they don’t have a choice given their platform. The choice is NOT between a good keyboard/mouse plus bad USB devices, versus bad USB keyboard, mouse and other devices…it’s between leaving USB keyboard and mouse unguarded as well as other USB devices, versus having just the keyboard and mouse unguarded.
The current setup is basically telling the non-geeky user that since he has a keyboard and mouse it doesn’t trust, it will pick up its marbles and go home and not even try to guard against a bad thumbdrive. That makes no sense. It’s letting the perfect be the enemy of the good.
I think they are coming 
@SteveC, based on what you wrote I have the impression you might be a bit confused about what is actually happening.
When sys-usb gets created via the salt recipe a parameter is added to the kernel telling it to ignore USB devices. This is when the locking out happens, because you have to enter your disk password at boot but sys-usb is not running yet. Hence: no keyboard.
So there is the option to have a sys-usb qube but not add the kernel parameter. Which I think is what you means when talking about “the keyboard version of sys-usb”. In that case the kernel in dom0 allows all USB devices until sys-usb starts and takes over the USB controller.
The result is that any USB device could compromise dom0 during boot or whenever sys-usb is not running.
I agree with you that the user has little choice. Either they make this concession in security or they can’t use Qubes OS on their machine. However you wrote:
between leaving USB keyboard and mouse unguarded as well as other USB devices, versus having just the keyboard and mouse unguarded
That makes no sense and doesn’t reflect what is happening.
OK…yes, I forgot about it being unwise (with or without sys,usb (keyboard) to leave, say, a thumb drive plugged in during boot.
What I was thinking of in what I wrote was the situation after bootup. Because the sys-usb (keyboard version) was not installed, dom0 is vulnerable when I plug in a thumbdrive (or whatever) after I log in. (It will of course be vulnerable to a bad usb keyboard or mouse, but that’s true either with or without sys.usb (keyboard).)
I said it’s vulnerable after boot. Maybe I’m ignorant and that’s not so, maybe it’s just as protected with sys-usb as without to things like thumbdrives after boot, but if that’s the case then the keyboard version of sys-usb is no added value at all–it won’t protect during boot and there’s no need for it after boot.
@SteveC wrote:
the keyboard version of sys-usb is no added value at all–it won’t protect during boot and there’s no need for it after boot.
Again, the “keyboard version” is the one where dom0 does not ignore USB during boot so you can use your USB keyboard to enter the disk password. I’d say that’s tremendous value IF you want to boot at all. 
OK, we’re talking at cross purposes.
Yes, obviously IF you’re going to use a sys-usb you DO want it to be one that won’t block your USB keyboard, if you have a USB keyboard. You’re comparing sys-usb (keyboard safe version) to Sys-usb (without the keyboard exception); I’m comparing sys-usb keyboard to NO sys-usb at all. Which is what you get from the installer (no choice given) if you have a USB keyboard. You aren’t given the choice, you have to do some linux-geeky thing afterwards. (And we’re trying to make this easy, right?)
I’m not discussing why I should use the keyboard version over the non keyboard version; I’m discussing why the system defaults to installing nothing whatsoever when I have a USB keyboard, even though it could install something.
And what I’m hearing is that since someone might go ahead and plug a thumb drive into their box while it’s booting with the usb-keyboard version of sys-usb installed, it’s a good reason to not only not install it by default, but not even give the choice during installation. That makes no sense to me.
The installation software follows the logic:
So a guy with a USB keyboard has to a) be aware that he COULD be protected from other devices after bootup but isn’t in fact protected and b) then needs to know how to establish the protection. Whereas the guy with a PS2 Keyboard can just accept the default and be fine, or choose not to install.
Apparently, someone decided that because the USB Keyboard version of sys-usb can’t protect you from anything during bootup, it’s not worth installing for use after bootup (and of course you don’t want to use the other one–no disagreement there!). Someone has to go through a special procedure afterwards to enable it. Why? Presumably it provides value after bootup, so why not make it available during install?
(For what it’s worth, I just installed the USB keyboard version of sys-usb. I’m not opposed to it; I just wonder why the installer couldn’t do it.)
Hmm I’m not yet migrated to 4.1 but I could have sworn usbguard was being integrated.
B
Qubes 4.1 only: You should also add the usbcore.authorized_default=0 option, which prevents the initialization of non-input devices. (Qubes ships with a USBGuard configuration that allows only input devices when usbcore.authorized_default=0 is set.)
Anyway, we need a better and probably interactive USB device manager which DOES NOT impair the non-PS/2 experience. Telling people that all the current inconvenience is “for security” is goddamn silly.