random-util: remove RDRAND usage

/dev/urandom is seeded with RDRAND. Calling genuine_random_bytes(...,
..., 0) will use /dev/urandom as a last resort. Hence, we gain nothing
here by having our own RDRAND wrapper, because /dev/urandom already is
based on RDRAND output, even before /dev/urandom has fully initialized.

Furthermore, RDRAND is not actually fast! And on each successive
generation of new x86 CPUs, from both AMD and Intel, it just gets
slower.

This commit simplifies things by just using /dev/urandom in cases where
we before might use RDRAND, since /dev/urandom will always have RDRAND
mixed in as part of it.

And above where I say "/dev/urandom", what I actually mean is
GRND_INSECURE, which is the same thing but won't generate warnings in
dmesg.

1 files changed, 4 insertions, 163 deletions

diff --git a/src/basic/random-util.c b/src/basic/random-util.c
index 3891058cbc..f2e68fcddd 100644
--- a/src/basic/random-util.c
+++ b/src/basic/random-util.c
@@ -35,137 +35,11 @@
 
 static bool srand_called = false;
 
-int rdrand(unsigned long *ret) {
-
-        /* So, you are a "security researcher", and you wonder why we bother with using raw RDRAND here,
-         * instead of sticking to /dev/urandom or getrandom()?
-         *
-         * Here's why: early boot. On Linux, during early boot the random pool that backs /dev/urandom and
-         * getrandom() is generally not initialized yet. It is very common that initialization of the random
-         * pool takes a longer time (up to many minutes), in particular on embedded devices that have no
-         * explicit hardware random generator, as well as in virtualized environments such as major cloud
-         * installations that do not provide virtio-rng or a similar mechanism.
-         *
-         * In such an environment using getrandom() synchronously means we'd block the entire system boot-up
-         * until the pool is initialized, i.e. *very* long. Using getrandom() asynchronously (GRND_NONBLOCK)
-         * would mean acquiring randomness during early boot would simply fail. Using /dev/urandom would mean
-         * generating many kmsg log messages about our use of it before the random pool is properly
-         * initialized. Neither of these outcomes is desirable.
-         *
-         * Thus, for very specific purposes we use RDRAND instead of either of these three options. RDRAND
-         * provides us quickly and relatively reliably with random values, without having to delay boot,
-         * without triggering warning messages in kmsg.
-         *
-         * Note that we use RDRAND only under very specific circumstances, when the requirements on the
-         * quality of the returned entropy permit it. Specifically, here are some cases where we *do* use
-         * RDRAND:
-         *
-         *         • UUID generation: UUIDs are supposed to be universally unique but are not cryptographic
-         *           key material. The quality and trust level of RDRAND should hence be OK: UUIDs should be
-         *           generated in a way that is reliably unique, but they do not require ultimate trust into
-         *           the entropy generator. systemd generates a number of UUIDs during early boot, including
-         *           'invocation IDs' for every unit spawned that identify the specific invocation of the
-         *           service globally, and a number of others. Other alternatives for generating these UUIDs
-         *           have been considered, but don't really work: for example, hashing uuids from a local
-         *           system identifier combined with a counter falls flat because during early boot disk
-         *           storage is not yet available (think: initrd) and thus a system-specific ID cannot be
-         *           stored or retrieved yet.
-         *
-         *         • Hash table seed generation: systemd uses many hash tables internally. Hash tables are
-         *           generally assumed to have O(1) access complexity, but can deteriorate to prohibitive
-         *           O(n) access complexity if an attacker manages to trigger a large number of hash
-         *           collisions. Thus, systemd (as any software employing hash tables should) uses seeded
-         *           hash functions for its hash tables, with a seed generated randomly. The hash tables
-         *           systemd employs watch the fill level closely and reseed if necessary. This allows use of
-         *           a low quality RNG initially, as long as it improves should a hash table be under attack:
-         *           the attacker after all needs to trigger many collisions to exploit it for the purpose
-         *           of DoS, but if doing so improves the seed the attack surface is reduced as the attack
-         *           takes place.
-         *
-         * Some cases where we do NOT use RDRAND are:
-         *
-         *         • Generation of cryptographic key material 🔑
-         *
-         *         • Generation of cryptographic salt values 🧂
-         *
-         * This function returns:
-         *
-         *         -EOPNOTSUPP → RDRAND is not available on this system 😔
-         *         -EAGAIN     → The operation failed this time, but is likely to work if you try again a few
-         *                       times ♻
-         *         -EUCLEAN    → We got some random value, but it looked strange, so we refused using it.
-         *                       This failure might or might not be temporary. 😕
-         */
-
-#if defined(__i386__) || defined(__x86_64__)
-        static int have_rdrand = -1;
-        unsigned long v;
-        uint8_t success;
-
-        if (have_rdrand < 0) {
-                uint32_t eax, ebx, ecx, edx;
-
-                /* Check if RDRAND is supported by the CPU */
-                if (__get_cpuid(1, &eax, &ebx, &ecx, &edx) == 0) {
-                        have_rdrand = false;
-                        return -EOPNOTSUPP;
-                }
-
-/* Compat with old gcc where bit_RDRND didn't exist yet */
-#ifndef bit_RDRND
-#define bit_RDRND (1U << 30)
-#endif
-
-                have_rdrand = !!(ecx & bit_RDRND);
-
-                if (have_rdrand > 0) {
-                        /* Allow disabling use of RDRAND with SYSTEMD_RDRAND=0
-                           If it is unset getenv_bool_secure will return a negative value. */
-                        if (getenv_bool_secure("SYSTEMD_RDRAND") == 0) {
-                                have_rdrand = false;
-                                return -EOPNOTSUPP;
-                        }
-                }
-        }
-
-        if (have_rdrand == 0)
-                return -EOPNOTSUPP;
-
-        asm volatile("rdrand %0;"
-                     "setc %1"
-                     : "=r" (v),
-                       "=qm" (success));
-        msan_unpoison(&success, sizeof(success));
-        if (!success)
-                return -EAGAIN;
-
-        /* Apparently on some AMD CPUs RDRAND will sometimes (after a suspend/resume cycle?) report success
-         * via the carry flag but nonetheless return the same fixed value -1 in all cases. This appears to be
-         * a bad bug in the CPU or firmware. Let's deal with that and work-around this by explicitly checking
-         * for this special value (and also 0, just to be sure) and filtering it out. This is a work-around
-         * only however and something AMD really should fix properly. The Linux kernel should probably work
-         * around this issue by turning off RDRAND altogether on those CPUs. See:
-         * https://github.com/systemd/systemd/issues/11810 */
-        if (v == 0 || v == ULONG_MAX)
-                return log_debug_errno(SYNTHETIC_ERRNO(EUCLEAN),
-                                       "RDRAND returned suspicious value %lx, assuming bad hardware RNG, not using value.", v);
-
-        *ret = v;
-        return 0;
-#else
-        return -EOPNOTSUPP;
-#endif
-}
-
 int genuine_random_bytes(void *p, size_t n, RandomFlags flags) {
         static int have_syscall = -1;
         _cleanup_close_ int fd = -1;
 
-        if (FLAGS_SET(flags, RANDOM_BLOCK | RANDOM_ALLOW_RDRAND))
-                return -EINVAL;
-
-        /* Gathers some high-quality randomness from the kernel (or potentially mid-quality randomness from
-         * the CPU if the RANDOM_ALLOW_RDRAND flag is set). This call won't block, unless the RANDOM_BLOCK
+        /* Gathers some high-quality randomness from the kernel. This call won't block, unless the RANDOM_BLOCK
          * flag is set. If it doesn't block, it will still always return some data from the kernel, regardless
          * of whether the random pool is fully initialized or not. When creating cryptographic key material you
          * should always use RANDOM_BLOCK. */
@@ -212,34 +86,6 @@ int genuine_random_bytes(void *p, size_t n, RandomFlags flags) {
                 }
         }
 
