Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jan 06, 2014 at 12:12:55AM +0100, Pablo Neira Ayuso wrote: > > From: Florian Westphal <fw@xxxxxxxxx> > > > > 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 netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
