From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: DDoS attack causing bad effect on conntrack searches Date: Thu, 22 Apr 2010 08:51:23 -0700 Message-ID: <20100422155123.GA2524@linux.vnet.ibm.com> References: <1271941082.14501.189.camel@jdb-workstation> <4BD04C74.9020402@trash.net> <1271946961.7895.5665.camel@edumazet-laptop> <1271948029.7895.5707.camel@edumazet-laptop> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Patrick McHardy , Changli Gao , hawk@comx.dk, Linux Kernel Network Hackers , netfilter-devel@vger.kernel.org To: Eric Dumazet Return-path: Content-Disposition: inline In-Reply-To: <1271948029.7895.5707.camel@edumazet-laptop> Sender: netfilter-devel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Thu, Apr 22, 2010 at 04:53:49PM +0200, Eric Dumazet wrote: > Le jeudi 22 avril 2010 =E0 16:36 +0200, Eric Dumazet a =E9crit : >=20 > > If one hash slot is under attack, then there is a bug somewhere. > >=20 > > If we cannot avoid this, we can fallback to a secure mode at the se= cond > > retry, and take the spinlock. > >=20 > > Tis way, most of lookups stay lockless (one pass), and some might t= ake > > the slot lock to avoid the possibility of a loop. > >=20 > > I suspect a bug elsewhere, quite frankly ! > >=20 > > We have a chain that have an end pointer that doesnt match the expe= cted > > one. > >=20 >=20 > On normal situation, we always finish the lookup : >=20 > 1) If we found the thing we were looking at. >=20 > 2) We get the list end (item not found), we then check if it is the > expected end. >=20 > It is _not_ the expected end only if some writer deleted/inserted an > element in _this_ chain during our lookup. So this situation uses SLAB_DESTROY_BY_RCU to quickly recycle deleted elements? (Not obvious from the code, but my ignorance of the networki= ng code is such that many things in that part of the kernel are not obviou= s to me, I am afraid.) Otherwise, of course you would simply allow deleted elements to continu= e pointing where they did previously, so that concurrent readers would no= t miss anything. Of course, the same potential might arise on insertion, but it is usual= ly OK to miss an element that was inserted after you started searching. > Because our lookup is lockless, we then have to redo it because we mi= ght > miss the object we are looking for. Ah... Is there also a resize operation? Herbert did do a resizable hash table recently, but I was under the impression that (1) it was in some other part of the networking stack and (2) it avoided the need to restart readers. > If we can do the 'retry' a 10 times, it means the attacker was really > clever enough to inject new packets (new conntracks) at the right > moment, in the right hash chain, and this sounds so higly incredible > that I cannot believe it at all :) Or maybe the DoS attack is injecting so many new conntracks that a larg= e fraction of the hash chains are being modified at any given time? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe netfilter-dev= el" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html