Re: Can we maybe reduce the set of packages we install by default a bit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday, April 17, 2019 1:36:08 PM EDT Lennart Poettering wrote:
> On Mi, 17.04.19 10:55, Steve Grubb (sgrubb@xxxxxxxxxx) 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 -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux