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 4:38:18 AM EDT Lennart Poettering wrote:
> On Di, 16.04.19 09:06, Adam Williamson (adamwill@xxxxxxxxxxxxxxxxx) wrote:
> 
> 
> > > I think all of these are good ideas. "No udev-settle" seems like a
> > > nice
> > > highlevel goal to shoot for.
> > >
> > >
> > >
> > > Another one I might add: "No stuck stop jobs" - it annoys me every
> > > single
> > > time when I reboot and something like rngd or conmon holds up my
> > > reboot
> > > for several minutes for no reason at all.
> >
> >
> >
> > I've seen the rngd stop thing, hadn't had time to investigate it yet as
> > more urgent fires keep showing up :/
> 
> 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 
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.


> 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?

> and we need the kernel's RNG much much earlier already (already because
> systemd assigns a uuid to each service invocation that derives from kernel
> 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.

> Isn't it time to kick rngd out of the default install, in particular
> on the workstation image? Isn't keeping it around just cargo culting?

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 
honest, it should be running during an anaconda or kickstart install in order 
to safely setup an encrypted disk. Also, livecd uses are starved for entropy 
and must use rngd to be responsive and safe. If you have a TPM, the best use 
you'll get out of it is providing random numbers via rngd. :-)

-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