Hacker News Reader

Comment by espadrine | Hacker News Reader

Isn’t that an even bigger problem, though, if Linux’ entropy pool gets polluted by an inentropic source that still increments its entropy counter?

I recall discussions to maybe rely on something like jitter entropy when the pool is empty and getentropy() is called.

View on HN

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.

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.

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.

I don't think sysvinit made use of hashtables, and if they did they would probably hit the same snag.

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.

> 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.

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

> 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/61bd7d1ed595a98e5fbf...

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?

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.

>on something like jitter entropy when the pool is empty and getentropy() is called

This ended up being implemented in 5.4 kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

When it comes to random seeding, I've always thought the best option would be to use every source available, and hope that at least one is high quality. If we combine:

* RDRAND * Seed from previous boot * Jitter * Result of every sensor (for example temperature) attached to the machine * Seed from hypervisor (if we are in a VM) * Time & Date * Any information about the physical computer we are on (attached hardware)

Reply on news.ycombinator.com