On Wed, 2019-04-24 at 14:16 +0200, Lennart Poettering wrote:
On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (nmav(a)redhat.com)
wrote:
> > As mentioned before: systemd itself already needs entropy itself
> > (it
> > assigns a random 128bit id to each service invocation, dubbed the
> > "invocation ID" of it, and it generates the machine ID and seeds
> > its
> > hash table hash functions), hence rngd doesn't cut it anyway,
> > since it
> > starts after systemd, being a service managed by systemd. If rngd
> > was
> > supposed to fill up the entropy pool at boot, it would have to
> > run as
> > initial PID 1 in the initrd, before systemd, and then hand over
> > to
> > systemd only after the pool is full. But it doesn't, hence rngd
> > is
> > pointless: it runs too late to be useful.
>
> The goal of running rngd early was to have the system boot, not
> necessarily to address systemd's need for random numbers. In that
> it
> is successful. I do not disagree that it is not a clean solution.
But how can it be successful? If systemd already needs to wait until
the pool is full to get the randomness it needs (and thus blocks
system boot-up as a whole) then what's the point in running rngd
afterwards? To reach the point where rngd can be run we already need
the pool to be full, and hence rngd can't do any good at all anymore,
whatsoever.
What does systemd use to generate these random numbers? Does it
directly call getrandom() or does something else?
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]