(off-list ancestor, not in this archive)
[PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool · "Theodore Ts'o" <tytso@mit.edu> · 2012-07-06
[PATCH] random: only use gathered bytes from arch_get_random_long · Kees Cook <hidden> · 2012-07-07
Re: [PATCH] random: only use gathered bytes from arch_get_random_long · "Theodore Ts'o" <tytso@mit.edu> · 2012-07-07
Re: [PATCH] random: only use gathered bytes from arch_get_random_long · Kees Cook <hidden> · 2012-07-07
Re: [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool · Ben Hutchings <hidden> · 2012-07-08
Re: [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool · "Theodore Ts'o" <tytso@mit.edu> · 2012-07-08
Re: [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool · Ben Hutchings <hidden> · 2012-07-08

Re: [PATCH 07/12] random: use the arch-specific rng in xfer_secondary_pool

From: Theodore Ts'o <tytso@mit.edu>
Date: 2012-07-08 01:41:35
Also in: lkml

On Sun, Jul 08, 2012 at 02:06:46AM +0100, Ben Hutchings wrote:

Surely the number of random bytes being added is i * sizeof(long), not
sizeof(u.hwrand)?

Meh; Kees Cook has made the same observation.  Basically, in the
unlikely case where RDRAND fails, we'll end up mixing in stack
garbage.  It's not a security vulnerability, since the contents of the
entropy pool never gets exposed.  In fact, one could argue that mixing
in some unknown garbage from the kernel stack might actually help a
little; but it can't hurt.

					- Ted

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help