netdev - Re: rhashtable issue

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: <173268446669.1734440.17749966565144969951@noble.neil.brown.name>
Date: Wed, 27 Nov 2024 16:14:26 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Kent Overstreet" <kent.overstreet@...ux.dev>
Cc: "Herbert Xu" <herbert@...dor.apana.org.au>, "Thomas Graf" <tgraf@...g.ch>,
 netdev@...r.kernel.org
Subject: Re: rhashtable issue - -EBUSY

On Wed, 27 Nov 2024, Kent Overstreet wrote:
> On Tue, Nov 26, 2024 at 12:36:54PM +0800, Herbert Xu wrote:
> > On Mon, Nov 25, 2024 at 11:35:48PM -0500, Kent Overstreet wrote:
> > >
> > > That knob was. That's not what I'm suggesting. Can you go back and
> > > re-read my, and Neal's, suggestion?
> > 
> > That's exactly what the knob used to do.  Let you add entries
> > without any limit.
> 
> No, the other option would be to add a knob to block until the rehash is
> finished instead of returning -EBUSY - that wouldn't be insecure.

Blocking is never acceptable for hashtable_insert().  It isn't needed.

I only suggested blocking (after dropping locks) because it is currently
the only way to handle some errors.  It would be better not to get the
errors.  This means accepting the possibility of longer hash chains.
Sometimes that is an acceptable tradeoff.

> 
> If allocating a bigger table is failing, that would require the limit on
> chain length to increase in order to guarantee that inserts won't fail,
> but that wouldn't be a security issue.
> 

but it would mean you cannot know if a long chain is a security issue -
someone determined your seed and is attacking your hash - or if it is
due to the density of the table being high.

I think it is perfectly reasonable to use use a word like "insecure" in
the description of the knob to allow longer hash chains and zero
failures.  I would want the insecurity to be clearly described, but I
think we would all want that.

NeilBrown