using sys-usb + usb keyboard + full disk encryption = inactive usb keyboard when you are asked to enter decryption key

[0spinboson]

Qubes OS version (e.g., R3.1):

R3.2rc2

---

Expected behavior:

I expected to be able to enter the decryption password using my (wireless, so unavoidably) USB keyboard.

Actual behavior:

USB keyboard is inactive; could only enter password using ps/2-connected kb

Steps to reproduce the behavior:

use full disk encryption; use a usb-keyboard, enable sys-usb, allow the keyboard to be passed to dom0 (in the manner described in the faq/documentation). reboot.

General notes:

If for whatever reason it is undesirable / impossible to enable the keyboard, it may be wise to put up a big fat warning that you won't be able to enter your decryption key after reboot. :)

[entr0py]

If you are referring to the LUKS password on boot, your keyboard being non-functional is not related to Qubes' USB isolation, since at that point in the boot process, Qubes hasn't had a chance to load at all.

Most likely, your keyboard driver isn't included in Fedora's initramfs. You'll have to add it using dracut - specifics will depend on your model.

[entr0py]

If you are referring to the LUKS password on boot, your keyboard being non-functional is not related to Qubes' USB isolation, since at that point in the boot process, Qubes hasn't had a chance to load at all.

Most likely, your keyboard driver isn't included in Fedora's initramfs. You'll have to add it using dracut - specifics will depend on your model.

[0spinboson]

Hm, that is quite peculiar, as I am quite certain that I could enter the password just fine until I enabled the USB cube. Oh well, I'll have a look at dracut then. :)

[0spinboson]

Hm, that is quite peculiar, as I am quite certain that I could enter the password just fine until I enabled the USB cube. Oh well, I'll have a look at dracut then. :)

[andrewdavidwong]

Can you please test it without and without the the USB qube enabled, then report back?

[andrewdavidwong]

Can you please test it without and without the the USB qube enabled, then report back?

[0spinboson]

Sure. Can I just delete the usb qube to disable it, or should I do
something else first?

On Sat, Aug 27, 2016 at 4:29 AM, Andrew David Wong <notifications@github.com

wrote:

Can you please test it without and without the the USB qube enabled, then
report back?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2270 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUGeHJzakPtT1ilsqNfdIEo-wK5l_kTHks5qj6DvgaJpZM4JuSpw
.

[0spinboson]

Sure. Can I just delete the usb qube to disable it, or should I do
something else first?

On Sat, Aug 27, 2016 at 4:29 AM, Andrew David Wong <notifications@github.com

wrote:

Can you please test it without and without the the USB qube enabled, then
report back?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2270 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUGeHJzakPtT1ilsqNfdIEo-wK5l_kTHks5qj6DvgaJpZM4JuSpw
.

[andrewdavidwong]

It's not necessary to delete it. You can temporarily disable it either by not having it auto-start or by unassigning your USB controller(s) from it.

[andrewdavidwong]

It's not necessary to delete it. You can temporarily disable it either by not having it auto-start or by unassigning your USB controller(s) from it.

[andrewdavidwong]

Note, however, that if you 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 here (under "Hide all USB controllers from dom0"), i.e., remove rd.qubes.hide_all_usb instead of adding it.

[andrewdavidwong]

Note, however, that if you 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 here (under "Hide all USB controllers from dom0"), i.e., remove rd.qubes.hide_all_usb instead of adding it.

[andrewdavidwong]

Also note, of course, that this means your USB controllers will be attached to dom0, so do this only with USB devices you trust.

[andrewdavidwong]

Also note, of course, that this means your USB controllers will be attached to dom0, so do this only with USB devices you trust.

[0spinboson]

I would try, but I don't see that file (probably because I'm using EFI
boot), and I'm not sure where else to look.

(Btw, I didn't create the USB qube during installation, but via the method
described in the documentation, yet usb devices are still hidden from dom0
even with all of the devices removed from the usb qube.)

On Sat, Aug 27, 2016 at 8:46 AM, Andrew David Wong <notifications@github.com

wrote:

Note, however, that if you 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 here
https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-2 (under "Hide all USB
controllers from dom0"), i.e., remove rd.qubes.hide_all_usb instead of
adding it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2270 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUGeHBRYMbXNOD5o1sh36UtchGfbDuiHks5qj91BgaJpZM4JuSpw
.

[0spinboson]

I would try, but I don't see that file (probably because I'm using EFI
boot), and I'm not sure where else to look.

