On Mi, 18.09.19 00:10, Martin Steigerwald (martin@xxxxxxxxxxxx) 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
