On Wed, Apr 17, 2019 at 10:38:18AM +0200, 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? IIUC, RDRAND exists from IvyBridge generation CPUs onwards for Intel or EPYC CPUs for AMD. I've no idea what the story is for non-x86 CPUs & RDRAND equivalent. Anyway, whether we can rely on RDRAND depends on what we consider the minimum targetted CPU models & architectures. I'm guessing that we do intend Fedora to work correctly in CPUs predating/lacking RDRAND. KVM guests can have a virtio-rng device provided on any architecture, which feeds from host's /dev/urandom, but it is unfortunately fairly rare for public cloud providers to enable it :-( rngd includes support for the "jitter entropy" source which uses CPU jitter to feed the RNG. At least in RHEL, this is the recommended option when the CPUs lack RDRAND or equivalent and is why rngd is enabled by default there. IIUC it is reading the jitter entropy from the kernel's crypto APIs, optionally applying AES to data, and then feeding it back into the kernel's rng pool. > 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, 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? /dev/random can get depleted after boot. Though modern recommendation is for apps to use /dev/urandom by default (or getrandom/getentropy syscalls), some probably still uses /dev/random for historical baggage reasons. 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
