linux-kernel - Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

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]

Date:	Thu, 2 Jul 2015 16:20:42 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jeremy White <jwhite@...eweavers.com>
cc:	Oliver Neukum <oneukum@...e.com>,
	Hans de Goede <hdegoede@...hat.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	<spice-devel@...ts.freedesktop.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to
 remotely connect USB devices over IP.

On Thu, 2 Jul 2015, Jeremy White wrote:

> > Oliver is talking about the danger of having part of the communication 
> > path for a block device run through userspace.
> > 
> > Imagine a situation where the client uses a USB storage device provided
> > by the server as a swap device.  And suppose a userspace daemon on the
> > client has to process USB packets as they pass between the client and
> > the server.  If the daemon is idle for some time, parts of its address
> > space may get stored in the swap area on the server and paged out.
> > 
> > Now consider what happens when those parts of memory need to be paged
> > back in.  The client submits a request to read from the swap area.  
> > The request is transformed into USB packets and sent through the
> > userspace daemon for transmission to the server.  But the daemon can't
> > process the packets because it is waiting for its missing parts to be
> > paged back!  Result: deadlock.
> 
> Right.  I followed that.  Oliver also asserted that he believed that the
> current usbip implementation has this flaw; I do not follow that.  The
> concept is that the usbip device driver virtualizes the device behavior;
> isolating the running kernel from the vagaries of the network transport.
>  All proposed usbredir implementations, even if they move the network
> transport to user space, would retain that behavior.

The point is that a device driver like usbip _cannot_ isolate the 
running kernel from the vagaries of the network transport if part of 
that transport occurs in userspace.

If any part of the transport passes through userspace, you can end up 
in a situation like what I outlined above, where a message can't be 
transported until after its reply has been received.  There's no way 
for a device driver to prevent a deadlock when this occurs, no matter 
what it virtualizes.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/