On Mi, 17.04.19 11:29, Japheth Cleaver (cleaver@xxxxxxxxxxxxxx) wrote: > On 4/17/2019 10:36 AM, 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: > > > > 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. > > This seems like a false dichotomy, no? Surely, things like this are a > possibility: > https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html That too means the service gets started after the init system is up, and the init system already requires entropy, so it's pointless. > But beyond that, is there really no way to lift this earlier in the boot > logic? Sure, you can invoke rngd before systemd, in which case it would have to be able to run as PID 1 itself pretty much and then hand over things. But why do that in userspace at all? the "Trust CPU RNG" kernel compile time option shows that these things are trivial to solve if people just want to. Instead of involving rngd at all, why not add a similar option for the TPM RNG (or any other non-CPU hw rng) and then rngd doesn't do anything useful anymore whatsoever? I mean, to my knowledge all those other RNGs already feed into the pool anyway, they just don't get trusted and thus don't add to the entropy estimate. Fixing that should be quite doable and given that CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too hard to argue for a CONFIG_RANDOM_TRUST_TPM either... Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
