On Mi, 24.04.19 17:43, Tomas Mraz (tmraz(a)redhat.com) wrote:
> But how can it be successful? If systemd already needs to wait
> 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,
What does systemd use to generate these random numbers? Does it
directly call getrandom() or does something else?
For the invocation IDs we use getrandom() with default args
(i.e. blocking behaviour). Similar for all other cases where we pick
128bit random identifiers (also known as uuids).
For the hashtable seeds we use classic /dev/urandom (i.e. entropy from
a possibly non-initialized pool) since it's OK if those seeds are
crappy initially, as long as they get better over time, since we
reseed if we see too many hash collisions.
We never use /dev/random or GRND_RANDOM.
Lennart Poettering, Berlin