Messages in this thread | | | Subject | Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP. | From | Hans de Goede <> | Date | Wed, 1 Jul 2015 20:45:03 +0200 |
| |
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
| |