usbvm fails (succeeds?) with error

[mfc]

Upon running usbvm (based on fedora template) with all USB and sdcard devices contained within it, I receive the following error in Qubes VM Manager:

Error starting VM: internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available.

It successfully isolates the devices from the other vms, but the usbvm itself is not running (instead has the yellow ! sign), so there is no way to interact with any USBs or SDcards if they are attached to the computer.

Q3.0rc2

[unman]

@mfc
It's a feature, not a bug. :-)
Look here - https://groups.google.com/forum/#!msg/qubes-users/lBBdiKz0D4w/4cYVbsDXtcQJ
For the moment you have to remove that device from the usbvm to have it boot.

[unman]

@mfc
It's a feature, not a bug. :-)
Look here - https://groups.google.com/forum/#!msg/qubes-users/lBBdiKz0D4w/4cYVbsDXtcQJ
For the moment you have to remove that device from the usbvm to have it boot.

[mfc]

removing the device from the usbvm doesn't enable it to be used again, nor does deleting the usbvm. I have to reboot in order to use USB devices.

According to that Google Group thread, It sounds like the "solution" is to disable USB3.0 in BIOS, is this correct?

[mfc]

removing the device from the usbvm doesn't enable it to be used again, nor does deleting the usbvm. I have to reboot in order to use USB devices.

According to that Google Group thread, It sounds like the "solution" is to disable USB3.0 in BIOS, is this correct?

[unman]

@mfc
Again this is an intended feature: it's in the FAQ.

I thought that you had a number of devices and the error was triggered by one of them. My apologies.
Yes, some people have a problem with USB 3.0: they have successfully disabled 3.0 in the BIOS, and then been able to attach the device to usbVM, but only some boards support this. YMMV
If you cant do this then your only option is to attach any other controllers that you can to the usbVM, and not use the offenders. lspci should help you to identify controllers that might work.
If ALL of your controllers are 3.0, and you cant disable in the BIOS then for the moment you're stuck. You'll have to wait for Marek's workround to surface. When he's back he may respond to that thread.

[unman]

@mfc
Again this is an intended feature: it's in the FAQ.

I thought that you had a number of devices and the error was triggered by one of them. My apologies.
Yes, some people have a problem with USB 3.0: they have successfully disabled 3.0 in the BIOS, and then been able to attach the device to usbVM, but only some boards support this. YMMV
If you cant do this then your only option is to attach any other controllers that you can to the usbVM, and not use the offenders. lspci should help you to identify controllers that might work.
If ALL of your controllers are 3.0, and you cant disable in the BIOS then for the moment you're stuck. You'll have to wait for Marek's workround to surface. When he's back he may respond to that thread.

[mfc]

Okay thanks for the further details. To be clear I am highlighting the UX issues in the current implementation.

I think it is the case you highlighted, that I have multiple devices and the error is triggered by one of them (probably the USB 3.0 port). But from a security perspective it doesn't make sense to only have some USB controllers going into the usbvm. The expectation should be that users will want all of their USB, sdcard, etc ports going into dedicated VMs. And that shouldn't throw up errors to the user, and they should still be able to use those ports, directed to those VMs.

expected UX:

1. usbvm (or usbvm and sdcardvm) created on installation, enabled on startup
2. plugging in USBs, sdcards, etc successfully are routed to these VMs.
3. usb controllers can be assigned away from usbvm to an appvm without having to delete the usbvm or reboot (shutting down the usbvm should be sufficient)
4. usb controllers can be returned to usbvm, without having to create new usbvm, rebooting, etc

No weird errors, no non-running VMs with yellow exclamation marks, no non-functional USB ports until reboot, etc.

[mfc]

Okay thanks for the further details. To be clear I am highlighting the UX issues in the current implementation.

I think it is the case you highlighted, that I have multiple devices and the error is triggered by one of them (probably the USB 3.0 port). But from a security perspective it doesn't make sense to only have some USB controllers going into the usbvm. The expectation should be that users will want all of their USB, sdcard, etc ports going into dedicated VMs. And that shouldn't throw up errors to the user, and they should still be able to use those ports, directed to those VMs.

expected UX:

1. usbvm (or usbvm and sdcardvm) created on installation, enabled on startup
2. plugging in USBs, sdcards, etc successfully are routed to these VMs.
3. usb controllers can be assigned away from usbvm to an appvm without having to delete the usbvm or reboot (shutting down the usbvm should be sufficient)
4. usb controllers can be returned to usbvm, without having to create new usbvm, rebooting, etc

No weird errors, no non-running VMs with yellow exclamation marks, no non-functional USB ports until reboot, etc.

[unman]

I don't think the problems with the current implementation are qubes problems though, they are down to faulty hardware. You see the same weird errors arising in the windows world with some USB 3.0 controllers. From a security perspective it doesn't make sense to use unsafe devices.

Perhaps the error handling could be better, and a message identifying the faulty device should be shown, (I mean a clearer message than the current one), and the usbVM closed for reconfiguration. That might help somewhat.

I don't agree with your expected UX though, specifically steps 3 and 4. I don't see a virtue in switching controllers between VMs, and I think the model of having a specific VM to handle usb is a good one that should be promoted.
Yes, it's a change to the way that people use their machines, but the qubes model is a huge change in any case. Having a safe usbVM (or two) to which you can attach any device and not risk compromising your secure VMs is a benefit that justifies learning a different way of working.

[unman]

I don't think the problems with the current implementation are qubes problems though, they are down to faulty hardware. You see the same weird errors arising in the windows world with some USB 3.0 controllers. From a security perspective it doesn't make sense to use unsafe devices.

Perhaps the error handling could be better, and a message identifying the faulty device should be shown, (I mean a clearer message than the current one), and the usbVM closed for reconfiguration. That might help somewhat.

I don't agree with your expected UX though, specifically steps 3 and 4. I don't see a virtue in switching controllers between VMs, and I think the model of having a specific VM to handle usb is a good one that should be promoted.
Yes, it's a change to the way that people use their machines, but the qubes model is a huge change in any case. Having a safe usbVM (or two) to which you can attach any device and not risk compromising your secure VMs is a benefit that justifies learning a different way of working.