(Btw, I didn't create the USB qube during installation, but via the method
described in the documentation, yet usb devices are still hidden from dom0
even with all of the devices removed from the usb qube.)

On Sat, Aug 27, 2016 at 8:46 AM, Andrew David Wong <notifications@github.com

wrote:

Note, however, that if you 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 here
https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-2 (under "Hide all USB
controllers from dom0"), i.e., remove rd.qubes.hide_all_usb instead of
adding it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2270 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUGeHBRYMbXNOD5o1sh36UtchGfbDuiHks5qj91BgaJpZM4JuSpw
.

[andrewdavidwong]

Note that if a USB controller is delegated to a domU, it will not be automatically returned to dom0 within that session:

https://www.qubes-os.org/doc/assigning-devices/#tocAnchor-1-1-4

[andrewdavidwong]

Note that if a USB controller is delegated to a domU, it will not be automatically returned to dom0 within that session:

https://www.qubes-os.org/doc/assigning-devices/#tocAnchor-1-1-4

[marmarek]

On Sat, Aug 27, 2016 at 02:33:16AM -0700, 0spinboson wrote:

I would try, but I don't see that file (probably because I'm using EFI
boot), and I'm not sure where else to look.

/boot/efi/EFI/qubes/xen.efi

And yes, if you enabled USB qube, it hides all the USB controllers from
dom0, even before it gets started. So, if your only keyboard is on USB,
you need at least to undo this hiding. But then, when sys-usb is started
it will again get USB controllers out of dom0, leaving you without
keyboard.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Sat, Aug 27, 2016 at 02:33:16AM -0700, 0spinboson wrote:

I would try, but I don't see that file (probably because I'm using EFI
boot), and I'm not sure where else to look.

/boot/efi/EFI/qubes/xen.efi

And yes, if you enabled USB qube, it hides all the USB controllers from
dom0, even before it gets started. So, if your only keyboard is on USB,
you need at least to undo this hiding. But then, when sys-usb is started
it will again get USB controllers out of dom0, leaving you without
keyboard.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[0spinboson]

Okay, that doesn't sound like I'll be able to work around it, esp. given that I have no clue how to edit the binary file xen.efi :)
Anyway, considering that this behavior is either intended or unavoidable, and not worked around all that easily, I would suggest inserting a warning somewhere, probably on the usb documentation page. (I'd be happy to do this myself, if that would help?)

[0spinboson]

Okay, that doesn't sound like I'll be able to work around it, esp. given that I have no clue how to edit the binary file xen.efi :)
Anyway, considering that this behavior is either intended or unavoidable, and not worked around all that easily, I would suggest inserting a warning somewhere, probably on the usb documentation page. (I'd be happy to do this myself, if that would help?)

[0spinboson]

BTW, for completeness I installed a fresh QubesOs 3.2rc2 on an empty drive I had lying around, again with FDE enabled. Rebooted a few times without sys-usb enabled/installed, so without USB devices being hidden from dom0. USB keyboard worked fine. Then enabled sys-usb, rebooted. Result: USB keyboard could no longer be used to enter the password.

[0spinboson]

BTW, for completeness I installed a fresh QubesOs 3.2rc2 on an empty drive I had lying around, again with FDE enabled. Rebooted a few times without sys-usb enabled/installed, so without USB devices being hidden from dom0. USB keyboard worked fine. Then enabled sys-usb, rebooted. Result: USB keyboard could no longer be used to enter the password.

[entr0py]

1. I stand corrected - my apologies:

   if you enabled USB qube, it hides all the USB controllers from dom0, even before it gets started.

2. Since 0spinboson created sys-usb manually, rd.qubes.hide_all_usb should not be set. There's no reason why Qubes would block his USB keyboard from functioning at the LUKS password prompt, even if the controller was assigned to a domU. Correct?

I just tested this by rebooting my Qubes with USB keyboard attached to controller assigned to sys-usb. Keyboard worked fine entering LUKS password then ceased functioning once sys-usb was loaded. Plugging back into dom0 USB controller, keyboard worked again.

Rebooted a few times without sys-usb enabled/installed, so without USB devices being hidden from dom0. USB keyboard worked fine. Then enabled sys-usb, rebooted. Result: USB keyboard could no longer be used to enter the password.

Now I'm confused. Has this behavior changed from 3.1 to 3.2?

[entr0py]

1. I stand corrected - my apologies:

   if you enabled USB qube, it hides all the USB controllers from dom0, even before it gets started.

2. Since 0spinboson created sys-usb manually, rd.qubes.hide_all_usb should not be set. There's no reason why Qubes would block his USB keyboard from functioning at the LUKS password prompt, even if the controller was assigned to a domU. Correct?

I just tested this by rebooting my Qubes with USB keyboard attached to controller assigned to sys-usb. Keyboard worked fine entering LUKS password then ceased functioning once sys-usb was loaded. Plugging back into dom0 USB controller, keyboard worked again.

Rebooted a few times without sys-usb enabled/installed, so without USB devices being hidden from dom0. USB keyboard worked fine. Then enabled sys-usb, rebooted. Result: USB keyboard could no longer be used to enter the password.

Now I'm confused. Has this behavior changed from 3.1 to 3.2?

[0spinboson]

Note that I created it 'manually' using the same commands that I understand the setup uses, namely by entering "qubesctl top.enable qvm.sys-usb", then "qubesctl state.highstate".

As for the change in behavior: I guess so. :)

