20.09.2019 01:04, Linus Torvalds пишет:

> instead. Yeah, it still doesn't help on machines that don't even have
> a cycle counter, but it at least means that you don't have to have a
> CPU rdrand (or equivalent) but you do have a cycle counter, now the
> extraction of randomness from the pool doesn't just do the
> (predictable) mutation for the backtracking, but actually means that
> you have some very hard to predict timing effects.
> 
> Again, in this case a cycle counter really does add a small amount of
> entropy (everybody agrees that modern CPU's are simply too complex to
> be predictable at a cycle level), but that's not really the point. The
> point is that now doing the extraction really fundamentally changes
> the state in unpredictable ways, so that you don't have that "if I
> recognize a value, I know what the next value will be" kind of attack.

This already resembles in-kernel haveged (except that it doesn't credit 
entropy), and Willy Tarreau said "collect the small entropy where it is, 
period" today. So, too many people touched upon the topic in one day, 
and therefore I'll bite.

We already have user-space software (haveged and modern versions of 
rngd) that extract supposed entropy from clock jitter and feed it back 
to the kernel via /dev/random (crediting it). Indeed, at present, on 
some hardware this is the only way for distributions and users to 
collect enough entropy during boot and avoid stalls - all other 
suggestions are simply non-constructive. Also, Google's Fuchsia OS does 
use and credit jitter entropy.

For the record: I do not have a justifiable opinion whether haveged/rngd 
output (known as jitter entropy) actually contains any entropy. I 
understand that there are two possible viewpoints here. The rest of the 
email is written under the assumption that haveged does provide real 
entropy and not fake one.

The problem that I have with the current situation is that distributions 
and users, when they set up their systems to run haveged or rngd, often 
do it incorrectly (even, as mentioned, under the assumption that haveged 
is something valid and useful). The most common mistake is relying on 
systemd-provided default dependencies, thus not starting such software 
as early as possible. Even worse, no initramfs generator allows one to 
easily include haveged/rngd in the initramfs and run it there. And for 
me, the first urandom warning comes from the initramfs, so anything 
started from the main system is, arguably, already too late.

Therefore, I think, an in-kernel hwrng that exposes jitter entropy is 
something useful (for those who agree that jitter entropy is not fake), 
because it avoids the pitfall-ridden userspace setup. Just as an 
exercise, I have implemented a very simple driver (attached as a patch) 
that does just that. I am only half-serious here, the driver is only 
lightly tested in KVM without any devices except an unconnected virtio 
network card, not on any real hardware. Someone else can also find it 
useful as a test/fake hwrng driver.

I am aware that there was an earlier decision that jitter entropy should 
not be credited, i.e. effectively a pre-existing NAK from Theodore Ts'o. 
But, well, distributions are already overriding this decision in 
userspace, and do it badly, so in my viewpoint, the driver would be a 
net win if some mechanism is added that makes it a no-op by default even 
if the driver is built-in. E.g. an explicit "enable" parameter, but I am 
open to other suggestions, too.

-- 
Alexander E. Patrakov