libusb and QubesOS USB pass through don’t work together

[Demi M. Obenour]

I was trying to use adb with QubesOS’s USB passthrough, and I was
not able to get it to work.

According to a post on LKML, the USBIP driver (used by QubesOS
USB passthrough) and libusb are not meant to work together.
One alternative would be to use qemu in the stubdomain to present an
emulated PCI USB device, instead of requiring USBIP support in the
guest kernel. This would also allow USB passthrough to work to VMs
that do not support USBIP, or indeed even qrexec.

Right now, I plan on using adb in sys-usb itself, after blacklisting
drivers for USB devices not in use. There ought to be a better way.
IMO, sys-usb should *only* support USBIP, with the real protocol
handling done in other domains, and the resulting devices (be they
block devices or others) attached to yet other domains.

Sincerely,

Demi

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Nov 09, 2019 at 07:18:40PM -0500, Demi M. Obenour wrote:
> I was trying to use adb with QubesOS’s USB passthrough, and I was
> not able to get it to work.

- From what I remember from my experiments with adb and qvm-usb, USBIP
don't pass through device reset requests. And even when device is reset
externally, qvm-usb won't assign it back automatically. The later thing
may be actually a good thing, to prevent device suddenly changing its
identification - like you think you attach some harmless device, but it
switches to some exotic device with a known bug in its driver. But it
breaks this use case.

> According to a post on LKML, the USBIP driver (used by QubesOS
> USB passthrough) and libusb are not meant to work together.
> One alternative would be to use qemu in the stubdomain to present an
> emulated PCI USB device, instead of requiring USBIP support in the
> guest kernel. This would also allow USB passthrough to work to VMs
> that do not support USBIP, or indeed even qrexec.

This is interesting idea and indeed something we consider for non-Linux
VMs. It won't help you for PVH domains though, as there is no qemu
involved. Anyway, we'd be very welcome in a contributed patches in this
area.

> Right now, I plan on using adb in sys-usb itself, after blacklisting
> drivers for USB devices not in use. There ought to be a better way.
> IMO, sys-usb should *only* support USBIP, with the real protocol
> handling done in other domains, and the resulting devices (be they
> block devices or others) attached to yet other domains.

Given performance and complexity of USB vs block protocols, IMO handling
mass-storage directly in sys-usb and connecting it further as block
device is a better idea. But otherwise I agree.

Also, disposable sys-usb is a good idea when you use more complex
devices directly in sys-usb:
https://www.qubes-os.org/doc/disposablevm-customization/#using-static-disposablevms-for-sys-

Using intermediate DisposableVM for "unpacking" USB protocol to
something simpler would work in a principle, but has two major usability
issues:
- DisposableVM (or more specifically: Linux VM) takes some precious
memory
- USBIP is slow

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3HXZQACgkQ24/THMrX
1ywBvQgAleE2CF2y/kBtt604DTGxhHAhJ6UMJLaB4G7g7YaFsk/0fBTXlVY05M5t
5hw/Re3WUxyWq0BVZ6Vio4Yw6AiSiULDDjsB2dU++eitom7XfIVaUagI1STzzPR+
mzASfdzfyBwO7k7TwcAYhFI1/E/n9BxDyVRjcPAhAbQtQSvYimmrhiW0OdpkNn7+
L3tvWlLWhQzYAjCsobERm4OelT6u0xhXPzaV7R/kGN1DG5ABmnkLfWZaicvFVw5T
tmfE9FM8ry7zOTIN7WX+R9n0cny0UqYBVY68Bj1kY+eXEl8/cqpDSUnrN0CGOb7Y
u2Dre8SjnwknZolJ9qJWbI2LTr39nw==
=EbQp
-----END PGP SIGNATURE-----

[Demi M. Obenour]

