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: <063D6719AE5E284EB5DD2968C1650D6D46742C@AcuExch.aculab.com>
Date:	Wed, 29 Jan 2014 14:26:15 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Greg KH' <gregkh@...uxfoundation.org>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Subject: RE: Many USB ethernet devices are broken over xhci

From: Greg KH 
> On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> > Many of the net/usb ethernet drivers (including common ones like
> > the smsc95xx) will fail to transmit all packet length properly
> > when connected to a USB3 port (ie using the xhci driver).
> 
> That's odd, as I've never had a problem with my USB 3.0 ethernet device
> (sorry, don't remember what driver it uses), and I stress it all the
> time.

If it is the ax88179_178a driver then it carefully pads packets
that are multiples of the message size.

> I've also run two different USB 2 ethernet devices on xhci with no
> issues at all, so perhaps the "many" statement might not be true?

Dunno, quite a few will send down requests with URB_SEND_SERO set.
Whether this causes a problem depends on exactly how the ethernet
packets are encapsulated in usb ones.
The ax88179_178a hardware gets very confused if you fail to send
a ZLP - which it why it uses the 'bodge' in usbnet to append a byte.

> > The underlying problem is that they assume the host controller
> > will honour the URB_ZERO_PACKET flag - which usbnet sets because
> > they specify FLAG_SEND_ZLP.
> >
> > However no one has ever added support for URB_ZERO_PACKET to
> > the xhci driver - so packets that need padding (probably 512
> > bytes after any header is added) will not be sent correctly
> > and may have very adverse effects on the usb target.
> 
> Really?  How has things been working so well up to now without this
> support?  Doesn't the hardware automatically add this padding with no
> explicit need for the xhci driver to do something?

Nope - things must work by luck!
Try ping -n $((512-0x32)) on an smsc95xx card - it should need a ZLP.

> > I don't think anything significant has changed (in the main kernel
> > sources) since I wrote the patch.
> 
> Then resubmit it, don't post links to it on the web, there's nothing we
> can do with them, sorry.

I've resubmitted it as a v3 patch (to linux-usb) in small steps so that
the changes are easier to verify.
The final result is slightly different as I spotted a couple of minor
issues when re-reading the final version.
Mostly due to another 2 months of looking at this code.

	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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