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:	Wed, 17 Dec 2008 15:17:13 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	kuznet@....inr.ac.ru, ptesarik@...e.cz, ilpo.jarvinen@...sinki.fi,
	netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: make urg+gso work for real this time

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Thu, 18 Dec 2008 09:16:37 +1100

> However, for retransmissions the urgent pointer is comletely
> bogus!
> 
> Again this shows that any application that's relying on the urgent
> data to be out-of-band is just broken.  The only sane way to use
> urgent mode is as a notification.

I don't think this is a completely fair assesment, to be
honest.

Showing that the BSD guys have some half-working hacks in
this area is pretty immaterial, in the grand scheme of things.
The fact that retransmits will corrupt the URG pointer is
merely an indication of how few people use BSD and URG in
this combination of circumstances.

Nothing more.

And it also shows that our strange scheme, where we don't
signal URG until it's within the 16-bit sequence offset
limit, at least reports an accurate URG value.

Also, what if we're using IPV6 jumbo frames and we advertise this
special 0xffff URG offset turd?  That points to a real byte in the
packet, but it might not be the right one since we can only accurately
point up to 0xffff into there.

In TCP/IP Volume 2, the original BSD code is even more ignorant of
this situation, it simply sets the difference into the field as-is,
not being mindful at all of overflow:

	ti->ti_urp = htons((u_short) (tp->snd_up - tp->snd_nxt));

which probably prompted the workaround you see in the BSD code these
days.  Which, as we've seen, it buggy.

Given all of this I still think our current compromise is likely the
best one.  We never will advertise an URG pointer that is not pointing
to where the URG data will be in the sequence space.
--
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