netdev - RE: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned

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] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6B5567@AcuExch.aculab.com>
Date:	Fri, 31 Jan 2014 09:30:03 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Peter Stuge' <peter@...ge.se>
CC:	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	David Miller <davem@...emloft.net>
Subject: RE: [PATCH RFC 1/1] usb: Tell xhci when usb data might be	misaligned

From: Peter Stuge
> But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?

No because there is a copy_to/from_user() in the middle.

The ehci/ohci/uhci all require that fragments be a multiple of the
usb message size (512 bytes for USB2).
So everything (until very recently) would always supply suitable
aligned buffers. Mostly they are page aligned.

For those who haven't read the xhci spec carefully:

The xhci controller removes the requirement on dma segments being
aligned to usb messages.
However there are two alignment requirements:
1) dma segments must not cross 64k address boundaries.
   This is documented clearly, even though it is a slight pain.
   You'd have thought the address counter could have more than
   16 bits these days!
   There only 17 bits for the length, but a length restriction
   would be less of a problem.
2) The v1.00 version of the specification adds that the end of
   the transfer ring can only occur at a 'TD fragment' boundary.
   These are aligned with the payload 'bursts' - which can be
   sixteen 1k packets.
I think that breaking the second of these causes a usb message
be split into two small pieces - which will terminate bulk xfers.
The asix USB3 Ge silicon gets very confused when this happens.

	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