Message-ID: <55958ACC.3080607@codeweavers.com>
Date: Thu, 02 Jul 2015 14:02:36 -0500
From: Jeremy White <jwhite@codeweavers.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Oliver Neukum <oneukum@suse.com>
CC: Hans de Goede <hdegoede@redhat.com>,
        "Daniel P. Berrange" <berrange@redhat.com>,
        spice-devel@lists.freedesktop.org, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to
 remotely connect USB devices over IP.
References: <1435700650-640-1-git-send-email-jwhite@codeweavers.com>		 <1435700650-640-2-git-send-email-jwhite@codeweavers.com>		 <20150701090619.GB16822@redhat.com> <1435826719.13145.10.camel@suse.com>		 <559521E5.2090400@redhat.com> <1435839045.2424.9.camel@suse.com>	 <55955F4F.4050500@codeweavers.com> <1435862819.1749.1.camel@suse.com>
In-Reply-To: <1435862819.1749.1.camel@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3084
Lines: 68

On 07/02/2015 01:46 PM, Oliver Neukum wrote:
> On Thu, 2015-07-02 at 10:57 -0500, Jeremy White wrote:
>> On 07/02/2015 07:10 AM, Oliver Neukum wrote:
>>> On Thu, 2015-07-02 at 13:35 +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 02-07-15 10:45, Oliver Neukum wrote:
>>>>> On Wed, 2015-07-01 at 10:06 +0100, Daniel P. Berrange wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Hi,
>>>>>
>>>>> this hits a fundamental limit. Block IO must be done entirely in kernel
>>>>> space or the system will deadlock. The USB stack is part of the block
>>>>> layer and the SCSI error handling. Thus if you involve user space you
>>>>> cannot honor memory allocation with GFP_NOFS and you break all APIs
>>>>> where we pass GFP_NOIO in the USB stack.
>>>>>
>>>>> Supposed you need to reset a storage device for error handling.
>>>>> Your user space programm does a syscall, which allocates memory
>>>>> and needs to launder pages. It proceeds to write to the storage device
>>>>> you wish to reset.
>>>>>
>>>>> It is the same problem FUSE has with writable mmap. You cannot do
>>>>> block devices in user space sanely.
>>>>
>>>> So how is this dealt with for usbip ?
>>>
>>> As far as I can tell, it isn't. Running a storage device over usbip
>>> is a bit dangerous.
>>
>> I don't follow that analysis.  The usbip interactions with the usb stack
>> all seem to be atomic, and never trigger a syscall, as far as I can
>> tell.  A port reset will flip a few bits and return.  A urb enqueue
>> queues and wakes a different thread, and returns.  The alternate thread
>> performs the sendmsg.
>>
>> I'm not suggesting that running a storage device over usbip is
>> especially safe, but I don't see the limit on the design.
> 
> Are you referring to the current code or the proposed user space pipe?

I'm referring to current usbip code.  But the proposed driver would have
the same behavior.

To be clear, I think the only tangible new proposal is the one Hans put
forth, which would modify the driver I originally posted to use a
netlink socket instead of a passing a file descriptor in via sysfs.
That would allow the user space application responsible for initiating
the request to provide TLS as desired.  It comes with the expense of an
extra memcpy, but I suspect Hans is right in saying the network
latencies make that an irrelevant cost.

Cheers,

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