From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Graf Subject: Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets Date: Wed, 21 Jan 2015 09:56:34 +0000 Message-ID: <20150121095634.GO20315@casper.infradead.org> References: <20150120143154.GR14883@acer.localdomain> <20150120145551.GH20315@casper.infradead.org> <20150120152149.GA3012@acer.localdomain> <20150120153556.GJ20315@casper.infradead.org> <20150121050819.GA23062@gondor.apana.org.au> <20150121051555.GA23300@gondor.apana.org.au> <20150121091457.GA25289@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Patrick McHardy , davem@davemloft.net, paulmck@linux.vnet.ibm.com, ying.xue@windriver.com, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org To: Herbert Xu Return-path: Received: from casper.infradead.org ([85.118.1.10]:35806 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751582AbbAUJ4g (ORCPT ); Wed, 21 Jan 2015 04:56:36 -0500 Content-Disposition: inline In-Reply-To: <20150121091457.GA25289@gondor.apana.org.au> Sender: netfilter-devel-owner@vger.kernel.org List-ID: On 01/21/15 at 08:14pm, Herbert Xu wrote: > On Wed, Jan 21, 2015 at 04:15:55PM +1100, Herbert Xu wrote: > > I failed to address the security aspect of this approach. Obviously > > this can only work if the only entites doing the walk are trusted. > > Which means that the vast majority (if not all) hash table users > > would be excluded, in particular, netlink. > > OK maybe we can get around this. So we will postpone the resize > or rehash when a walk is in place, however, when we hit a hard > limit, i.e., when insert would otherwise fail, then we do the > rehash regardless of any outstanding walks. The walks will just > behave erratically or we could force them to start from scratch > again. Exactly. I think we also need a timer to abort walks because if only a single walker is allowed, an attacker could start a walk and not complete it to block out everybody else.