Messages in this thread | | | Date | Mon, 19 May 2014 18:39:43 -0400 | From | Jörn Engel <> | Subject | Re: [PATCH] random: mix all saved registers into entropy pool |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |