I’ve followed USB qubes | Qubes OS and I always achieve the same results: no keyboard in LUKS, and getting through that with a PS/2 keyboard I can reach xfce. The only strange thing I notice is that I’ve 2 BDFs when using readlink: basically it’s like I didn’t whitelist the controller with my input devices. Ask me if more information is needed.
What is relevant lspci, what are BDFs, and how do they map to the
ports you have?
Bus 003 has my mice and kb, and the controller is a PCI-e card. (I’d assume the VIA Labs one).
The others are in reality one controller (probably related to my bios settings), they are all the rear/front ports.
(Sorry for the screenshot, I need USB for internet.)
Okay so I revisited this today: my USB keyboard doesn’t work after I set the required GRUB options and reboot, so the sys-usb qube isn’t even created yet.
Interestingly, my mice works: no matter the USB controller I plug it into.
Also, lsusb shows that no controller is hidden yet.
(I assume that my kb should work, as the docs don’t mention me needing a PS/2 keyboard.)
So far, I’ve used 00:1c.0 but I noticed that this is my PCI bridge in lspci, so I changed it to 02:00.0 but that didn’t change anything.
Trying 00:14.0 (my internal USB controller) solved nothing, thus I don’t think it would be a driver issue/anything with the board. (Brand new, and it claims it’s “driverless” for Linux)
I went ahead and ran sudo qubesctl state.sls qvm.sys-usb and added policies as needed (to allow kb and mice into dom0). Now as usual, I’ve no mice nor kb from USB in LUKS and Xfce. Interestingly, if I don’t add the policies then I can atleast allow my mice to work (pop-up), while the keyboard gets denied all the time (constant notifications).
Manually attaching with qvm-usb gives no output in the terminal, and nothing happens.
If I open XTerm in sys-usb, I can use the USB keyboard there.
I needed no-strict-reset on the internal USB controller, now I’ve a running sys-usb and a working mice. My USB keyboard is still not usable anywhere.
Yet they both appear in dom0 lsusb.
If I remove the added boot options, then it seems that attaching my internal usb controller to sys-usb is enough: and I can use my keyboard too. Is this insecure? dom0 apparently can still only see my usb controller card. (Obviously I do get a warning about USB not being restricted in dom0)
The only option I can leave in is the rd.qubes.dom0_usb=02:00.0 as the other 2 (in combination, or even just individually) cause the aforementioned problems. (To be precise, a working mice in dom0 and sys-usb, while keyboard is not working even though according to dom0’s lsusb it is directly attached.)
I cant help you without text.
Understandable, fortunately I gained internet access on the machine:
lspci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 07)
00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 (rev 31)
00:16.3 Serial controller: Intel Corporation 100 Series/C230 Series Chipset Family KT Redirection (rev 31)
00:17.0 SATA controller: Intel Corporation Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #5 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Q150 Chipset LPC/eSPI Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller (rev 31)
00:1f.3 Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V (rev 31)
01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 630 Rev. 2] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1)
02:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01)
Internal USB Controller’s (for “untrusted” devices) BDF: 00:14.0 (rear+front)
PCI-e USB Controller’s (for direct dom0 access, input devices) BDF: 02:00.0 (rear)
lsusb (in dom0):
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 0951:16b7 Kingston Technology
Bus 003 Device 003: ID 145f:01f1 Trust USB2.0 Hub
Bus 003 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Keyboard: Bus 3, Device 4
Mice: Bus 3, Device 3
To reiterate my steps:
- USB qubes | Qubes OS
- I explicitly (in the GUI) attached my internal USB Controller to
sys-usb
=> working mice,sys-usb, no keyboard at LUKS/Xfce (even though it appears inlsusb, and in theory my PCI-e USB Controller should be attached todom0and the internal one tosys-usb) - I removed the boot options so now everything works (even the internal USB controller is hidden to dom0), but I sense that this isn’t secure.
I’ve not specified my reboots exactly
And this doesn’t help either?
The guide I followed references this part too, and I should’ve done everything there. (And the attach/detach part works in itself. The only problem is the isolation at boot, as at the moment every usb controller is on dom0 while typing the LUKS password.)