On Wed, 2019-04-17 at 10:55 -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. > > > 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. AFAIK, we already home that in place - if there is not enough entropy when storage encryption is being setup, the installation will pause & notify the user to provide more entropy (generally by monkey-bashing keyboard keys). > 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 _______________________________________________ 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
