4 ms·

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 dis

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.

garaetjjte 6y ago
>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/linux.git/commit/?id=50ee7529ec45 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
altfredd 6y ago
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
CJefferson 6y ago
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)

garaetjjte 6y ago

>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/linux.git/commit/?id=50ee7529ec45 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

altfredd 6y ago

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

CJefferson 6y ago

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)