R4.0 and R4.0-rc2 Instructions for USB Keyboard w/Sys-USB fails
Eric Duncan
https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard
Tried on two ISOs: R4.0 (bare ISO install, no updates) and R4.0-rc2 (up to date).
Tried on two systems: Thinkpad X1 Tablet 3rd Gen and Apple Macbook Pro mid-2014.
Both systems reboot to a keyboard that does not work to enter LUKS password, and therefore losing all access to the system.
I'm guessing I need to configure the keyboard for USB pass through? As a step missing perhaps?
The command executes properly:
sudo qubesctl state.sls qvm.usb-keyboard
And after a reboot, the system doesn't allow USB keyboard.
The odd part is... I can press ESC and get to the text output of LUKS asking for password. So something is kind of working?
Lorenzo Lamas
The guide also shows how to hide all USB controlles from Dom0. This is now default, so you need to unhide them. Indeed strange though that ESC is still working.
Eric Duncan
Do you think I need to pass an entire controller? Could I start of focus on what IDs the USB keyboard is using and just pass that? I'm new to USB pass through processes, so these are my first attempts.
Whichever is the case, I'll update the guide as well with a PR to add this step.
The guide is also a bit annoying as for other a year I always thought it was only for USB block devices - until I recently scrolled all the way down - and now see the info about other USB devices. I'll add an Introduction as well to help clarify things and what all that guide covers.
On Friday, January 4, 2019 at 12:54:56 PM UTC-5, Lorenzo Lamas wrote:
> On Friday, January 4, 2019 at 6:29:37 PM UTC+1, Eric Duncan wrote:
> >
> > The odd part is... I can press ESC and get to the text output of LUKS asking for password. So something is kind of working?
>
> Indeed strange though that ESC is still working.
It's a race condition when Xen is attaching USB controllers? If I act quickly, I can get a few characters typed until the keyboard goes dead. Which begs the question, why does Xen allow me to even type a few chars before the usb is redirected?
Lorenzo Lamas
> > The guide also shows how to hide all USB controlles from Dom0. This is now default, so you need to unhide them.
>
> Do you think I need to pass an entire controller? Could I start of focus on what IDs the USB keyboard is using and just pass that? I'm new to USB pass through processes, so these are my first attempts.
>
> Whichever is the case, I'll update the guide as well with a PR to add this step.
>
> The guide is also a bit annoying as for other a year I always thought it was only for USB block devices - until I recently scrolled all the way down - and now see the info about other USB devices. I'll add an Introduction as well to help clarify things and what all that guide covers.
>
>
Method 3 is to attach the whole USB controller using Xen PCI passthrough. When creating a USB Qube(sys-usb), all USB controllers are attached to this Qube so Dom0 is protected from all USB devices. You can then connect USB devices to other Qubes when necessary with method 1 and 2.
This means if you use a USB Qube, if you attach a USB keyboard, it is also connected to sys-usb, and not Dom0, and you cannot use USB passthrough on Dom0, so you can't use it to type. To solve this, the USB qube gets permission to send keystrokes to dom0(done automatically when you execute qubesctl state.sls qvm.usb-keyboard). (Btw, this means that the USB qube can send keystrokes to Dom0 and also see sent keystrokes i.e. passwords. If you or someone connects a compromised/evil USB device to sys-usb it can thus sniff your passwords or sent commands to Dom0. If you don't want this: A: only use built-in laptop keyboard or PS/2 keyboard and don't give USB Qube permission to send keystrokes. If this is not possible or external USB keyboard is needed: B: if you have multiple USB controllers you might be able to create a second USB qube and attach one of the USB controllers using PCI passthrough to that device and leave the others connected to the first USB Qube. Then you can allow permission to send keystrokes for the second USB Qube and connect your keyboard to the USB ports belonging to that USB controller, and connect other (untrusted) USB devices to the USB ports from the other controller connected to the first USB Qube. Now you're protected from malicious devices unkowingly connected by yourself, an attacker might of course still attach the device to the other USB ports.
And/Or C: use the DisposableVM feature with sys-usb to ensure a clean sys-usb every boot. This is more useful for a non-targeted attack/accidental compromise. Of course compromise can still happen between boots.
Even with a USB Qube, Dom0 is still unprotected from USB devices during boot, this why USB controllers are hidden from Dom0 during boot.
To enter your LUKS password, you only need to unhide the USB controllers from Dom0. If you have access to your machine you can follow the standard instructions to hide them, but instead of adding the line(s) "rd.qubes.hide_all_usb" you need to remove them. If you don't want to reinstall Qubes, you can boot the machine, then edit the boot command in Grub during boot(not sure how that works with (U)EFI boot) by pressing 'e' and remove "rd.qubes.hide_all_usb" on the same place(s) and press ctrl+x to boot. Then after booting is complete also remove "rd.qubes.hide_all_usb" with the normal instructions to make it permanent.
> On Friday, January 4, 2019 at 12:54:56 PM UTC-5, Lorenzo Lamas wrote:
> > On Friday, January 4, 2019 at 6:29:37 PM UTC+1, Eric Duncan wrote:
> > >
> > > The odd part is... I can press ESC and get to the text output of LUKS asking for password. So something is kind of working?
> >
> > Indeed strange though that ESC is still working.
>
> It's a race condition when Xen is attaching USB controllers? If I act quickly, I can get a few characters typed until the keyboard goes dead. Which begs the question, why does Xen allow me to even type a few chars before the usb is redirected?