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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
