On Wed, 2019-04-17 at 19:36 +0200, 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: > > > 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 > > 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. > > > 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. 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.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. Big +1, I've been saying this for ages as well ... > > > 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. > > > 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). I concur, I would really like to see rngd become a thing of the past as well. The kernel has all the tools and access needed to reseed itself, *requiring* a racy userspace tool to do the kernel's job is a bit ridiculous. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ 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
