netdev - Re: [RFT 1/2] xhci 1.0: Limit arbitrarily-aligned scatter gather.

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]

Message-ID: <Pine.LNX.4.44L0.1402051619240.1312-100000@iolanthe.rowland.org>
Date:	Wed, 5 Feb 2014 16:23:50 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
cc:	David Laight <David.Laight@...LAB.COM>,
	Mark Lord <mlord@...ox.com>, netdev <netdev@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Bjørn Mork <bjorn@...k.no>,
	Freddy Xin <freddy@...x.com.tw>,
	Ming Lei <ming.lei@...onical.com>
Subject: Re: [RFT 1/2] xhci 1.0: Limit arbitrarily-aligned scatter gather.

On Wed, 5 Feb 2014, Sarah Sharp wrote:

> On Wed, Feb 05, 2014 at 11:58:12AM +0000, David Laight wrote:

> > The problem is that the ax88179_178a driver submits receive URBs that
> > cross 64k boundaries, and are not aligned (they start at an 0x40 boundary).
> > Receive USB frames can contain multiple ethernet frames, by default they
> > are 20kB (and sit in 24kB of memory).
> 
> Perhaps you should add printks when a TRB is split on 64KB boundaries
> and see if the device drops packets around that time?

This seems kind of puzzling.

In theory, any URB that's more than 1 byte long can cross a 64-KB 
boundary.  I don't understand why this should cause problems for 
xhci-hcd.  Sure, the transfer has to be split into multiple TDs where 
the boundary crossing occurs.  But why would that be problematic?

Alan Stern

--
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