PV USB

[marmarek]

Reported by marmarek on 17 Apr 2012 12:59 UTC
PV USB with Linux 3.x works fine, but needs some work to integrate with Qubes:

1. xen-usbfront and xen-usbback drivers (patch from xen-devel with some minor modification works ok). It is ready on my devel machine.
2. Add support for PV USB to libxl (or stay with standalone python scripts).
   2a. This includes some script in backend VM (in some/most cases not dom0) that bind USB device to usbback driver - /usr/lib/qubes/unbind_pci_device.sh equivalent.
3. Add Qubes tool to manage USB devices (qvm-block equivalent).

Migrated-From: https://wiki.qubes-os.org/ticket/531

[marmarek]

Modified by marmarek on 17 Apr 2012 12:59 UTC

[marmarek]

Modified by marmarek on 17 Apr 2012 12:59 UTC

[marmarek]

Comment by marmarek on 3 Oct 2012 23:25 UTC
Some related info: https://groups.google.com/group/qubes-devel/browse_thread/thread/e002ae940061d897

[marmarek]

Comment by marmarek on 3 Oct 2012 23:25 UTC
Some related info: https://groups.google.com/group/qubes-devel/browse_thread/thread/e002ae940061d897

[marmarek]

Modified by joanna on 8 Oct 2012 09:31 UTC

[marmarek]

Modified by joanna on 8 Oct 2012 09:31 UTC

[marmarek]

Comment by marmarek on 8 Nov 2012 03:00 UTC
qvm-usb code done by Alexandre Bezroutchko merged into master branch.
Kernel frontend/backend drivers are still unstable, but this isn't the scope of this ticket.

[marmarek]

Comment by marmarek on 8 Nov 2012 03:00 UTC
qvm-usb code done by Alexandre Bezroutchko merged into master branch.
Kernel frontend/backend drivers are still unstable, but this isn't the scope of this ticket.

[marmarek]

Comment by joanna on 8 Feb 2013 12:53 UTC
We're still waiting for a working pvusb backend...

[marmarek]

Comment by joanna on 8 Feb 2013 12:53 UTC
We're still waiting for a working pvusb backend...

[marmarek]

Modified by joanna on 8 Feb 2013 13:03 UTC

[marmarek]

Modified by joanna on 8 Feb 2013 13:03 UTC

[marmarek]

Modified by joanna on 1 Aug 2013 11:56 UTC

[marmarek]

Modified by joanna on 1 Aug 2013 11:56 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:07 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:07 UTC

[marmarek]

Modified by marmarek on 20 Apr 2014 17:25 UTC

[marmarek]

Modified by marmarek on 20 Apr 2014 17:25 UTC

[marmarek]

Comment by marmarek on 24 Oct 2014 12:01 UTC
USBIP in 3.17 kernel (uploaded to unstable repo) is moved out of "staging" tree. Its architecture/interface looks good in terms of usability in Qubes: network connection is established in userspace, then single file descriptor (socket) is passed to the kernel.
Based on that, I've managed to run it over qrexec (minor change in qrexec was required - to use sockets instead of pipes). Tested on USB stick and webcam - looks pretty good. Test on internal bluetooth adapter failed (oops in backend), but also had problems with this device without USBIP in the middle. All with UsbVM of course.

Some remaining problems:

1. Performance - in R2 qrexec is pretty slow, also produces a lot of CPU usage in dom0. Hopefully will work much better in R3. But still, even in R2 it was enough for webcam.
2. Connection workflow - VM-VM qrexec services are normally initiated by one VM to another. In qvm-usb we'd like to dom0 arrange the VM-VM connection. In R2 it is rather simple to work around, as the connection always goes through dom0, but in R3 it will be somehow more tricky - but still doable of course. Or perhaps we should implement it without qrexec, just plain vchan?

[marmarek]

Comment by marmarek on 24 Oct 2014 12:01 UTC
USBIP in 3.17 kernel (uploaded to unstable repo) is moved out of "staging" tree. Its architecture/interface looks good in terms of usability in Qubes: network connection is established in userspace, then single file descriptor (socket) is passed to the kernel.
Based on that, I've managed to run it over qrexec (minor change in qrexec was required - to use sockets instead of pipes). Tested on USB stick and webcam - looks pretty good. Test on internal bluetooth adapter failed (oops in backend), but also had problems with this device without USBIP in the middle. All with UsbVM of course.

Some remaining problems:

