On Wednesday, April 17, 2019 1:36:08 PM EDT Lennart Poettering wrote:
On Mi, 17.04.19 10:55, Steve Grubb (sgrubb(a)redhat.com) wrote:
> On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > What's the story anyway for rngd? Why would userspace be better at
> > providing entropy to the kernel than the kernel itself? Why do we
> > enable it on desktops at all, such systems should not be
> > entropy-starved. Do we need this at all now that the kernel can use
> > RDRAND itself?
>
> The kernel uses RDRAND/SEED but it does not increment the entropy
> estimate based on it. Another interesting thing is that TPM chips also
> have entropy
That's not true anymore. There's a kernel compile time option now for
that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel sets
that since a while.
Ah...the devil is in the details. It does not credit entropy. This can easily
be tested. systemctl stop rngd. Then open 2 terminal windows. In one terminal
start this shell script:
#!/bin/sh
while [ 1 ]
do
/bin/cat /proc/sys/kernel/random/entropy_avail
sleep 1
done
Then in another:
cat /dev/random >/dev/null
After a couple seconds, hit ctl-c to kill cat. Watch what happens to the
entropy.
I have a Kabylake system idling. It takes 3 minutes for entropy to get back
to 3k after stopping the consumer. At that point its losing about as much as
its gaining. If I start rngd and do the same test, my entropy bounces back to
over 3k in less than a second. As it stands today, rngd has a dramatic effect
on entropy.
> available, but the kernel does not use it. So, if you have a
hardware
> based entropy source such as TPM, you need rngd to move the entropy to
> the kernel. And it also can mine CPU jitter to create some entropy on
> its own. And it also supports the NIST beacon if you want that kind of
> entropy. Rngd greatly helps system recover from low entropy situations.
Yeah, all that stuff is stuff the kernel could do better on its
own.
Many have tried to convince upstream about this. If anyone here has influence,
please try.
If the CPU jitter stuff or the TPM stuff is a good idea, then why
not add that to the kernel natively, why involve userspace with that?
I agree. :-)
i.e. if the TPM and the CPU jitter stuff can be trusted, then the
same
thing as for CONFIG_RANDOM_TRUST_CPU=y should be done: pass the random
data into the pool directly inside in the kernel.
And credit entropy!
> > rngd runs as regular system service, hence what's the
point of that
> > altogether? I mean, it runs so late during boot, at a point where the
> > entropy pool is full anyway,
>
> I'd really like to see it start much earlier. Any way to make that
> happen?
Well, no. I mean, the only way you can do that is by turning rngd into
its own init system, if you want it to run before the init
system.
> > RNG, and it does that super early). So, why run a service that is
> > supposed to fill up the entropy pool at a point where we don't need it
> > anymore, and if the kernel can do what it does most likely already on
> > its own?
>
> The kernel cannot recover quickly when stressed for continued entropy
> depletion. For example, we are required to be able to supply all guest
> VM's with entropy from the host. They draw down the entropy pools which
> need replenishment. The kernel is constantly starved for entropy.
That's not how the entropy pool works. Once it is full it's full, and
it doesn't run empty anymore.
Empirical evidence suggests otherwise. See the test above.
> I think you're being harsh without really looking deeply
into the
> problem. If we could set a sysctl to tell the kernel to use a TPM or
> increment entropy estimate when RDSEED is used, I'd agree we should
> consider this. And to be
OK, so I guess that point in time is now. Though it's not a sysctl,
but a compile time option (see above).
It looks as though it may be controlled as a boot commandline option, too.
But that is likely intended to disable the effect it has.
-Steve