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
| ||
|
Message-ID: <53CED031.9090907@zytor.com> Date: Tue, 22 Jul 2014 13:57:21 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Andy Lutomirski <luto@...capital.net>, "Theodore Ts'o" <tytso@....edu>, kvm list <kvm@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Kees Cook <keescook@...omium.org>, X86 ML <x86@...nel.org>, Daniel Borkmann <dborkman@...hat.com>, Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>, Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>, Gleb Natapov <gleb@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Bandan Das <bsd@...hat.com>, Andrew Honig <ahonig@...gle.com> Subject: Re: [PATCH v4 2/5] random: Add and use arch_get_rng_seed On 07/22/2014 01:44 PM, Andy Lutomirski wrote: > > But, if you Intel's hardware does, in fact, work as documented, then > the current code will collect very little entropy on RDSEED-less > hardware. I see no great reason that we should do something weaker > than following Intel's explicit recommendation for how to seed a PRNG > from RDRAND. > Very little entropy in the architectural worst case. However, since we are running single-threaded at this point, actual hardware performs orders of magnitude better. Since we run the mixing function (for no particularly good reason -- it is a linear function and doesn't add security) there will be enough delay that RDRAND will in practice catch up and the output will be quite high quality. Since the pool is quite large, the likely outcome is that there will be enough randomness that in practice we would probably be okay if *no* further entropy was ever collected. > Another benefit of this split is that it will potentially allow > arch_get_rng_seed to be made to work before alternatives are run. > There's no fundamental reason that it couldn't work *extremely* early > in boot. (The KASLR code is an example of how this might work.) On > the other hand, making arch_get_random_long work very early in boot > would either slow down all the other callers or add a considerable > amount of extra complexity. > > So I think that this patch is a slight improvement in RNG > initialization and will actually result in simpler code. (And yes, if > I submit a new version of it, I'll fix the changelog.) There really isn't any significant reason why we could not permit randomness initialization very early in the boot, indeed. It has largely been useless in the past because until the I/O system gets initialized there is no randomness of any kind available on traditional hardware. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists