netdev - Re: [PATCH net-next] random32: mix in entropy from core to late initcall

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] [day] [month] [year] [list]

Message-Id: <20140730.135548.612455468946510168.davem@davemloft.net>
Date:	Wed, 30 Jul 2014 13:55:48 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dborkman@...hat.com
Cc:	netdev@...r.kernel.org, hannes@...essinduktion.org
Subject: Re: [PATCH net-next] random32: mix in entropy from core to late
 initcall

From: Daniel Borkmann <dborkman@...hat.com>
Date: Mon, 28 Jul 2014 14:01:38 +0200

> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> 
> Currently, we have a 3-stage seeding process in prandom():
> 
> Phase 1 is from the early actual initialization of prandom()
> subsystem which happens during core_initcall() and remains
> most likely until the beginning of late_initcall() phase.
> Here, the system might not have enough entropy available
> for seeding with strong randomness from the random driver.
> That means, we currently have a 32bit weak LCG() seeding
> the PRNG status register 1 and mixing that successively
> into the other 3 registers just to get it up and running.
> 
> Phase 2 starts with late_initcall() phase resp. when the
> random driver has initialized its non-blocking pool with
> enough entropy. At that time, we throw away *all* inner
> state from its 4 registers and do a full reseed with strong
> randomness.
> 
> Phase 3 starts right after that and does a periodic reseed
> with random slack of status register 1 by a strong random
> source again.
> 
> A problem in phase 1 is that during bootup data structures
> can be initialized, e.g. on module load time, and thus access
> a weakly seeded prandom and are never changed for the rest
> of their live-time, thus carrying along the results from a
> week seed. Lets make sure that current but also future users
> access a possibly better early seeded prandom.
> 
> This patch therefore improves phase 1 by trying to make it
> more 'unpredictable' through mixing in seed from a possible
> hardware source. Now, the mix-in xors inner state with the
> outcome of either of the two functions arch_get_random_{,seed}_int(),
> preferably arch_get_random_seed_int() as it likely represents
> a non-deterministic random bit generator in hw rather than
> a cryptographically secure PRNG in hw. However, not all might
> have the first one, so we use the PRNG as a fallback if
> available. As we xor the seed into the current state, the
> worst case would be that a hardware source could be unverifiable
> compromised or backdoored. In that case nevertheless it
> would be as good as our original early seeding function
> prandom_seed_very_weak() since we mix through xor which is
> entropy preserving.
> 
> Joint work with Daniel Borkmann.
> 
> Signed-off-by: Daniel Borkmann <dborkman@...hat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>

Looks great, applied, thanks everyone.
--
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