linux-kernel - Re: [PATCH v4 2/5] random: Add and use arch_get_rng

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

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/