Side note, and entirely unrelated to this particular problem, but
_because_ I was looking at the entropy init and sources of randomness
we have, I notice that we still don't use the ToD clock as a source.
There's not a whole lot of bits there, but at least one of the attacks
against entirely missing boot-time randomness was to look at the
output of get_random_bytes(), and just compare it across machines. We
sanitize things by going through a cryptographic hash function, but
that helps hide the internal entropy buffers from direct viewing, but
it still leaves the "are those internal entropy buffers the _same_
across machines" for the nasty embedded hardware case with identical
hardware.
Of course, some of those machines didn't even have a a time-of-day
clock either. But the fact that some didn't doesn't mean we shouldn't
take it into account.
So adding a "add_device_randomness()" to do_settimeofday64() (which
catches them all) wouldn't be a bad idea. Not perhaps "entropy", but
helping against detecting the case of basically very limited entropy
at all at early boot.
I'm pretty sure we discussed that case when we did those things
originally, but I don't actually see us doing it anywhere right now.
So we definitely have some sources of differences for different
systems that we could/should use, even if we might not be able to
really account them as "entropy". The whole "people generated a number
of the same keys" is just horrendously bad, even if they were to use
/dev/urandom that doesn't have any strict entropy guarantees.
Linus
