netdev - Re: [RFC][PATCH] [TPROXY] kick out TIME_WAIT sockets in case a new connection comes in with the same tuple

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, 10 Dec 2008 09:52:22 +0100
From:	Balazs Scheidler <bazsi@...abit.hu>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, tproxy@...ts.balabit.hu, hidden@....bme.hu,
	panther@...abit.hu
Subject: Re: [RFC][PATCH] [TPROXY] kick out TIME_WAIT sockets in case a new
 connection comes in with the same tuple

On Tue, 2008-12-09 at 22:18 -0800, David Miller wrote:
> From: Balazs Scheidler <bazsi@...abit.hu>
> Date: Tue, 09 Dec 2008 08:51:35 +0000
> 
> > Hi,
> > 
> > I'd like to get some guidance regarding the following patch. There's a 
> > severe performance limitation related to TIME_WAIT sockets and TProxy rules.
> > The patch below is the 'nice' approach, but it adds 6 bytes to 
> > inet_sock and inet_timewait_sock. The 'ugly' approach would be to schedule the
> > removal of the affected TIME_WAIT sockets at PREROUTING time.
> > 
> > This post is meant to get some review, but please do not apply this patch this time.
> 
> I have no general objection to this, but people seem to be
> experts at making various parts of the TCP socket structures
> larger and larger :-(
> 

I understand. Here are the alternatives I considered:
 1) the patch above, by extending the socket structures
 2) expand skb, of course I felt this is worse than the patch I posted
 3) call inet_twsk_deschedule() from the prerouting hook

The 3rd one does not require any expansion of the related structures,
however it'd mean that the TCP state is not only looked up, but also
changed from the TPROXY target. I felt this ugly, but the ugliness would
be constrained to the tproxy code. Shall I post a patch implementing
option #3 above?

-- 
Bazsi


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