On Wed, Apr 17, 2019 at 10:55:58AM -0400, Steve Grubb wrote: > 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. The recommendation is for virtio-rng to be backed by /dev/urandom these days, so you won't deplete the host /dev/random anymore. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