[0spinboson]

Note that I created it 'manually' using the same commands that I understand the setup uses, namely by entering "qubesctl top.enable qvm.sys-usb", then "qubesctl state.highstate".

As for the change in behavior: I guess so. :)

[entr0py]

That might account for the difference. I just created a new AppVM and passed the controller to it.

[entr0py]

That might account for the difference. I just created a new AppVM and passed the controller to it.

[0spinboson]

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

[0spinboson]

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

[marmarek]

Okay, that doesn't sound like I'll be able to work around it, esp. given that I have no clue how to edit the binary file xen.efi :)

Sorry, I meant xen.cfg.

[marmarek]

Okay, that doesn't sound like I'll be able to work around it, esp. given that I have no clue how to edit the binary file xen.efi :)

Sorry, I meant xen.cfg.

[andrewdavidwong]

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

My understanding is that this is correct. This is why @rootkovska recommends physically unplugging all (untrusted) USB devices when rebooting. Qubes isn't around to isolate USB controllers before it starts running.

[andrewdavidwong]

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

My understanding is that this is correct. This is why @rootkovska recommends physically unplugging all (untrusted) USB devices when rebooting. Qubes isn't around to isolate USB controllers before it starts running.

[entr0py]

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

Yes. My reasoning:

1. If my system is booting it's because I booted it. If it's booting without my knowledge, I've got far bigger problems than my USB controllers.
2. I have multiple USB controllers. sys-usb controller is empty before booting/shutdown. Keyboard is connected to a dom0 USB controller. If my keyboard firmware is malicious, it's far too late to save me.

Your point is valid though - especially as it relates to opportunities for user error. If I used my USB ports for anything more than infrequent file transfers, I would probably lock it all down. [Didn't realize that password entry would be disabled though. Thanks for heads up. I guess a laptop without ps/2 would have to boot another os and then edit the /boot partition?]

[entr0py]

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

Yes. My reasoning:

1. If my system is booting it's because I booted it. If it's booting without my knowledge, I've got far bigger problems than my USB controllers.
2. I have multiple USB controllers. sys-usb controller is empty before booting/shutdown. Keyboard is connected to a dom0 USB controller. If my keyboard firmware is malicious, it's far too late to save me.

Your point is valid though - especially as it relates to opportunities for user error. If I used my USB ports for anything more than infrequent file transfers, I would probably lock it all down. [Didn't realize that password entry would be disabled though. Thanks for heads up. I guess a laptop without ps/2 would have to boot another os and then edit the /boot partition?]

[Sen-Dion]

Is it possible to lock all USB controllers with an exception of the one in dom0 that handles USB keyboard (and mouse)?

[Sen-Dion]

Is it possible to lock all USB controllers with an exception of the one in dom0 that handles USB keyboard (and mouse)?

[InnovativeInventor]

A warning on the page would be nice to have on this part of the page
[here](https://www.qubes-os.org/doc/usb/#Creating and Using a USB qube)

How would I get keyboard access to Qubes again?

Edit: I figured it out (instructions are below for anyone who gets into the same circumstance that I got myself into)

First, I booted into a rescue system using a qubes installation drive.
Next, it required me editing /boot/efi/EFI/qubes/xen.cfg (note, not efi) and getting rid of rd.qubes.hide_all_usb to allow for my encryption password to be entered
Then, I deleted /var/lib/qubes/servicevms/sys-usb to get rid of the usb vm so I can actually use the Qubes operating system.

I hope this helps others.

[InnovativeInventor]

A warning on the page would be nice to have on this part of the page
[here](https://www.qubes-os.org/doc/usb/#Creating and Using a USB qube)

How would I get keyboard access to Qubes again?

Edit: I figured it out (instructions are below for anyone who gets into the same circumstance that I got myself into)

First, I booted into a rescue system using a qubes installation drive.
Next, it required me editing /boot/efi/EFI/qubes/xen.cfg (note, not efi) and getting rid of rd.qubes.hide_all_usb to allow for my encryption password to be entered
Then, I deleted /var/lib/qubes/servicevms/sys-usb to get rid of the usb vm so I can actually use the Qubes operating system.

I hope this helps others.

[InnovativeInventor]

I just created a pull request to amend the docs to have a nice warning up top. I think this will help prevent others from messing up.

[InnovativeInventor]

I just created a pull request to amend the docs to have a nice warning up top. I think this will help prevent others from messing up.

[marmarek]

Next, it required me editing /boot/efi/EFI/qubes/xen.cfg (note, not efi) and getting rid of rd.qubes.hide_all_usb to allow for my encryption password to be entered

This is for EFI. For non-efi, edit /boot/grub2/grub.cfg and /etc/default/grub (the former is generated from the latter, but you may not be able to launch the generator in rescue mode).

Then, I deleted /var/lib/qubes/servicevms/sys-usb to get rid of the usb vm so I can actually use the Qubes operating system.

This is very bad idea. If you want to remove sys-usb, do it properly from running system. You can use USB keyboard with sys-usb, it isn't enabled (and is prevented by installer by default) because it has security implications. See here: https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard

But if you are in a situation where you have sys-usb and the only keyboard you have is USB (and didn't followed above instruction), you can prevent its autostart by systemctl disable qubes-vm@sys-usb.service, or simply by removing /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service symlink.

[marmarek]

Next, it required me editing /boot/efi/EFI/qubes/xen.cfg (note, not efi) and getting rid of rd.qubes.hide_all_usb to allow for my encryption password to be entered

This is for EFI. For non-efi, edit /boot/grub2/grub.cfg and /etc/default/grub (the former is generated from the latter, but you may not be able to launch the generator in rescue mode).

Then, I deleted /var/lib/qubes/servicevms/sys-usb to get rid of the usb vm so I can actually use the Qubes operating system.

This is very bad idea. If you want to remove sys-usb, do it properly from running system. You can use USB keyboard with sys-usb, it isn't enabled (and is prevented by installer by default) because it has security implications. See here: https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard

But if you are in a situation where you have sys-usb and the only keyboard you have is USB (and didn't followed above instruction), you can prevent its autostart by systemctl disable qubes-vm@sys-usb.service, or simply by removing /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service symlink.

[marmarek]

See also https://www.qubes-os.org/doc/usb/#removing-a-usb-qube

[marmarek]

See also https://www.qubes-os.org/doc/usb/#removing-a-usb-qube

[homotopycolimit]

I find myself in the same situation. I could not enter my LUKS password after creating the USB vm in Qubes 4.0.

I booted into a rescue system and removed the rd.qubes.hide_all_usb from xen.cfg and rebooted.
I know get as far as the login screen where again the keyboard again does not work (even though the mouse does).

How do I get rid of the usb vm from within the rescue system. How can I undo whatever sudo qubesctl state.sls qvm.sys-usb did?

nvm - I found it (above) simply by removing /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service symlink.

[homotopycolimit]

I find myself in the same situation. I could not enter my LUKS password after creating the USB vm in Qubes 4.0.

I booted into a rescue system and removed the rd.qubes.hide_all_usb from xen.cfg and rebooted.
I know get as far as the login screen where again the keyboard again does not work (even though the mouse does).

How do I get rid of the usb vm from within the rescue system. How can I undo whatever sudo qubesctl state.sls qvm.sys-usb did?

nvm - I found it (above) simply by removing /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service symlink.