lkml.org 
[lkml]   [2015]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
From
Date
Hi,

On 01-07-15 20:31, Jeremy White wrote:
>> 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.
>
> Good point. For completeness, I'll note that, in a Spice use case, the
> data would be encrypted by the normal Spice mechanisms. And it would be
> fairly straight forward to write a user space daemon that would accept
> TLS and then relay to the unencrypted socket (of course, it would
> rewrite everything, which would be inefficient).
>
>>
>> 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.
>
> And that would also eliminate the need to copy the parsing code, which
> would be a nice improvement.
>
> I considered this approach, but discarded it, perhaps wrongly, when my
> google fu suggested that netlink sockets were the best way to connect
> user space and a kernel module. (Because I perceived netlink sockets to
> be functionally equivalent to the relay daemon described, above).
>
> From the user space perspective, the usbredir parser has an interface
> that exposes about 20 callback functions, which are invoked with
> pointers to a variety of structures. The ideal would be to have a
> mechanism to 'call into' kernel space with those varying interfaces.
>
> Would using ioctls be a reasonable way to achieve this? Is there a
> better way?
>
> In the other direction, the usbredir hc provides a range of functions; I
> think most interesting are the urb en/dequeue, hub control, and hub
> status calls. Some of that can be handled in the driver; some would
> need to be passed on to user space.
>
> My google fu did not lead me to an obvious way to pass this information
> to user space. The approach that comes to mind is to use a signal, or
> woken socket, to instruct user space to poll.
>
> I'd appreciate further comments and advice.

I think it makes sense to have the actual usbredir protocol parsing
in the kernel, and use a netlink interface, this will make it much
easier to deal with protocol extensions (although we have not had
any extensions to the usbredir proto in a while), and will be much
cleaner then an ioctl interface.

I think that Daniel's concern can easily be fixed by rather then
passing the fd of a socket into the kernel to simply forwarding the
data back and forth from a socket opened by userspace into the netlink
socket. This way SSL, SASL or whatever can be put in between, and
you can even built a nice test-suite this way :)

The downside of this is introducing an extra memcpy of all the data,
but an ioctl interface has the same problem and is going to be
unwieldy, so I advice against that.

As for the extra memcpy I would not worry about that, in all the
performance testing I've done it has almost always been all about
latency not throughput.

Regards,

Hans


\
 
 \ /
  Last update: 2015-07-01 21:01    [W:0.265 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site