Cannot assign USB radio peripheral with qvm-usb

[p.o.m...@gmail.com]

Hello,

I am running Qubes 3.2, with a Fedora 25 sys-usb. I have a HackRF One SDR that I am trying to attach to an appvm, with no luck.

When I run qvm-usb in dom0 to attach the USB device the command hangs and there is the following in the appvm's dmesg output:

[ 490.254687] vhci_hcd vhci_hcd: pdev(0) rhport(0) sockfd(0)
[ 490.254701] vhci_hcd vhci_hcd: devid(131091) speed(3) speed_str(high-speed)
[ 490.463076] usb 2-1: new high-speed USB device number 93 using vhci_hcd
[ 490.674105] usb 2-1: new high-speed USB device number 94 using vhci_hcd
[ 490.885282] usb 2-1: new high-speed USB device number 95 using vhci_hcd
[ 490.885332] usb 2-1: SetAddress Request (95) to port 0
[ 490.900735] usb 2-1: device descriptor read/8, error -71
[ 491.022552] usb 2-1: device descriptor read/8, error -71
[ 492.007163] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 492.007176] usb usb2-port1: unable to enumerate USB device
[ 492.991256] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 493.879245] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?

The last message continues for some time before vhci_hcd gives up and disconnects the device. qvm-usb in dom0 never returns.

The SDR works just fine if I use it from sys-usb directly, so the problem appears limited to how Qubes handles USB forwarding.

Can anyone help with this error?

I suspect not many people have an SDR to test. I am willing to help debug this but I will need help knowing what to do.

Thanks,
- Paul

[awokd]

On Sun, December 3, 2017 10:26 pm, p.o.m...@gmail.com wrote:

> I am running Qubes 3.2, with a Fedora 25 sys-usb. I have a HackRF One
SDR that I am trying to attach to an appvm, with no luck.
>
> When I run qvm-usb in dom0 to attach the USB device the command hangs
and there is the following in the appvm's dmesg output:

Can't help with that specific issue but as a workaround you can assign one
of your USB controllers directly to the AppVM. Look under "Finding the
right USB controller" in here
https://www.qubes-os.org/doc/assigning-devices/ .

[p.o.m...@gmail.com]

On Monday, December 4, 2017 at 8:39:48 AM UTC-5, awokd wrote:
> Can't help with that specific issue but as a workaround you can assign one
> of your USB controllers directly to the AppVM. Look under "Finding the
> right USB controller" in here
> https://www.qubes-os.org/doc/assigning-devices/ .

Would love to, but there is only one USB controller on this laptop. It kinda defeats the purpose to reassign the whole thing.

[N.]

Hi Paul,

Did you found a better solution? I'm basically having the same problem right now.

-N

[Yuraeitha]

On Tuesday, December 5, 2017 at 12:31:29 AM UTC+1, Paul Mosier wrote:

qvm-usb isn't perfect 1:1 USB translation, so some kinds of device standards and devices types, may not work. For example I've tried getting a Yubi key to work on it recently, and it did not work. Many (all I tested) USB thumb drives, external drives, USB keyboards, USB mouses, and what else of these common devices, seems to work smooth with qvm-usb, without fail and appears reliable. However more exotic devices, such as your USB device, or other exotic devices such as Yubi key, seems not to work with the current state of qvm-usb.

I'm aware it's not a beautiful or flexible fix to pass an USB controller directly to a VM. But it may end up being the only viable solution, so it's not out of the question to discuss it early too before reaching a conclusion on getting the qvm-usb to work properly, especially considering direct USB pass-through is easy, assuming hardware support is sufficient.

Does your USB controller support PCI reset? If it does, then you won't have to do a full system restart (or bypass security with a few commands (not recommended practice) to switch the USB controller from one AppVM to another.

Limitations to consider:
- Can only run one VM with the controller at any one time.
- The need to restart the VM in order to get USB on an already running VM.
- Lacking PCI reset makes it a whole lot more troublesome and cumber-stone.
- Must be in HVM or PV "qvm-prefs src-vm virt_mode" to work, PVH won't work.

If you have USB PCI reset support, then only having one USB controller might not be so bad as it seems. However, it still isn't as nice as using qvm-usb. PCI reset sensitivity can also be adjusted so that it won't reject PCI cards without PCI reset support, however, it's adding one extra attack vector to your system through USB attacks.

