netdev - Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets

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: <20150121051555.GA23300@gondor.apana.org.au>
Date:	Wed, 21 Jan 2015 16:15:55 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Patrick McHardy <kaber@...sh.net>, davem@...emloft.net,
	paulmck@...ux.vnet.ibm.com, ying.xue@...driver.com,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH 3/3] netlink: Lock out table resizes while dumping
 Netlink sockets

On Wed, Jan 21, 2015 at 04:08:19PM +1100, Herbert Xu wrote:
> 
> OK I think I have a solution for you guys.  But first you'll need to
> wait for me to undo the nulls stuff so I can steal that bit which
> is central to my solution.
> 
> Essentially I need a bit to indicate an entry in the bucket chain
> should be skipped, either because it has just been removed or that
> it is a walker entry (see xfrm_state_walk).
> 
> The way it'll work then is exactly the same as xfrm_state_walk,
> except that the linked list is broken up into individual buckets.
> 
> Of course we'll still need to postpone resizes (and rehashes which
> is what my work is about) during a walk but I think that's a fair
> price to pay.

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.

Even with trusted cases such as netfilter I'm uneasy about this
so I don't think I'm going to go forward with this approach.

At this point I think the best thing that'll give you stable dumps
is a separate list like xfrm_state_walk.  If you did that then
we don't need to touch rhashtable at all.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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