Date:	Mon, 6 Jan 2014 13:43:40 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Florian Westphal <fw@...len.de>
Cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH 01/12] netfilter: avoid get_random_bytes calls

Hello!

On Mon, Jan 06, 2014 at 12:54:36PM +0100, Florian Westphal wrote:
> 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 ]

I hope, I answer that below.

> > 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...

On some of my small virtual machines (amd64) I even see this message while
login on the console (small iptables set also loaded before). In the mean
time prandom_u32() is still seeded with maybe 3 bits (I once measured it)
at the beginning and won't get a refresh until the nonblocking pool is
fully initialized. prandom_u32 will just iterate over its seed until it
is renewed whereas get_random_bytes does try to stretch (with help of the
twisted GFSR and SHA-1) the available entropy in case the nonblocking_pool
is limited, thus it is more probable to get better random results.

E.g. on an amd64 athlon x2 with two VMs:
[Mon Jan  6 13:35:40 2014] Initializing cgroup subsys cpuset
...
[Mon Jan  6 13:36:21 2014] random: nonblocking pool is initialized

I normally get the message while typing in the password on the prompt of the
serial console.

Single integers are not so much of a problem. E.g. one problem in
wireless code was, where get_random_bytes was called in a loop to fill
a structure, that did hurt: f7d8ad81ca8c44 ("mac80211: minstrels: spare
numerous useless calls to get_random_bytes").

> > 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.

I don't know if it is a real problem. Most of the time the initial seed
should be enough, but I guess get_random_bytes would still be a more
defensive choice. I would have used it. ;)

Greetings,

  Hannes

--
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

Powered by blists - more mailing lists