The editorial acknowledges that a single missing value out of 2^64 wouldn't fail any NIST SP 800-22 test and wouldn't leak meaningful entropy in real cryptographic protocols. But it argues the significance lies in what the anomaly reveals about AMD's on-die entropy pipeline — either an overly aggressive stuck-at health filter or a structural bias in the post-processing whitener — both of which are documented deviations from a properly designed hardware RNG.
The original forum post documents billions of RDRAND/RDSEED calls across multiple Ryzen and EPYC generations that never once produced 0x0, while an Intel machine in the same test produced the statistically expected trickle of zeros. The simplicity and reproducibility of the test — a tight loop counting zero outputs — is presented as evidence that this is a genuine hardware behavior, not a testing artifact.
Surfaced the flatassembler thread to Hacker News with the framing 'AMD's random number generator can't generate a 0?' — treating the observation as a legitimate anomaly worth broader technical scrutiny. The 256-point score and 197 comments suggest the community agrees the finding is credible enough to warrant investigation.
A post on the flat assembler forum from user Revolution documented something that shouldn't be possible from a properly designed hardware random number generator: AMD's `RDRAND` and `RDSEED` instructions, tested across Ryzen and EPYC parts spanning several generations, appear to never output a value of zero. Not "rarely." Zero times, across runs large enough that a uniform 64-bit source should have produced a handful of zeros by chance.
The test is embarrassingly simple. Loop `RDRAND` (or `RDSEED`) a few billion times, count how many results equal `0x0000000000000000`, and print the number. On a genuinely uniform 64-bit generator, the expected count is `N / 2^64` — so at a few billion draws you'd see essentially none most runs, but occasionally one. The forum thread reports the count staying pinned at zero across multiple machines and multiple runs, while an Intel box in the same test produces the statistically-expected trickle of zeros.
If the observation holds up to independent replication, it means AMD's on-die entropy pipeline is either explicitly filtering the all-zero output or the post-processing whitener has a structural bias that makes 0x0 unreachable. Both are plausible: hardware RNG designs frequently include a health test that discards "stuck" outputs, and the all-zero pattern is the canonical stuck-at fault signature. Filtering it aggressively enough — say, discarding any block that comes out all-zero regardless of context — would produce exactly this behavior.
On its face, this sounds like a rounding error dressed up as a scandal. One value out of 2^64 is a bias so small that no statistical randomness test in NIST SP 800-22 would flag it, and no cryptographic protocol built on top of RDRAND would leak a meaningful bit because of it. If you're using RDRAND to seed a userspace PRNG or feed a TLS handshake, the sky is not falling.
But the *reason* it matters isn't the missing zero. It's that a documented deviation from the ISA contract has apparently sat inside shipping AMD silicon for multiple generations without anyone noticing publicly. `RDRAND` is specified to return a uniformly-distributed random value from a DRBG that is itself seeded from a hardware entropy source. "Uniform" means every 64-bit value has equal probability. Zero is a 64-bit value. If it can never come out, the distribution isn't uniform, and any downstream analysis that assumes uniformity is technically wrong — even if the practical consequences round to nothing.
The secondary concern is what this reveals about the health-check plumbing. AMD's SP 800-90B compliance documentation describes continuous health tests that watch for stuck-at faults and repetition patterns. If the mitigation for a stuck-at-zero fault is "drop any all-zero block silently and try again," that's a reasonable engineering choice — but it should be documented, because it changes the statistical guarantees you're getting. The community reaction on Hacker News split roughly along the expected lines: cryptographers shrugging ("the bias is negligible"), systems people annoyed ("then document it"), and a smaller camp asking the sharper question — what *else* is being silently filtered that we haven't tested for?
The right lesson isn't "AMD's RNG is broken." It's that hardware RNGs are opaque black boxes whose actual output distribution nobody outside the vendor has really measured at scale. Linux's `/dev/urandom` mixes RDRAND with other entropy sources precisely because kernel developers have never trusted any single hardware RNG — including Intel's, whose Ivy Bridge implementation was the subject of similar skepticism a decade ago. That defense-in-depth posture looks smarter every time a story like this surfaces.
If you're calling `RDRAND` directly from application code to generate cryptographic keys, stop. This was already the recommended practice — the Linux kernel, BoringSSL, OpenSSL, and every major cryptographic library mix hardware RNG output with other sources for exactly this reason. The missing-zero anomaly doesn't change the recommendation; it reinforces it.
If you're on Linux and using `getrandom(2)` or `/dev/urandom`, you're fine. The kernel's entropy pool mixes RDRAND with interrupt timing, keyboard/network jitter, and other sources through a cryptographic mixing function. A bias in one input can't propagate to the output as long as at least one input is genuinely unpredictable. This is exactly the threat model the mixing was designed for.
If you build FIPS-certified products or ship anything into regulated environments, this is worth an internal ticket. FIPS 140-3 and Common Criteria evaluations both depend on entropy source documentation matching observed behavior. If AMD's public documentation says RDRAND is uniform and the silicon says otherwise, your compliance story has a small footnote that auditors will eventually ask about. Better to have the answer ready than to be surprised.
For the vast middle — web apps, backend services, most infrastructure code — this changes nothing. Your session tokens are safe, your UUIDs are safe, your JWTs are safe. The bias is somewhere around one part in 2^64, which is smaller than the probability that a cosmic ray will flip a bit in your RAM during the same operation.
The interesting follow-up isn't from AMD — it's from whoever runs the same test on more silicon. Intel, ARM, Apple Silicon, RISC-V vendors, the hardware RNGs baked into SmartNICs and HSMs — all of them deserve the same treatment. If "never returns zero" turns out to be a widespread pattern rather than an AMD-specific quirk, the cryptographic engineering community owes itself a serious conversation about what "uniform" actually means in shipping silicon, and whether the vendor documentation everyone has been citing for two decades is describing the chip you think you're using.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.