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 todom0
and 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.)