1. Performance - in R2 qrexec is pretty slow, also produces a lot of CPU usage in dom0. Hopefully will work much better in R3. But still, even in R2 it was enough for webcam.
2. Connection workflow - VM-VM qrexec services are normally initiated by one VM to another. In qvm-usb we'd like to dom0 arrange the VM-VM connection. In R2 it is rather simple to work around, as the connection always goes through dom0, but in R3 it will be somehow more tricky - but still doable of course. Or perhaps we should implement it without qrexec, just plain vchan?

[adrelanos]

Can you please elaborate on the usability impact of PV USB? So once we have the USB VM and PV USB... Does it mean, that even if USB printer, USB input devices, USB phone connection, etc. are all connected to same internal USB controllers, that Qubes could selectively assign arbitrary devices to different VMs? The VMs would not have access to the real USB stack, but only a virtualized one?

[adrelanos]

Can you please elaborate on the usability impact of PV USB? So once we have the USB VM and PV USB... Does it mean, that even if USB printer, USB input devices, USB phone connection, etc. are all connected to same internal USB controllers, that Qubes could selectively assign arbitrary devices to different VMs? The VMs would not have access to the real USB stack, but only a virtualized one?

[marmarek]

Yes, exactly. Of course still compromised USB VM could provide malicious
device to the target VM (instead of genuine one) and sniff all the
communication, but this would be much better than having full USB stack
in target VM (or even dom0).

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?

[marmarek]

Yes, exactly. Of course still compromised USB VM could provide malicious
device to the target VM (instead of genuine one) and sniff all the
communication, but this would be much better than having full USB stack
in target VM (or even dom0).

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?

[marmarek]

Generally there are multiple implementations possible here:

1. Xen-specific PV USB drivers - project was dormant for a long time, but recently got some attention. Initially it was based on USBIP kernel driver. But currently backend driver is considered as part of qemu - haven't checked if that would work with driver domains (i.e. USB controllers in some USB VM instead of dom0).
2. USBIP - not Xen specific and since Linux ~3.19 moved out of "staging" tree to normal driver. This driver uses userspace tools for TCP communication and then pass socket FD to the kernel - it is possible to use qrexec socket instead of TCP.
3. OpenXT drivers - Windows frontend and Linux backend. Linux frontend is work in progress.

USBIP seems to be the easiest and the most mature implementation, available in mainline Linux. I have some work in progress scripts for setting it up ("the backend part"). Will push it somehow this week. Probably needs help on frontend part (updating qvm-usb tool, adding Qubes Manager options etc).

cc @caschulz88

[marmarek]

Generally there are multiple implementations possible here:

1. Xen-specific PV USB drivers - project was dormant for a long time, but recently got some attention. Initially it was based on USBIP kernel driver. But currently backend driver is considered as part of qemu - haven't checked if that would work with driver domains (i.e. USB controllers in some USB VM instead of dom0).
2. USBIP - not Xen specific and since Linux ~3.19 moved out of "staging" tree to normal driver. This driver uses userspace tools for TCP communication and then pass socket FD to the kernel - it is possible to use qrexec socket instead of TCP.
3. OpenXT drivers - Windows frontend and Linux backend. Linux frontend is work in progress.

USBIP seems to be the easiest and the most mature implementation, available in mainline Linux. I have some work in progress scripts for setting it up ("the backend part"). Will push it somehow this week. Probably needs help on frontend part (updating qvm-usb tool, adding Qubes Manager options etc).

cc @caschulz88

[caschulz88]

Hey, thanks for posting the possible implementation options here. For me also USBIP sounds the best way to go for an implementation. I'm looking forward to grab your code and work with it. Of course I'm also willing to support you and help on working on the backend and frontend part.

Please let me know as soon as it's online somewhere.

[caschulz88]

Hey, thanks for posting the possible implementation options here. For me also USBIP sounds the best way to go for an implementation. I'm looking forward to grab your code and work with it. Of course I'm also willing to support you and help on working on the backend and frontend part.

Please let me know as soon as it's online somewhere.

[marmarek]

Here: https://github.com/QubesOS/qubes-app-linux-usb-proxy
It requires: #1876 (both dom0 and VM parts)
You can workaround that by editing /etc/qubes-rpc/qubes.USB in backend doman and hardcoding some device there (just for testing).

[marmarek]

Here: https://github.com/QubesOS/qubes-app-linux-usb-proxy
It requires: #1876 (both dom0 and VM parts)
You can workaround that by editing /etc/qubes-rpc/qubes.USB in backend doman and hardcoding some device there (just for testing).