Re: Linux 5.3-rc8

[Lennart Poettering <mzxreary@0pointer.de>]

On Mi, 18.09.19 00:10, Martin Steigerwald (martin@lichtvoll.de) wrote:

> > getrandom() will never "consume entropy" in a way that will block any
> > users of getrandom(). If you don't have enough collected entropy to
> > seed the rng, getrandom() will block. If you do, getrandom() will
> > generate as many numbers as you ask it to, even if no more entropy is
> > ever collected by the system. So it doesn't matter how many clients
> > you have calling getrandom() in the boot process - either there'll be
> > enough entropy available to satisfy all of them, or there'll be too
> > little to satisfy any of them.
>
> Right, but then Systemd would not use getrandom() for initial hashmap/
> UUID stuff since it

Actually things are more complex. In systemd there are four classes of
random values we need:

1. High "cryptographic" quality. There are very few needs for this in
   systemd, as we do very little in this area. It's basically only
   used for generating salt values for hashed passwords, in the
   systemd-firstboot component, which can be used to set the root
   pw. systemd uses synchronous getrandom() for this. It does not use
   RDRAND for this.

2. High "non-cryptographic" quality. This is used for example for
   generating type 4 uuids, i.e uuids that are supposed to be globally
   unique, but aren't key material. We use RDRAND for this if
   available, falling back to synchronous getrandom(). Type 3 UUIDs
   are frequently needed by systemd, as we assign a uuid to each
   service invocation implicitly, so that people can match logging
   data and such to a specific instance and runtime of a service.

3. Medium quality. This is used for seeding hash tables. These may be
   crap initially, but should not be guessable in the long
   run. /dev/urandom would be perfect for this, but the mentioned log
   message sucks, hence we use RDRAND for this if available, and fall
   back to /dev/urandom if that isn't available, accepting the log
   message.

4. Crap quality. There are only a few uses of this, where rand_r() is
   is OK.

Of these four case, the first two might block boot. Because the first
case is not common you won't see blocking that often though for
them. The second case is very common, but since we use RDRAND you
won't see it on any recent Intel machines.

Or to say this all differently: the hash table seeding and the uuid
case are two distinct cases in systemd, and I am sure they should be.

Lennart

--
Lennart Poettering, Berlin