linux-kernel - Re: [PATCH 2/2] usbip: Implement SG support to vhci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Jul 2019 21:41:04 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Suwan Kim <suwan.kim027@...il.com>
cc:     shuah@...nel.org, <gregkh@...uxfoundation.org>,
        <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] usbip: Implement SG support to vhci

On Fri, 5 Jul 2019, Suwan Kim wrote:

> On Mon, Jun 24, 2019 at 01:24:15PM -0400, Alan Stern wrote:
> > On Mon, 24 Jun 2019, Suwan Kim wrote:
> > 
> > > > > +	hcd->self.sg_tablesize = ~0;
> > > > > +	hcd->self.no_sg_constraint = 1;
> > > > 
> > > > You probably shouldn't do this, for two reasons.  First, sg_tablesize
> > > > of the server's HCD may be smaller than ~0.  If the client's value is
> > > > larger than the server's, a transfer could be accepted on the client
> > > > but then fail on the server because the SG list was too big.
> > 
> > On the other hand, I don't know of any examples where an HCD has 
> > sg_tablesize set to anything other than 0 or ~0.  vhci-hcd might end up 
> > being the only one.
> > 
> > > > Also, you may want to restrict the size of SG transfers even further,
> > > > so that you don't have to allocate a tremendous amount of memory all at
> > > > once on the server.  An SG transfer can be quite large.  I don't know 
> > > > what a reasonable limit would be -- 16 perhaps?
> > > 
> > > Is there any reason why you think that 16 is ok? Or Can I set this
> > > value as the smallest value of all HC? I think that sg_tablesize
> > > cannot be a variable value because vhci interacts with different
> > > machines and all machines has different sg_tablesize value.
> > 
> > I didn't have any good reason for picking 16.  Using the smallest value 
> > of all the HCDs seems like a good idea.
> 
> I also have not seen an HCD with a value other than ~0 or 0 except for
> whci which uses 2048, but is not 2048 the maximum value of sg_tablesize?
> If so, ~0 is the minimum value of sg_tablesize that supports SG. Then
> can vhci use ~0 if we don't consider memory pressure of the server?
> 
> If all of the HCDs supporting SG have ~0 as sg_tablesize value, I
> think that whether we use an HCD locally or remotely, the degree of
> memory pressure is same in both local and remote usage.

You have a lot of leeway.  For example, there's no reason a single SG
transfer on the client has to correspond to a single SG transfer on the
host.  In theory the client's vhci-hcd can break a large SG transfer up
into a bunch of smaller pieces and send them to the host one by one,
then reassemble the results to complete the original transfer.  That
way the memory pressure on the host would be a lot smaller than on the
client.

Alan Stern