On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > 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... I like the part that this is trivial to solve if people want to. Making people agree is an order of magnitude harder than fixing any code. Nevertheless, without rngd, getrandom() would block in one of the first services started by systemd (if it doesn't block in systemd itself). The kernel option CONFIG_RANDOM_TRUST_CPU, is not portable so you'll need something more for non-x86. What rngd does that the kernel doesn't is a jitter entropy "subsystem" which will feed the kernel with random data, even when the hardware doesn't support something native. Can the jitter entropy gather be done by the kernel? It seems yes via the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU and the jitterentropy_rng may help in simplifying fedora (if people agree :). regards, Nikos _______________________________________________ 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