5 ms·

Linux entropy pool is designed to accept and mix different low-quality entropy sources and has explicit workarounds for problems like these. Systemd is literal

Linux entropy pool is designed to accept and mix different low-quality entropy sources and has explicit workarounds for problems like these. Systemd is literally the only software, that has this problem. I am not aware of any other software, that uses rdrand and expects high-quality cryptography-grade randomness. Precisely, because is does not work. Intel CPUs used to have very similar issues with rdrand and so did AMD. Furthermore, CPU implementation of rdrand is a very attractive targets for state backdoors, so most sensible developers either follow the "GNUPG way" (ask for randomness from user) or simply read from /dev/random. The rdrand instruction is great for games, because it allows to make white noise without complex algorithms and system call overhead. It is also handy for few situations, like interrupt handlers, when you needs to create some semi-random value without using stack space or calling into outside code. Unfortunately, when it was introduced, rdrand was documented to generate "cryptographically strong random numbers" (did Intel developers ever knew, what that means?) Of course, most actual cryptography experts didn't buy into that. As a consequence, and because multi-platform software needed to have it's own RNG anyway, the instruction remained largely unused for actual cryptography. Unused = untested and sometimes broken. If I were in systemd developer's place, I would not hinge bootability of my systems on something like that.

ficklepickle 6y ago
It's an early boot problem. If they tried to use the kernel facilities it would block, making boot take much longer. Fixed in recent kernel versions. I know it's in vogue to rip on systemd, but let's at least try to be fair.
- freeone3000 6y ago
  Somehow sysv init never ran into this issue. Maybe it's okay to let the kernel seed its entropy pool before initializing your hash table.
  - Foxboron 6y ago
    I don't think sysvinit made use of hashtables, and if they did they would probably hit the same snag.
    - aidenn0 6y ago
      sysvinit (or rather RC systems often built on top of it) tended to use trees (most often the filesystem). Unlike hash-tables, trees don't need randomness to guarantee asymptotic behavior.
Dylan16807 6y ago
> The rdrand instruction is great for games, because it allows to make white noise without complex algorithms and system call overhead. Eh. You're looking at hundreds of cycles per use. That makes it slower than a secure software RNG, let alone an insecure one.
- jcelerier 6y ago
  Right ! For games if it's for e.g. texture noise or things like that you shouldn't need more than a couple xors and shifts
tadfisher 6y ago
> Systemd is literally the only software, that has this problem. I am not aware of any other software, that uses rdrand and expects high-quality cryptography-grade randomness. Please seek out and understand the reasons behind calling RDRAND in systemd before making statements like these. "High-quality crytography-grade randomness" is explicitly not required for the purposes of the PRNG at boot-time, which include UUID generation and seeding hash tables. https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbfeb75b530539c4834f6a4/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbf...
- tremon 6y ago
  Why would the boot process need to generate UUID's? And even if it does, why would it need truly random UUIDv4s instead of simple UUIDv1s?
  - LukeShu 6y ago
    UUIDv1s (RFC 4122 §4.2.1) also rely on several things that are even less likely to be available at early-boot: - The clock might not be initialized; the justification for using rdrand specifically calls out embedded systems; embedded systems are also likely to have clocks that reset to some date every boot and get fixes as part of the boot process that happens later. - The "node ID" (nominally, a MAC address) udev has not started yet and therefore has not initialized the network cards yet (in fact, if you configure it to randomize your MAC address (for privacy), the random_bytes() routine being discussed is the one that it will use to generate the MAC!) The filesystem hasn't yet been mounted, it can't use /etc/machine-id or anything like that either.

ficklepickle 6y ago

It's an early boot problem. If they tried to use the kernel facilities it would block, making boot take much longer. Fixed in recent kernel versions. I know it's in vogue to rip on systemd, but let's at least try to be fair.

freeone3000 6y ago
Somehow sysv init never ran into this issue. Maybe it's okay to let the kernel seed its entropy pool before initializing your hash table.
- Foxboron 6y ago
  I don't think sysvinit made use of hashtables, and if they did they would probably hit the same snag.
  - aidenn0 6y ago
    sysvinit (or rather RC systems often built on top of it) tended to use trees (most often the filesystem). Unlike hash-tables, trees don't need randomness to guarantee asymptotic behavior.

Dylan16807 6y ago

> The rdrand instruction is great for games, because it allows to make white noise without complex algorithms and system call overhead. Eh. You're looking at hundreds of cycles per use. That makes it slower than a secure software RNG, let alone an insecure one.

jcelerier 6y ago
Right ! For games if it's for e.g. texture noise or things like that you shouldn't need more than a couple xors and shifts

tadfisher 6y ago

> Systemd is literally the only software, that has this problem. I am not aware of any other software, that uses rdrand and expects high-quality cryptography-grade randomness. Please seek out and understand the reasons behind calling RDRAND in systemd before making statements like these. "High-quality crytography-grade randomness" is explicitly not required for the purposes of the PRNG at boot-time, which include UUID generation and seeding hash tables. https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbfeb75b530539c4834f6a4/src/basic/random-util.c#L40-L98 https://github.com/systemd/systemd/blob/61bd7d1ed595a98e5fbf...

tremon 6y ago
Why would the boot process need to generate UUID's? And even if it does, why would it need truly random UUIDv4s instead of simple UUIDv1s?
- LukeShu 6y ago
  UUIDv1s (RFC 4122 §4.2.1) also rely on several things that are even less likely to be available at early-boot: - The clock might not be initialized; the justification for using rdrand specifically calls out embedded systems; embedded systems are also likely to have clocks that reset to some date every boot and get fixes as part of the boot process that happens later. - The "node ID" (nominally, a MAC address) udev has not started yet and therefore has not initialized the network cards yet (in fact, if you configure it to randomize your MAC address (for privacy), the random_bytes() routine being discussed is the one that it will use to generate the MAC!) The filesystem hasn't yet been mounted, it can't use /etc/machine-id or anything like that either.