On 2019-11-09 19:45, Marek Marczykowski-Górecki wrote:
> On Sat, Nov 09, 2019 at 07:18:40PM -0500, Demi M. Obenour wrote:
>> I was trying to use adb with QubesOS’s USB passthrough, and I was
>> not able to get it to work.
>

> From what I remember from my experiments with adb and qvm-usb, USBIP
> don't pass through device reset requests. And even when device is reset
> externally, qvm-usb won't assign it back automatically. The later thing
> may be actually a good thing, to prevent device suddenly changing its
> identification - like you think you attach some harmless device, but it
> switches to some exotic device with a known bug in its driver. But it
> breaks this use case.
>
>> According to a post on LKML, the USBIP driver (used by QubesOS
>> USB passthrough) and libusb are not meant to work together.
>> One alternative would be to use qemu in the stubdomain to present an
>> emulated PCI USB device, instead of requiring USBIP support in the
>> guest kernel. This would also allow USB passthrough to work to VMs
>> that do not support USBIP, or indeed even qrexec.
>
> This is interesting idea and indeed something we consider for non-Linux
> VMs. It won't help you for PVH domains though, as there is no qemu
> involved. Anyway, we'd be very welcome in a contributed patches in this
> area.

I would love to send them, but right now I am rather short on time.
I still have the socket-based qrexec patch to finish first.

>
>> Right now, I plan on using adb in sys-usb itself, after blacklisting
>> drivers for USB devices not in use. There ought to be a better way.
>> IMO, sys-usb should *only* support USBIP, with the real protocol
>> handling done in other domains, and the resulting devices (be they
>> block devices or others) attached to yet other domains.
>
> Given performance and complexity of USB vs block protocols, IMO handling
> mass-storage directly in sys-usb and connecting it further as block
> device is a better idea. But otherwise I agree.
>
> Also, disposable sys-usb is a good idea when you use more complex
> devices directly in sys-usb:
> https://www.qubes-os.org/doc/disposablevm-customization/#using-static-disposablevms-for-sys-
>
> Using intermediate DisposableVM for "unpacking" USB protocol to
> something simpler would work in a principle, but has two major usability
> issues:
> - DisposableVM (or more specifically: Linux VM) takes some precious
> memory
> - USBIP is slow

That is a very good point. Both would be averted if we ran on a
microkernel, such as seL4, and had drivers that ran directly on the
microkernel. Alas, we are stuck with Xen and Linux for the time being.

Sincerely,

Demi

[Fidel Ramos]

FWIW I have a working AppVM for using adb. It uses Debian 10 as template, I have it with no networking and only for connecting the phone through adb, copy files and do backups.

Interestingly the adb server fails to start the first time, but it works on second try. Then I'm able to copy files (which fail for me through MTP on other VMs), adb shell and everything I have tried.

I'm on regular QubesOS 4.0 with kernel 4.19.80-1.pvops.qubes.x86_64 on a Librem 13v2 laptop.

Fidel Ramos
PGP 7F07 1B7C 479F EDD1
https://fidelramos.net

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Sunday, November 10, 2019 12:18 AM, Demi M. Obenour <demio...@gmail.com> wrote:

> I was trying to use adb with QubesOS’s USB passthrough, and I was
> not able to get it to work.
>
> According to a post on LKML, the USBIP driver (used by QubesOS
> USB passthrough) and libusb are not meant to work together.
> One alternative would be to use qemu in the stubdomain to present an
> emulated PCI USB device, instead of requiring USBIP support in the
> guest kernel. This would also allow USB passthrough to work to VMs
> that do not support USBIP, or indeed even qrexec.
>
> Right now, I plan on using adb in sys-usb itself, after blacklisting
> drivers for USB devices not in use. There ought to be a better way.

> IMO, sys-usb should only support USBIP, with the real protocol

> handling done in other domains, and the resulting devices (be they
> block devices or others) attached to yet other domains.
>
> Sincerely,
>
> Demi
>

> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/356ba859-0456-38a0-631c-77266e3865f0%40gmail.com.