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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081217.153442.166884508.davem@davemloft.net>
Date:	Wed, 17 Dec 2008 15:34:42 -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 10:25:54 +1100

> 1) We don't support that right now.

I guess this is what the people writing RFC793 were thinking
as well :-)

> 2) Even if we did this would be broken either way because just
> where do you put the urgent pointer if your packet is > 64K and
> the urgent pointer lies in the packet but beyond 64K to the start?

You would need to chop up the packet to allow proper specification of
the URG pointer.

> > 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.
> 
> I agree to the extent that urgent mode is hopelessly broken in
> so many ways so one more isn't going to make that much of a
> difference.
> 
> However, I still think that the approach suggested by Alexey is
> better than the status quo:
> 
> 1) It's unlikely to break any existing apps (all it does is send SIGURG
> multiple times).
> 
> 2) For those apps that use urgent mode in the first place, they're
> likely to want to see the urgent notification ASAP, rather than having
> it delayed due to the receiver being busy.  So this is an improvement
> over what we have.

I agree that prompt signalling of the URG condition is desirable.

None of the RFCs seem to give any real guidance in this area, and that
explains the plethora of ways we see various stacks handling this
situation.

I'll think about your patch some more, but no promises.
--
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