netdev - Re: [PATCH] tcp: make urg+gso work for real this time

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:	Thu, 18 Dec 2008 21:45:13 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	Petr Tesarik <ptesarik@...e.cz>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] tcp: make urg+gso work for real this time

On Thu, 18 Dec 2008, Herbert Xu wrote:

> On Thu, Dec 18, 2008 at 08:29:07AM +1100, Herbert Xu wrote:
> >
> > > I.e. we set URG and urg_ptr to fake scb->seq + 0xFFFF only when:
> > > 
> > > 	after(scb->seq + 0xFFFF, tp->snd_nxt)
> > > 
> > > My brains are rusty, so take this critically. :-)
> > 
> > Indeed that's a great idea!
> 
> OK, I think this is what we should do:
> 
> 1) Fix fresh transmissions of urgent mode as Alexey suggested.
> 
> This is the safest way of ensuring that the urgent notification
> is not delayed.  This is still not as "fast" as the BSD behaviour
> but it is much safer with respect to broken^H^H^H^H^H^Hlegacy
> applications.
> 
> 2) Continue to use the current test for retransmissions.
> 
> 3) Apply my original GSO patch and revert the existing URG fixes.
> 
> With Alexey's fix, the scenario that Ilpo identified would only
> occur on retransmissions.  As we disable TSO on retransmissions,
> it no longer affects my patch.

No, would you use that 0xffff hack with gso you would create even worse 
problem in case of reordering / losses. And that's just because the very 
scenario still remains fully unsolved. I'm not sure if you understood my 
scenario at all (I was hopeful that you did :-))? It's basically that 
(with the terms of this hack) some segments in a super-skb would need to 
set 0xffff while some < 0xffff. ...But you just can't send too large urg 
ptr in any segment or you're asking for trouble.

Also, I think even without gso but with reordering / enough losses will 
make it possible that not-yet-sent condition of Alexey's proposal (it's 
techically not-yet-received) will no longer hold from _the receiver's_ 
point of view and havoc breaks loose.

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