Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to
 remotely connect USB devices over IP.
To: Jeremy White <jwhite@codeweavers.com>,
        "Daniel P. Berrange" <berrange@redhat.com>
References: <1435700650-640-1-git-send-email-jwhite@codeweavers.com>
 <1435700650-640-2-git-send-email-jwhite@codeweavers.com>
 <20150701090619.GB16822@redhat.com> <55943213.6040901@codeweavers.com>
Cc: spice-devel@lists.freedesktop.org, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
From: Hans de Goede <hdegoede@redhat.com>
Message-ID: <5594352F.7080003@redhat.com>
Date: Wed, 1 Jul 2015 20:45:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <55943213.6040901@codeweavers.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3615
Lines: 78

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-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/