linux-kernel - Re: usbip doesn't work with userspace code that accesses USB devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a95c7e71-a720-49ba-b503-6f20a86be38e@rowland.harvard.edu>
Date: Mon, 4 Mar 2024 22:19:24 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Marek Marczykowski-Górecki <marmarek@...isiblethingslab.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
  Demi Marie Obenour <demi@...isiblethingslab.com>, linux-usb@...r.kernel.org,
  Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: usbip doesn't work with userspace code that accesses USB devices

On Tue, Mar 05, 2024 at 12:52:22AM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 04, 2024 at 11:46:04PM +0100, Marek Marczykowski-Górecki wrote:
> > Terminology:
> > 1. sys-usb - a VM where USB controller (a PCI device) lives; here
> > usbip-host is attached to the device
> > 2. testvm - target VM where usbip is connected; here vhci-hcd is used
> > 3. qvm-usb - tool that connects the above two (equivalent of
> > userspace part of standard usbip)
> > 
> > Specific steps:
> > 1. Connect android phone - at this point it's only in sys-usb
> > 2. Switch its mode to file transfer - observe reconnect in sys-usb
> > 3. Use qvm-usb to attach it to the testvm
> > 4. Call jmtpfs -d /mnt in testvm
> 
> Or maybe reset or something is involved here too?
> 
> After using qvm-usb to attach _and detach_ the device, it stays bound to
> usbip-host driver (that's intentional). But then, even after re-binding
> back to the "usb" driver, jmtpfs called in sys-usb directly fails the
> same way, including failure to reset.
> 
> In fact, even without usbip involved at all, jmtpfs directly in sys-usb
> works only once. The second attempt (without either physically reconnecting
> the phone, or changing its more to "no data transfer" and back to "file
> transfer") fails the same way. After terminating the first instance, I
> see just this logged:
> 
>     [921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcd

If something doesn't work when usbip isn't involved, you definitely 
shouldn't expect it to work when usbip _is_ involved.

It sounds like you're facing more than one type of problem.  The best 
approach is to attack them separately.

I'd start with problems that exist only on sys-usb first -- keeping 
usbip out of the picture will make everything much simpler.  You can try 
capturing a usbmon trace, starting from before the phone is attached, 
and continuing on through the mode changes and failures.  In fact, break 
it up into several traces, each starting just before one of the major 
events (initial plug-in, mode change, whatever).

Once that's under control, I suggest using usbmon on both sides (sys-usb 
and testvm) of the usbip connection.  But start without usbip.

Alan Stern