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

> From: Sarah Sharp
...
> (Also, usb-storage aligns the block sizes to 512K, which explains why
> we've never had an issue with TD fragments with that driver.)

What is a 'block' in that context?
512K sounds more like the value that very long transfers get chopped
up into. With 4k pages that might be 128 fragments.

I'd have thought that the SG list would normally contain references
to a number of memory pages - so each would be 4k (on x86) aligned.
My suspicion is that the xhci controller will generate correct USB3
data provided the link TRB is on a 1k boundary - so such data won't
be a problem.

If a user program does a direct transfer from the block device
(and that is done by locking down the user pages) then the buffer
could have an arbitrary alignment.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html