netdev - RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.

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:	Mon, 18 Nov 2013 15:41:00 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Ben Hutchings" <bhutchings@...arflare.com>
Cc:	"Alan Stern" <stern@...land.harvard.edu>,
	"Sarah Sharp" <sarah.a.sharp@...ux.intel.com>,
	<netdev@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.

> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> Sent: 18 November 2013 15:03
> To: David Laight
> Cc: Alan Stern; Sarah Sharp; netdev@...r.kernel.org; linux-usb@...r.kernel.org
> Subject: Re: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
> 
> On Mon, 2013-11-18 at 09:48 +0000, David Laight wrote:
> > > > But the minimum fragment size is (probably) 4k.
> > > > For the network stack an OUT transfer might have a lot (and I mean lots)
> > > > of fragments (there may be constraints, and linearising the skb is a option).
> > > [...]
> > >
> > > The maximum number of fragments in the skb is going to be 17 (including
> > > the 'head' area).  (I'm ignoring NETIF_F_FRAGLIST which is not normally
> > > supported by physical device drivers.)
> > >
> > > I don't know how many fragments that can end up as, at the USB level.
> >
> > If you assume that every fragment crosses a 64k boundary that would be 34.
> > OTOH I've not seen a fragment of a 64k TSO send crossing a 32k
> > boundary, and I think the 'head' area is constrained to be part of
> > a single (4k or larger) page.
> 
> I don't know that it's possible at the moment, but I wouldn't recommend
> relying on that.

The xhci (USB3) hardware supports SG, but a non-obvious alignment restriction
applies at the end of a ring segment. In effect this means that the number of
fragments mustn't exceed the size of the ring segment.
It would make the xchi driver simpler if excessively fragmented requests
could just be bounced.
Since ring entries are 16 bytes there isn't much reason to not use a 4k
'page' for a ring and have (almost) 256 ring slots.
(The code currently uses multiple ring segments with 63 usable slots.)

Looks like skb are constrained enough that a sensible limit can be applied.

The other likely generator of fragmented requests is the mass storage code.
Most likely for dd(1) with a large block size.

	David