AMD's random number generator can't generate a 0?

Original Article ↗ Hacker News Discussion ↗

AMD CPUs appear to have a bug where certain generations’ hardware random number instruction (notably Zen 2 `rdrand16`) almost never produce a true 0, or mislabel zero outputs as failures, raising questions about bias in values that are supposed to be uniformly random. Commenters note that most systems don’t use these hardware numbers directly but as seeds for stronger software RNGs, and that modern kernels mix multiple entropy sources so a single flawed source should not be catastrophic—though history shows even small RNG biases can become real vulnerabilities. The thread broadens into whether to trust opaque, vendor-implemented RNGs at all, how kernels protect against bad or malicious entropy sources, and the risks of rolling custom cryptographic RNGs in user space.

Nature of the AMD RNG bug

  • Reports focus on Zen 1/2-era CPUs where RDRAND16 appears never to return 0 while RDRAND32/64 do.
  • Closer testing shows RDRAND16 can internally generate 0, but when it does, the carry flag (CF) is set to 0, signalling “failure / retry.”
    • Typical wrappers then discard these results and loop, so user code effectively never sees a 16‑bit zero.
  • The rate of CF=0 “failures” aligns with 1/65536 and all such failures return 0, suggesting a systematic behavior rather than pure absence of 0.
  • Newer generations (Zen 3/4) don’t show the issue in tests; Zen 5 has a related RDSEED erratum where an all‑zero result with CF=1 can lead to similar workarounds that reintroduce “never zero” behavior.

Relation to past hardware RNG issues

  • Earlier Zen 2 microcode bugs caused RDRAND to always return all 1s until updated.
  • There is concern that microcode “fixes” may have traded one error pattern (all 1s) for another (no 0s).
  • Some system operators disabled trusting CPU RNG in the Linux kernel due to these kinds of AMD glitches.

Security impact and randomness quality

  • One camp: practical impact is minimal because:
    • Hardware RNG is normally only used to seed a CSPRNG such as the kernel pool.
    • Losing 1 value out of 2^16 (or 2^32/2^64) barely shrinks the key space.
  • Other camp: any systematic bias is a red flag:
    • Cryptographic history shows small biases can become exploitable in some protocols.
    • Even if this specific bias is likely harmless, dismissing such flaws is seen as risky.
  • Thread revisits basics:
    • Desired output is a discrete uniform distribution; “never 0” is bias.
    • Predictability is not just “not always same value,” but “no value or predicate is favoured.”

Mixing entropy and trusting hardware

  • Broad agreement: don’t rely on a single opaque hardware RNG; mix multiple sources via a strong construction (CSPRNG, sponge, or XOF).
  • Debate over:
    • Whether adding a “bad” but non-malicious source can ever make a good pool worse (most say no; others cite attacks where a malicious source that sees other inputs can bias output).
    • Whether it’s better to always use kernel interfaces (/dev/urandom, getentropy/getrandom) versus rolling userland RNGs.
  • Some argue strongly against custom RNGs (history of real-world failures); others defend mature, long‑tested custom XOF‑based designs, especially for cross‑platform or embedded use.

Validation, testing, and how this slipped through

  • Several commenters are surprised such a simple distribution bug passed hardware validation; hypotheses include:
    • Incomplete verification plans (no specific coverage bin for 0).
    • Off‑by‑one errors.
  • Practical note: histogramming all 65,536 16‑bit outputs is an easy black‑box test that should catch this class of error.