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: <1229529888.13305.57.camel@nathan.suse.cz>
Date:	Wed, 17 Dec 2008 17:04:48 +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 18:30 +0300:
> Hello!
> 
> > Probably, netbsd/openbsd have some another quirk to work this around.
> > I do not see how, though.
> 
> F.e. this could be totally safe if we do this only in the case
> when octet seq+0xFFFF has not yet been sent.
> 
> When we send segment with 0xFFFF inside urg_ptr is advanced and so on,
> so that receiver has no chances to corrupt stream.
> 
> 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. :-)

This is all nice, but it still does not solve those series of SIGURGs on
the receiving side. My suggestion is to not generate a new SIGURG until
the data for the latest one have arrived. There can be only one byte of
urgent data, so if somebody sends more than one, it cannot be handled by
the receiver, anyway, so that use case is broken and need not be taken
into account.

Oh, and since SIGURG is not a real-time signal, there is no requirement
to send as many of them as there were urgent data. Of course, this does
not help other OSes, but I'm not sure how they behave in these
situations.

Petr

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