-        if (FLAGS_SET(flags, RANDOM_ALLOW_RDRAND)) {
-                /* Try x86-64' RDRAND intrinsic if we have it. We only use it if high quality randomness is
-                 * not required, as we don't trust it (who does?). Note that we only do a single iteration of
-                 * RDRAND here, even though the Intel docs suggest calling this in a tight loop of 10
-                 * invocations or so. That's because we don't really care about the quality here. We
-                 * generally prefer using RDRAND if the caller allows us to, since this way we won't upset
-                 * the kernel's random subsystem by accessing it before the pool is initialized (after all it
-                 * will kmsg log about every attempt to do so). */
-                for (;;) {
-                        unsigned long u;
-                        size_t m;
-
-                        if (rdrand(&u) < 0) {
-                                /* OK, this didn't work, let's go with /dev/urandom instead */
-                                break;
-                        }
-
-                        m = MIN(sizeof(u), n);
-                        memcpy(p, &u, m);
-
-                        p = (uint8_t*) p + m;
-                        n -= m;
-
-                        if (n == 0)
-                                return 0; /* Yay, success! */
-                }
-        }
-
         fd = open("/dev/urandom", O_RDONLY|O_CLOEXEC|O_NOCTTY);
         if (fd < 0)
                 return errno == ENOENT ? -ENOSYS : -errno;
@@ -257,8 +103,6 @@ void initialize_srand(void) {
 #if HAVE_SYS_AUXV_H
         const void *auxv;
 #endif
-        unsigned long k;
-
         if (srand_called)
                 return;
 
@@ -283,9 +127,6 @@ void initialize_srand(void) {
         x ^= (unsigned) now(CLOCK_REALTIME);
         x ^= (unsigned) gettid();
 
-        if (rdrand(&k) >= 0)
-                x ^= (unsigned) k;
-
         srand(x);
         srand_called = true;
 
@@ -339,8 +180,8 @@ void random_bytes(void *p, size_t n) {
          *
          * What this function will do:
          *
-         *         • This function will preferably use the CPU's RDRAND operation, if it is available, in
-         *           order to return "mid-quality" random values cheaply.
+         *         • Use getrandom(GRND_INSECURE) or /dev/urandom, to return high-quality random values if
+         *           they are cheaply available, or less high-quality random values if they are not.
          *
          *         • This function will return pseudo-random data, generated via libc rand() if nothing
          *           better is available.
@@ -363,7 +204,7 @@ void random_bytes(void *p, size_t n) {
          * This function is hence not useful for generating UUIDs or cryptographic key material.
          */
 
-        if (genuine_random_bytes(p, n, RANDOM_ALLOW_RDRAND) >= 0)
+        if (genuine_random_bytes(p, n, 0) >= 0)
                 return;
 
         /* If for some reason some user made /dev/urandom unavailable to us, or the kernel has no entropy, use a PRNG instead. */