Storage and all is fine, I attach my sorage and I can mount and use it, even use the USB system to put it into a guest.
1: yes, the device is there under LSUSB
2: Yes, I can put a PCI-E car in and have the webcam atttached to that.
3: I don’t have any guest called sys-usb
4: I have no IOMMU groups.
qvm-usb produces nothing, even when a USB Drive is plugged in.
But the USB listing in the system tray has the USB drive with all partitions.
I can’t even see the bluetooth adaptor to pass through either.
All 3 devices are plugged into the same hub that is plugged into my monitor that is plugged into one USB port on the motherboard. (Just so you know that everything is connected and shuold be seen.
LSUSB shows all 3 devices.
1: MicrosoftCorp. LifeCam HD-3000
2: Realtek Semiconductor Corp. Bluetooth 5.3 Radio
3: Verbatim, Ltd Flash Drive
Well, mine isn’t that issue. I know where everything is attached to and it doesn’t change unless I want to pass something through.
And since the webcam nor the BT device appear in the USB listing, it makes it hard to do anything with them.
I have lost a large contract because I don’t have a usable webcam at the moment. But that is their loss.
I’m not new to Qubes, but I can’t even attach the devices to the guests using XL commands.
XL doesn’t even show me any USB devices, just keeps telling me it requires 1 argument, and if I give it that argument, it is empty, no devices returned
So I am quite confused as to why I have no access to anythign that I have plugged in from the CLI. And when things are seen by the system, why Qubes software won’t let me do anything with them…
I can attach any USB drive that I want.
If I make a USB Qube then that will destroy any semblance of security for the drives I have connected to Dom0.
If I do use a USB VM then that almost defeats the purpose of many things.
I already have the drives that I connect only to my storage VM, nothing else.
I have the drives that only get mounted in Dom0.
How can I keep and maintain my security as well as everything else?
I could just have every USB connected to the USB VM except whatever I plug into another specific HUB, but that would mean that the USB Qube would have to allow me to select what I decided to have connected to the USB Qube, but when the Guest is set up it takes over everything. I don’t get to select what actually gets connected to it, so that is one issue.
So I can attach drives to any guests after attaching them, I don’t have to put it anywhere else to the connect them to any guests.
So I don’t NEED a USB qube, I just need things to work correctly, the way things worked correctly in Qubes 1 and 2 and (early)3.
At least in those versions things worked a lot better.
Why do you need drives connected to dom0? You should not do anything in dom0, except managing VMs, otherwise you break the security approach of Qubes OS. More info: Device handling security | Qubes OS.
If you are really sure you want to do this, then you could try to take the advantage of the different USB controllers, if your hardware has it. You create a USB qube, add one USB controller to it, and connect to it devices which shouldn’t touch dom0. And use the other USB controller for devices connected to dom0.
Well, I have my backups for my guests.
That doesn’t get connected to anything except Dom0.
Connecting it to other guests would void any semblance of security for Domain-0 if I then connected it to Domain-0.
I also have other hardware and devices that get connected only to Domain-0.
Domain-0 doesn’t automatically do things to the drives either.
I have my drives connected to Domain-0 and I have no issues.
I have the drives mounted into another guest, and they are constantly being read which causes heat and reduces the lifespan and integrity of the drives. But I think that is just the downside of using MicroSoft SystemD.
Oh I do have multiple controllers, as I said in my previous post, I could do just that.
Please don’t try to sound smart by saying I could do what I already said I could do.
+1 for separating the USB controllers, so Dom0 only gets exposed to the safest, never connected anywhere else, devices. However, as @fsflover has said, you can only do this if your hardware has multiple USB bus controllers, which we do not know. I think you misunderstood that point. In fact, looking back, you previously suggested that a PCI card would be necessary to do it…
With a separate controller, you can attach the whole bus to a more full-featured appvm, where it can be handled by software which should not be used in Dom0. Maybe this would be helpful: https://github.com/QubesOS/qubes-video-companion
It would also make sure that there are no possible problems due to Dom0 taking over USB audio devices integrated into the webcam.
As I had said, I can do it. So I have already said so, and you are saying you don’t know, because I have not told you my hardware.
But I have said I can do it in that regard, but you just keep on about this stuff. Why keep harassing me about things trying to make yourself seem smart when I already said I can do certain things but telling me I should do certain things that I said I can do before you even mentioned them???
My Domain-0 can do plenty, it can pass the drives to other guests easily.
It should be able to pass any device, LIKE IT USED TO.
Because I don’t trust the guests, I trust Domain-0.
Domain-0 has no internet, and has my own security software in it, so I trust it.
Plugging hardware into an untrusted guest would just mean that there are going to be bigger issues. (in my opinion), because there is no separation of the USB devices, and the guests tend to scan the drives all the time.
This causes more issues than there needs to be.
If Qubes was to use a good linux distribution that is safer and more secure, as well as many other little things be changed, then Qubes as a whole would have less issues, be more trustable because would be more secure, and not have many of the issues that it does.
Are you sure you connect the right USB controllers to the sys-usb? Could you list them here?
This is correct. However you don’t have to connect them later to dom0 again. You could just continue use them for backups via sys-usb, as recommended by the official docs.
But the firmware on your drives could attack dom0, too.
I may have missed that indeed, but this forum is also for other users. I expect that someone else might benefit from my post, too.
03:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43bc (rev 02)
2a:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Zeppelin USB 3.0 xHCI Compliant Host Controller
These are the 2 main controllers that I moved across.
I had another USB card installed to enable a different USB subsystem for other things.
So I had another controller there last night, but I have that card out at the moment.
Connect them to sys-usb, have them be degraded at all times because the system continually looks at them and reads them… Smart.
They can recommend whatever they want, but I want security.
The firmware on them won’t attack Dom0. I read and scan the firmware before I use any drive.
Any action taken by the drive by me plugging it in is recorded and scanned before I use any drive.
Even when someone gives me a drive, I check the firmware before I do anything with it on any PC.
Even if I’m plugging it into a guest, I still get it checked first.
Someone may, but this is topic is about getting the webcam passed through to a guest.
Do you have any knowledge on how to set up the sys-usb guest so that it works please?
I can’t find anything that actually tells me how to, so that I can know where I’m going wrong.
I just added 2 of the 3 controllers.
Didn’t do it 1 by 1.
I didn’t get any errors as the machine literally just locked up solid.
After I get things backed up I’ll run the tests and go 1 by 1 in different orders for assigning the controllers.
then hope I can get the machine booted again if it does lock up like that.
But knowing how to create a sys-usb would be handy too.
I may have not done something that I should have done?
Or maybe I did something to the guest that I shouldn’t have?
In my understanding, hard crashes like these would only happen if you added a wrong device to sys-usb. The qube itself doesn’t need any changes (unless you want them or unless you use a minimal Template).
I don’t know then, because the only things that I"m adding are the USB controllers, which there are 3… two on the motherboard and one that is on the PCIE BUS.
Right now I’ve got drives in the PCIEx1 slot. so I can’t use the USB in there to get things checked for now. Have to get things backed up first.
I added my PCIE drive controller to a guest, and it added fine.
After that, the guest wouldn’t boot.
The device would not return to Dom0 even after the guest was killed.
After that…
shutdown PC took a bit longer than usual.
After PC shut down, had to do a full complete power cycle with flush to get it to power on again.
cycle flush included the following…
1: turn off power at PSU.
2: hold power button for 10 seconds to flush power.
3: power on PSU
4: try to power on.
5: press reset button.
6: Hold power button for 10 seconds then release.
7: Rapidly press power button for 3 seconds.
8: Hold power button in until motherboard lights come on.
Then the system turned on.
Then I had to remove the PCIE device from the guest.
Then I had to restart the machine again to get the controller back to Dom0 so I could use the drives.
This reset type thing I had to do the same thing when I tried to get the 2 USB controllers added in to the guest.
But it didn’t cause the whole machine to lock up and screen to go black and all. Adding the USB does though.
@Vael_S, you definitely are very savvy with Xen, Qubes OS, and computing in general, which is excellent. You definitely deserve respect for that, and I don’t think anyone doubts that.
@fsflover kind of has a point here. This forum, among other things, is intended to be an appendix of the official docs, filling in the gaps where the official docs are incomplete.
We all want to see you get your USB passthrough back, but because nobody is ever the only one who experiences a particular issue, we also want to make sure that other people who find themselves in a similar situation have everything “on a silver platter”, so to speak.
If the issue and solution/workaround is clean and well-presented enough, it makes it much more likely to be transferred over to become part of the official docs.
Yes, it actually does, and it does quite a lot more than you might think.
Give this a try:
In a dom0 terminal, type the following command:
sudo dmesg -W | grep -i USB
"Show the output of dmesg, but only show new entries containing the case-insensitive string ‘usb’ "
Plug in or unplug a USB device in dom0
Watch the output of dmesg
It might not mount them, but the kernel definitely interacts with the device as soon as it’s detected. That’s how it then shows up as a block device in the /dev directory.
The kernel interacts with it and tries to figure out what it is, and this is the attack vector that sys-usb is intended to mitigate.
(You probably already knew this, but including it for anyone else who sees this thread and might not)
This is extremely relevant to know. It tells us what’s going on behind the scenes when you boot your computer, and what firmware is and is not loaded, and more specifically, where the firmware is and is not loaded (inside which guest).
There are PCI devices that will exist on a single physical device, but present themselves as multiple PCI devices. AMD devices, like the ones in your machine, are notorious for this. These devices will often have firmware written by the manufacturer that will utilise all the PCI addresses registered by the physical device to “perform checks on each other” to “preserve system integrity” (according to their designers).
You get all sorts of weird combinations. The one that I’m currently experiencing issues/frustrations/rage-quits with is AMD Renoir iGPU and its built-in USB controllers in the Ryzen 7 4800U (causes a system crash just like what you’re experiencing, and I have to cold boot to recover).
This means that these physical devices have firmware that includes check to see that the “companion” PCI devices are present, reachable, and working as expected. If the firmware detects anything to the contrary, it assumes that a hardware fault exists, and freaks out.
I have AMD laptops with Vega RX8 iGPUs in them that, thanks to firmware updates by AMD, don’t seem to like being separated from the USB and Thunderbolt controllers, and will kill the display if they are separated.
The screen goes black, the screen backlight stays on, the fans spin up to full, and nothing else seems to recover it except a hard reboot.
In the past, sys-usb worked without any issues whatsoever on that hardware on the firmware at the time, which leads me to believe that some kind of check has been added in the latest firmware, throwing an error if that check fails.
So if you are encountering similar behaviour, then it’s possible that the AMD firmware is the culprit.
What can either of us do about this? Still working out a viable minimal-effort solution to this. I really don’t want to have to patch firmware every time linux-firmware is updated, but I also don’t want to run extremely outdated firmware in dom0, either…
Yeah, this definitely sounds like what I described above, unfortunately…
The creation of sys-usb in the standard First Run Wizard goes off a salt pillar in /srv/formulas.base/virtual-machines-formula/qvm/sys-usb.sls. Have a look at that pillar, and you’ll be pleasantly surprised to see that everything you’re concerned about is factored into its creation.
No network access, minimal template used, dispVM, does not provide network, minimal RAM. Devices aren’t “passed through” like PCI devices, but they’re proxied via qubes-usb-proxy, with all parsing done inside of sys-usb, meaning the guests never actually get hold of the USB device. It’s all there.
Damn, that’s thorough. Maximum respect, but where exactly do you execute these checks? Not in dom0, right…?
Assuming you don’t do it in dom0, you’ve got me genuinely curious about how you do this. Is there a piece of software or script you use that you could point us to?
Sounds like a cool little tool you’ve got
This is extremely relevant, because there are hardware devices that will present themselves as multiple PCI devices (and AMD hardware is particularly notorious about doing this). If the device performs more than one function, and you only pass through one of those functions, it generally does not like it, and will likely result in the other half of the device receiving mismatching information. This leads to the firmware believing something is faulty, causing a system crash.
When firmware includes these sorts of checks, and they fail, you will likely experience issues (or have in the past) when you wake up your computer from sleep. Maybe the display dies. Maybe the audio goes choppy. Maybe the USB controllers re-enumerate themselves in the wrong order, and get put into the wrong qubes.
I would have a look at your PCI devices and see if there are any other devices starting with 2a:00.X and see what they are, because chances are they’re likely part of the same physical device. And if you’re splitting them up, that might be what’s causing the system hang/crash…
@renehoj is right. You really should follow the instructions in that guide.
Read what it does first if you’re skeptical, or execute those steps manually with your desired modifications and/or omissions if you prefer.
If you’re going to do it manually, then you will need to:
Make sure you have the package qubes-usb-proxy installed in your USB qube
Make sure your dom0 policy files are set up appropriately to allow USB passthrough to the other qubes
Otherwise they won’t show up in the USB menu-thing in the dom0 XFCE system tray, because the request will keep getting denied by dom0.
But that is the way to get yourself a sys-usb qube as recommended by the Qubes Project.
Again, it’s up to you, but honestly, I would recommend letting SaltStack take care of your sys-usb creation (checking the steps it performs, if you wish, of course), and then modifying the end result if it’s not to your liking. It would likely be less of a headache.
You also ask SaltStack to undo sys-usb and restore everything to its previous state if you wish, too.
