On Wednesday, April 17, 2019 1:36:08 PM EDT Lennart Poettering wrote:
> On Mi, 17.04.19 10:55, Steve Grubb ([email protected]) 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
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
