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