When extracting from the input pool to feed one of the output pools, extracting more bytes can't hurt the reseed, and it can help if there happens to be more entropy than we estimated. We deliberately try to be conservative in our estimates -- for example, mixing in the cycle counter on each event but estimating based on the low-resolution clock -- so this situation is likely.
For example, the authors of http://eprint.iacr.org/2012/251.pdf found in a multi-week run on a desktop that the actual entropy from add_input_randomness was much higher than our estimates, at 9.69 bits min-entropy per event from the cycle counters alone vs. 1.85 bits estimated. The only reason to hold back is that we have to debit the input pool's entropy estimate for every byte we extract, which may delay us the next time we want to extract from the input pool. But if we're already leaving the pool practically empty, this isn't much of a cost. So go ahead and suck up two full extractions, 160 bits. If we have even more than that and didn't know it, this should still be a good solid seed. We just have to make sure not to give ourselves credit for more entropy than our sober estimates allow. The credit_bits output parameter takes care of that. Signed-off-by: Greg Price <pr...@mit.edu> --- drivers/char/random.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index c11281551..c2428ecb2 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1001,6 +1001,13 @@ retry: ibytes = 0; if (credit_bits != NULL) *credit_bits = ibytes * 8; + if (dest != NULL && ibytes && ibytes == have_bytes) { + /* When a reseed drains the pool, we might as well + * suck up any underestimated entropy as well as what + * we estimate is there. */ + WARN_ON(credit_bits == NULL); + ibytes = max_t(size_t, ibytes, 2*EXTRACT_SIZE); + } entropy_count = max_t(int, 0, entropy_count - (ibytes << (ENTROPY_SHIFT + 3))); if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
