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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 30 Jan 2014 13:55:23 -0800
From:	Sarah Sharp <>
To:	Alan Stern <>
Cc:	David Laight <David.Laight@...LAB.COM>,
	"" <>,
	"" <>,
	Greg Kroah-Hartman <>,
	David Miller <>,
	Dan Williams <>,
	"Nyman, Mathias" <>,
	Mark Lord <>, Freddy Xin <>
Subject: Re: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned

On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote:
> On Thu, 30 Jan 2014, Sarah Sharp wrote:
> > It should not matter what alignment or length of scatter-gather list the
> > upper layers pass the xHCI driver, it should just work.  I want to do
> > this fix right, by changing the fundamental way we queue TRBs to the
> > rings to fit the TD rules.  We should break each TD into fragment-sized
> > chunks, and add a link TRB in the middle of a segment where necessary.
> That's a good plan.  However _some_ restriction will turn out to be
> necessary.
> For example, what will you do if a driver submits an SG list containing
> 300 elements, each 3 bytes long?  That's too many to fit in a single
> ring segment, but it's smaller than a TD fragment -- it's even smaller
> than maxpacket -- so there's no place to split it.  (Not that I think
> drivers _will_ submit requests like this; this is just to demonstrate
> the point.)
> It ought to be acceptable to require, for example, that an SG URB 
> contain no more than (say) 100 elements that are smaller than 512 
> bytes.

At that point, the xHCI driver or USB core should probably use a bounce
buffer.  It feels like we should attempt to push down scatter-gather
lists as far down in the stack as possible, so the upper layers don't
have to care what alignment, length, or random 64KB boundary splits we

> ehci-hcd gets along okay with the restriction that each SG element 
> except the last has to be a multiple of the maxpacket size.  xhci-hcd 
> can relax this quite a lot, but not all the way.

What does the EHCI driver do when it receives a SG list from the USB
networking layer that violates this restriction?

Sarah Sharp
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists