linux-kernel - Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49

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: <alpine.LFD.2.00.0904111150380.4583@localhost.localdomain>
Date:	Sat, 11 Apr 2009 11:57:16 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	David Miller <davem@...emloft.net>, Ingo Molnar <mingo@...e.hu>,
	Lai Jiangshan <laijs@...fujitsu.com>, shemminger@...tta.com,
	jeff.chua.linux@...il.com, dada1@...mosbay.com, jengelh@...ozas.de,
	kaber@...sh.net, r000n@...0n.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: iptables very slow after commit
 784544739a25c30637397ace5489eeb6e15d7d49



On Fri, 10 Apr 2009, Paul E. McKenney wrote:
> 
> 1.	Assuming that the synchronize_net() is intended to guarantee
> 	that the new rules will be in effect before returning to
> 	user space:

Btw, I think that's a bad assumption.

The thing is, nobody can really care if the new rules are in effect or 
not, because the thing you race with is not the "return to user space" 
part, but the incoming packets.

And those incoming packets might have been incoming before the rules were 
set up too.

So I seriously doubt you need to synchronize with any returning to user 
space. What you want to synchronize with is then later actions that do 
things like turning on the interface that the rules are attached to etc!

So I would suggest:

 - remove the synchronize_net() entirely. Replace it with just freeing the 
   old rules using RCU.

 - new packets will always end up seeing the new rules. That includes the 
   case of somebody doing "ifconfig eth0 up" that enables a new source of 
   packets, so there are no real security issues.

 - if you enabled your network interfaces before you updated your packet 
   filtering rules, you already had a window where packets would come in 
   with the old rules, so doing a "synchronize_net()" in no way protects 
   against any race conditions anyway.

Am I missing something?

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/