You could write a small script to turn off sys-usb (assuming no VMs are tied to it, i.e. for USB tethering internet purposes), which then starts your VM that requires your exotic USB device, and keep using sys-usb for common devices.

For example, write a very simple but effective script like this;

qvm-shutdown sys-usb
wait
qvm-start AppVM (the one with exotic USB).
wait

Have another script which reverses it, by shutting down your exotic USB AppVM, and restarts your sys-usb VM. You can put a XFCE4 Launcher (or use Whisker menu's) which both are pre-installed Qubes 4 plugin (Qubes 3.2. only has the Launcher pre-installed). Pick a random icon to add to either the launcher or the whisker menu, and right click on the launcher itself (or the icon in whisker menu), and click properties for launcher or edit icon for Whisker menu.

From here, both are really similar. It doesn't matter which icon you use, as long it's an icon you dont plan on using. Whisker menu will replace the icon you change, however Launcher is more powerful because it doesn't actually affect the original icon by the changes you make to any icons inside the Launcher configurations.

So if using Launcher (which you can add multiple of, and with the right icons, youcan make it look really stylish too, like the kind of stylish look Apple dock has (I do by no means like Apple products, though one should be objective fair to the aspects they did well). This is quickly and easily done without even installing anything on Qubes.

So, now you can add any scripts or any commands you like, to the launcher, change the icons and names, organize it in whatever way you like, there is litterelly no limit.

In there, you can put a launcher for special scripts, such as the one switching between sys-usb and AppVM-(with-exotic-USB-use-cases).

Essentially by making such a script, you can not only easily make an icon out of it, you can also easily keybind the script too, as well as backup the script for future re-installs of Qubes (be sure to audit the script before moving it out/in of dom0 for security reasons).

This is a potential way you can work around the issue, it's not all round fix, but it may be practical enough, depending on your needs.

[Yuraeitha]

On Tuesday, December 5, 2017 at 12:31:29 AM UTC+1, Paul Mosier wrote:

Apologies, I used "icon" and "shortcut" interchangeably, mixing the use-cases together, making it hard to tell when I speak of one or the other. In order not to misunderstand what I said, please be mindful of this mistake when reading my post.

[p.o.m...@gmail.com]

Hi N,

I did not find a better solution. I run the radio peripheral from sys-usb directly and moved any software for it to that VM.

Yuraeitha, my USB controller does not support PCI reset, so your ideas do not help me. If sys-usb goes down the only way to get any USB functionality is to reboot the system. And as this is a somewhat RAM-limited laptop, switching the USB controller to any other VM doesn't always work, as sys-usb doesn't always come up at boot (due to memory access issues).

Incidentally, the Yubikey I have works just fine with qvm-usb. I didn't have to do anything unusual for that at all.

- Paul

[Yuraeitha]

Alright, so PCI reset is not supported. However, you haven't answered the full question in regard to the PCI reset, did you look at the feature to disable the PCI reset requirements? It's in the link awokd posted up above. As well as the method to make PCI more permissive too.

You loose a bit security from local USB attacks, however, the question then becomes what you value more, as well as your threat profile, and if you ever leave your laptop/desktop alone/exposed to people you can't trust.

Essentially, you may very well have the opportunity to remove the PCI reset requirement and add permissive mode to your USB, without loosing too much security, given if your environment is favorable (low attack risks on your machine).

If you do that, then you won't need to restart the full machine every time you switch the controller, and sys-usb should work at every boot as well.

Have you tried or thought about this? If this is no good, then direct USB attachment becomes a big hassle indeed.

Interesting that you got the Yubi key to work with qvm-usb btw, I might have a second look at it again. It could be that I us Qubes 4 though? *shrug* I'll have to see what happens.

[p.o.m...@gmail.com]

Hi Yuraeitha,

Yes, I have looked to see if PCI reset could be changed. I have had no luck.

I am aware of the security implications of running things in sys-usb. For the time being I accept the risks, though I will be looking a little closer at the hardware of my next laptop!

[Yuraeitha]

ah, that's too bad, it sucks when having bought hardware with such minor but hugely impacting limitations. If the hardware developers only had more incentive to increase quality on the market... It's frustrating that so few market proper information & specifications, and so so few reviews, focus on things like USB capabilities. Like how many controllers there is etc. can be dodgy to learn about on a laptop... One would think that given all the virtualisation that people get into (not just Qubes, but in general), that information about controllers and even PCI reset would be more available, and even be good selling points.

Either way, I wish you good luck in your hunt, may you find a proper pray in the jungle.