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]

Message-Id: <1229520685.13305.32.camel@nathan.suse.cz>
Date:	Wed, 17 Dec 2008 14:31:25 +0100
From:	Petr Tesarik <ptesarik@...e.cz>
To:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	Ilpo J??rvinen <ilpo.jarvinen@...sinki.fi>,
	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: make urg+gso work for real this time

Alexey Kuznetsov píše v St 17. 12. 2008 v 15:55 +0300:
> Hello!
> 
> > In other words what we do currently potentially makes urgent
> > mode completely useless since it may delay the sending of the
> > urgent notification indefinitely.  While the BSD behaviour would
> > only break "broken" applications.
> 
> This is true.
> 
> It definitely will work with correct application (those which
> use SO_OOBINLINE), and surely will kill those which treat
> urg data in _default_ __BSD__("BSD behaviour", you say, huh:-))
> way and withdraw octet at urgent pointer. 
> 
> Probably, netbsd/openbsd have some another quirk to work this around.
> I do not see how, though.
> 
> I decided that this is a fatal conflict, which can be solved cleanly
> only in a painful way like you suggested. Current approach delaying
> URG is the way which does not spoil any data, breaking only in the
> case of aborts.
> 
> If you are serious about this, also it would be a good idea
> to make SO_OOBINLINE default option. Consider this. At least this
> will allow to trap applications which will corrupt data stream
> earlier.

This might turn out to be a dangerous decision. I am aware at least of
one big application which uses urgent data and doesn't use SO_OOBINLINE:
Oracle.

Yes, of course it's broken, but do we really want to join the much-hated
folks who are stuck with an only-we-do-it-correctly approach?

Just my 2 cents,
Petr Tesarik


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