netdev - Re: [PATCH 01/12] netfilter: avoid get_random

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: <20140106115436.GE28854@breakpoint.cc>
Date:	Mon, 6 Jan 2014 12:54:36 +0100
From:	Florian Westphal <fw@...len.de>
To:	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org, fw@...len.de
Subject: Re: [PATCH 01/12] netfilter: avoid get_random_bytes calls

Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
> On Mon, Jan 06, 2014 at 12:12:55AM +0100, Pablo Neira Ayuso wrote:
> > From: Florian Westphal <fw@...len.de>
> > 
> > All these users need an initial seed value for jhash, prandom is
> > perfectly fine.  This avoids draining the entropy pool where
> > its not strictly required.
> 
> Secrets protecting hash tables should be rather strong.

Yes, which is why e.g. conntrack hash is not converted.

> prandom_u32() has two seeding points at boot-up. One is at late_initcall.

Yes.  None of these locations are executed via initcalls, they are all
in _checkentry (i.e., run when userspace iptables inserts a rule using
the target/match), except hashlimit where its delayed until the first
address is stored (so its even later).

> Thanks to parallel boot-up this gets executed fairly early. The other one is
> when the RNG nonblocking pool is fully initialized. Only after this point we
> can assume prandom_u32() returns truely random values. In between, only
> get_random_bytes or net_get_random_once are safe for use.

Can you elaborate?  If entropy estimate is really really low
(because we're booting up), why would get_random_bytes() be a better
choice [ i understand net_get_random_once() is for delaying
the actual random_bytes call until a later point in time where we've
hopefully collected more entropy ]

> To get the impression when prandom_u32 gets truely seeded, watch out
> for the message "random: nonblocking pool is initialized" in dmesg. ;)

It happens very very early on my machine, even before / is remounted
rw.  I would be more interested in what happens on small embedded
boxes...

> Hmm, some of them look like good candidates for net_get_random_once. I don't
> see such a problem with draining entropy pool, especially as they don't run
> that early and they don't request so many random bits.

I specifically did not use net_get_random_once once because checkentry is
not a hotpath.

I don't see why get_random_bytes use increases the security margin, especially
considering none of these hashes have periodic run-time rehashing?

But sure, if you think this change is a problem, Pablo can just revert it.
--
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