Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1174798 > unrolled thread

[RFC PATCH 0/1] RFC - Implement a usbredir kernel module

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/1] RFC - Implement a usbredir kernel module Jeremy White <jwhite@codeweavers.com> - 2015-07-01 00:10 +0200
    Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to  remotely connect USB devices over IP. "Daniel P. Berrange" <berrange@redhat.com> - 2015-07-01 11:10 +0200
      Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to  remotely connect USB devices over IP. Oliver Neukum <oneukum@suse.com> - 2015-07-02 10:50 +0200
    Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect  USB devices over IP. Jeremy White <jwhite@codeweavers.com> - 2015-07-07 18:50 +0200

#1174798 — [RFC PATCH 0/1] RFC - Implement a usbredir kernel module

The following patch proposes a new kernel module to provide an
alternate protocol for transporting USB devices over a TCP/IP connection.

This flows from a few conversations on the Spice devel mailing list.[1][2]

I am relying heavily on the opinion of Hans de Goede, who believes
that the usbredir protocol is superior to that used by the existing
usbip kernel module[3].

The basic approach in this module is the same as usbip (virtual hcd driver)
but it attempts to support a configurable number of devices and hubs,
rather than just one hub and the limit of 8 devices.

This version of the code should be sufficient to review my general
approach, but it is known to be incomplete.  I have successfully mounted
and operated a thumb drive across the interface.

Hopefully it is enough to warrant advice and comments; feedback is
greatly appreciated.

Anyone wishing to test this will also need a related set of usbredir patches,
recently sent to the spice-devel mailing list.[4]

Roughly half of the code (all of the code that fails checkpatch <grin>)
was copied, essentially unchanged, from the usbredir project.  I felt
that diffability was more important than checkpatch; I stand ready to
be corrected.

After review, I plan to build a fairly extensive set of unit tests
(see the new usbredirtestserver in [3]), and would hope to submit
a complete module later in the summer.

Cheers,

Jeremy


[1] http://lists.freedesktop.org/archives/spice-devel/2014-August/017145.html
[2] http://lists.freedesktop.org/archives/spice-devel/2015-April/019451.html
[3] http://lists.freedesktop.org/archives/spice-devel/2014-August/017174.html
[4] http://lists.freedesktop.org/archives/spice-devel/2015-June/020595.html

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

[toc] | [next] | [standalone]

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

On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote:
> This module uses the usbredir protocol and user space tools,
> which are used by the SPICE project.
> 
> Signed-off-by: Jeremy White <jwhite@codeweavers.com>

[snip]

> diff --git a/drivers/usb/usbredir/Kconfig b/drivers/usb/usbredir/Kconfig
> new file mode 100644
> index 0000000..284fd02
> --- /dev/null
> +++ b/drivers/usb/usbredir/Kconfig
> @@ -0,0 +1,25 @@
> +config USBREDIR
> +	tristate "USBREDIR support"
> +	depends on USB && NET
> +	---help---
> +	  This enables connecting a remote USB device over IP using
> +          the USBREDIR protocol.  This module provides a sysfs attach
> +          interface which, if given a socket connected to a remote
> +          usbredirserver, will enable the remote device to behave as
> +          though it were connected to the system running this module.
> +
> +          For more information and user space tools, refer to the
> +          USBREDIR project, which can be found at
> +          http://www.spice-space.org/page/UsbRedir.

[snip]

> new file mode 100644
> index 0000000..217a2e4
> --- /dev/null
> +++ b/drivers/usb/usbredir/README
> @@ -0,0 +1,20 @@
> +USB Redirection Kernel Module
> +
> +This module allows a Linux system to instatiate USB devices
> +that are located on a remote device.  The USB data is transferred
> +over a socket using the USBREDIR protocol, which is generally
> +used in conjunction with the SPICE project.
> +
> +You will need the USBREDIR user space tools.  They can
> +be found at http://www.spice-space.org/page/UsbRedir.
> +
> +To use, start the usbredirserver on a remote system.
> +For example,
> + ./usbredirserver --port 4000 125f:db8a
> +will export my ADATA thumb drive on the remote system.
> +
> +Next, on the local system, connect a socket and relay that to
> +the kernel module.  The connectkernel utility will do this as follows:
> +  ./connectkernel adata4000 my.remote.device.com 4000
> +
> +The device should attach and be usable on the local system.

What is the security story here ? If I am understanding correctly, you have
a userspace helper which opens a socket, and does a connect() to establish
the connection to the remote system, and then tells the kernel to use the
file descriptor associated with the socket.

Assuming that's correct, then this seems to imply that the socket has raw
plain text data being sent/received, and thus precludes the possibility
of running any security protocol like TLS unless the kernel wants to have
an impl of the TLS protocol.

I don't really think it is sensible to be defining & implementing new
network services which can't support strong encryption and authentication.
Rather than passing the file descriptor to the kernel and having it do
the I/O directly, I think it would be better to dissassociate the kernel
from the network transport, and thus leave all sockets layer data I/O
to userspace daemons so they can layer in TLS or SASL or whatever else
is appropriate for the security need.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On Wed, 2015-07-01 at 10:06 +0100, Daniel P. Berrange wrote:

> I don't really think it is sensible to be defining & implementing new
> network services which can't support strong encryption and authentication.
> Rather than passing the file descriptor to the kernel and having it do
> the I/O directly, I think it would be better to dissassociate the kernel
> from the network transport, and thus leave all sockets layer data I/O
> to userspace daemons so they can layer in TLS or SASL or whatever else
> is appropriate for the security need.

Hi,

this hits a fundamental limit. Block IO must be done entirely in kernel
space or the system will deadlock. The USB stack is part of the block
layer and the SCSI error handling. Thus if you involve user space you
cannot honor memory allocation with GFP_NOFS and you break all APIs
where we pass GFP_NOIO in the USB stack.

Supposed you need to reset a storage device for error handling.
Your user space programm does a syscall, which allocates memory
and needs to launder pages. It proceeds to write to the storage device
you wish to reset.

It is the same problem FUSE has with writable mmap. You cannot do
block devices in user space sanely.

	Sorry
		Oliver


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

[toc] | [prev] | [next] | [standalone]

#1178736 — Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

>>
>> Well, the checkpatch.pl reports were all style (and mostly whitespace);
>> roughly 3000 of them against 3000 lines of code :-/.  I did review the
>> code, looking for areas where I thought it would badly cram into the
>> kernel, and I adjusted the few I found (and sent changes upstream).
> 
> style matters, as it's a thing with your brain.  You learn patterns and
> if the patterns change, you have to do more work and don't see the real
> issues involved.  So by ignoring our style you are saying you don't want
> anyone else in the kernel community to ever review or work on the code,
> which isn't ok.

Looks like I can't side step this unless Hans is willing to shift the
usbredir project entirely to using kernel style :-/.

I will plan to make changes so that checkpatch runs clean; I lay out my
concerns and my plan below to make sure I'm taking the best path.

My main concern with changing the ~2,500 lines of code from the upstream
usbredir project is that it will increase the odds that I will introduce
errors, both initially, and again later as I review and attempt to relay
patches from the upstream.

To summarize the checkpatch reports:  the biggest issue is whitespace,
which shouldn't be a problem; I should be able to automate that without
error.  There are also a fair number of one offs; FSF address, space
after '!', etc.  I hope to persuade Hans to take a few style only
patches upstream to address those.  That leaves a pack of about 60 brace
placement and line length issues.

I will plan to manually change those prior to submission.  Any upstream
changes that affect the same code will be manually corrected as well,
prior to submission.

Make sense?

Cheers,

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web