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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists