netdev - RE: [PATCH v2 net 2/2] tg3: Fix data corruption on 5725 with TSO

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: <1368543869.12268.49.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
Date:	Tue, 14 May 2013 08:04:29 -0700
From:	"Michael Chan" <mchan@...adcom.com>
To:	"David Laight" <David.Laight@...LAB.COM>
cc:	"Nithin Nayak Sujir" <nsujir@...adcom.com>,
	"Eric Dumazet" <eric.dumazet@...il.com>, davem@...emloft.net,
	netdev@...r.kernel.org, stable@...r.kernel.org
Subject: RE: [PATCH v2 net 2/2] tg3: Fix data corruption on 5725 with
 TSO

On Tue, 2013-05-14 at 09:40 +0100, David Laight wrote:
> > >>>> +        if (tg3_asic_rev(tp) == ASIC_REV_5762 && mss) {
> > >>>> +                u32 base = (u32) mapping & 0xffffffff;
> > >>>> +
> > >>>> +                return ((base + len + (mss & 0x3fff)) < base);
> ... 
> > For the bug to occur, the fragment does not have to span a 4G boundary. If it is
> > within MSS bytes (9.6k) of a 4G boundary, it triggers the failure.
> 
> Would it be worth simplifying the test to assume that 'len'
> is 64k and 'mss' 9.6k?
> (commenting on the actual condition.)
> The number of false positives would be small, but the test
> a lot quicker.
> The '(u32)mapping + (0x10000 + 9600) < (u32)mapping' test might
> even be faster than the ' tg3_asic_rev(tp) == ASIC_REV_5762' one. 

I think that if we do this and detect a false positive, it may be very
far from the 4G boundary.  The new skb that we allocate to workaround
the condition may be even closer to 4G and may hit the real bug
condition.

The mss and len values are accessed many times in this immediate code
path just before setting the TX BD, gcc should be able to optimize this
quite nicely.


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