Re: [PATCH] random: mix all saved registers into entropy pool

["Jörn Engel" <joern@logfs.org>]

On Mon, 19 May 2014 15:18:01 -0700, H. Peter Anvin wrote:
> 
> I think this is likely to be particularly valuable during boot.  I can
> see it becoming substantially less valuable after that point, but during
> boot is when the most critical.
> 
> What I do see as an issue is that the value is probably impossible to
> quantify, and so I feel more than a bit queasy about giving it
> /dev/random credit.  However, making sure the pool is well stirred
> during boot is really way more important.

I would feel fairly confident giving this .25 bits of entropy per
event.  With 40% unique hashes and assuming at most 1 bit of entropy
for a unique hash, that is a fairly conservative underestimate.

But as you can see from the patch, I feel less confident doing any
kind of entropy-guessing in general and have skipped that step.  By
the .25 bits metric, my patch should feed 128 bits of entropy into
both the non-blocking pool and the input pool within the first 5s or
so of boot time.  In reality it is likely more.

The other problem to solve is VM clones sharing the same state for the
various pools.  Assuming HZ=100 no external interrupts and .25 bits, we
would gather 128 bits in just above 5s.  That is not great, but okish.

What worries me is that much of those 5s may be spent inside the idle
loop and have rather predictable register content and we may run
tickless.  I have no great solution for that case.

We could change the ratelimiting to, say, 4 interrupts per jiffie.
But that would still not help much in the worst case scenario above,
so the benefits don't seem convincing.

Jörn

--
When you admit that some people are too important to prosecute, it's
just a few short steps to the obvious corollary – that everybody else
is unimportant enough to jail.
-- Matt Taibbi