AMD's RDRAND16 instruction can't generate zero on some Zen CPUs
Users discover AMD processors skip 0 when generating 16-bit random numbers, a flaw that evaded hardware validation.
What to know
- AMD's RDRAND16 instruction on Zen 2 and some Zen 3 CPUs never generates zero values, instead falsely signaling an error condition.
- The flaw appears to be in the carry-flag logic, not the underlying entropy generator—the instruction produces zero internally but discards it via incorrect error signaling.
- The bug has limited real-world impact; cryptographic code seeds software CSPRNGs with hardware randomness rather than using it directly.
- This is at least the second known RDRAND defect on Zen 2 (a prior bug generated all 1s); AMD has released security bulletin SB-7055 acknowledging the issue.
The dispute Whether the bug was fixed after Zen 2 or persists into Zen 3—one Zen 3 user could not reproduce it while another on a later Zen 3 chip reported generating zeros normally. · positions read across 19 posts and comments
The bug is real but has minimal practical impact because crypto code uses hardware RNG only as a seed for software CSPRNGs.
-
“Embarrassing, but probably little practical impact, since these hardware random numbers are typically not used directly and instead seed a CSPRNG.”
CodesInChaos · Hacker News ↗
The bug's existence and escape through validation raises questions about AMD's testing rigor.
-
“I always wonder how hardware bugs like this happen with the sheer amount of hardware validation that's done. It'd be fascinating to know how it slipped through the cracks, though I know almost nothing about this side of the industry sadly”
20k · Hacker News ↗
The bug is specific to RDRAND16; 32-bit and 64-bit variants appear unaffected, and the flaw stems from carry-flag misbehavior rather than entropy failure.
-
“OK, update, I can reproduce it with rdrand16, rdrand32 is fine but rdrand16 can never generate all 0s.”
jstanley · Hacker News ↗
jstanley Zen 2 CPU owner, bug reproducer0x000xca0xfe Hardware/cryptography developerAMD CPU manufacturer
How it unfolded 4 developments, newest first · click a bar or a number to jump articlespostscomments
-
4
Bug identified as carry-flag misfire, not entropy failure
A commenter clarifies that RDRAND16 likely produces zero correctly internally, but sets the carry flag (CF) to 0 erroneously when zero emerges, causing retry logic to discard the valid result.
“But it looks like the rdrand16 instruction can produce zeros just fine, it just sets CF=0 erroneously (indicating an error and that the user program should retry).”
— 0x000xca0xfe -
Really interesting and surprising article. As a workaround, if you're skeptical about an RNG you can implement an algorithm using AES-CTR and putting some entropy in by hand, like mashing on the keyboard a lot. (Like, a lot though.) You can then keep encrypting it, returning some of the ciphertext as the "random" values and rekeying with the rest…
2 more of the top 3 · 9 posts in this stretch
-
A
AMD's random number generator (RDSEED, RDRAND) cannot generate a 0. https:// board.flatassembler.net/topic. php?t=24261 # crypto # cryptography
-
Not sure if this finding is new, but the author from FASM Thread apparently has a Zen 2 (He doesn't directly mention anything besides "Ryzen 7", some other poster mentions it is a 4800HS). There were a number of articles about RDRAND being broken on Zen 2 and earlier generations but fixed via Microcode from about 6 years…
-
-
background
Users discover RDRAND16 bug across AMD Zen processors — Developers on Hacker News report testing AMD's RDRAND16 instruction and finding it unable to generate zero values on Zen 2 and some Zen 3 CPUs. One user on a Ryzen 5 3600 (Zen 2) confirmed the bug; another on a Zen 4 (7840U) could not reproduce it.
-
3
Zen 4 user reproduces no issue with RDRAND16
A Zen 4 user (7840U) runs a test with GCC intrinsics and confirms zero values generate normally on that architecture, showing the bug is not universal across all Zen generations.
-
Zen 4 reporting in. I'm unable to reproduce it (7840U). $ ./a.out | rg '\b\-?\d\b' | sort -n | uniq -c 15281 -2 15192 -1 15273 0 15243 1 15269 2 I used the GCC intrinsic ( _rdrand16_step ), #include <immintrin.h> short rdrand16() { // gcc -mrdrnd short ret; while (1 != _rdrand16_step(&ret)) { } return ret; }
1 more of the top 2 · 2 posts in this stretch
-
I have a couple questions:Looks like they tried 16-bit numbers. Does the odd behavior happen also on 32 and 64 (might take a long time to check - I'd start scratching my head after a couple hundred years of no zeroes) ones? Is the zero masking as some other fixed number, increasing its output count? Is RDRAND implemented as multiple reads of an…
-
-
2
AMD security bulletin disclosed for hardware RNG flaw
An AMD security bulletin (SB-7055) is cited as official acknowledgment of the RDRAND16 issue.
“I always wonder how hardware bugs like this happen with the sheer amount of hardware validation that's done. It'd be fascinating to know how it slipped through the cracks, though I know almost nothing about this side of the industry sadly…”
— 20k, HN commenter · source -
This is why I use, in security critical contents of my software (where the numbers have to be computationally infeasible to produce), a type of random number generator called an XOF (extendable-output function).It takes entropy from multiple different sources, makes it all input to the XOF, then the XOF uses cryptography to output a stream that…
2 more of the top 3 · 5 posts in this stretch
-
I always wonder how hardware bugs like this happen with the sheer amount of hardware validation that's done. It'd be fascinating to know how it slipped through the cracks, though I know almost nothing about this side of the industry sadly
-
Does rdrand32 and then taking the lowest 16 bits of its result yield any zeroes?Basically I'm wondering if it's a bug in the version of the instruction that writes to a 16-bit reg, or a bug in the underlying RNG
-
-
1
Zen 3 user reports intermittent zero generation
A user on Zen 3 reports being able to generate 16-bit zeros, suggesting the bug may have been fixed after Zen 2.
“I'm getting 16-bit zeros on my Zen 3 chip (+1:3821, 0:3893, -1:3895), I will wait to get some statistically significant samples for the 32-bit values and update the forum thread. Maybe it was fixed after Zen 2?”
— matja -
This is not the first RNG bug on Zen 2, I recall after I first got mine that some application or other would quit immediately at startup because rdrand always returned -1, i.e. all 1s. It was fixed with a microcode update.Do we now learn that they fixed "always generate all 1s" with "never generate all 0s"??EDIT: I've been unable to reproduce the…
2 more of the top 3 · 3 posts in this stretch
-
I'm getting 16-bit zeros on my Zen 3 chip (+1:3821, 0:3893, -1:3895), I will wait to get some statistically significant samples for the 32-bit values and update the forum thread. Maybe it was fixed after Zen 2?
-
Embarrassing, but probably little practical impact, since these hardware random numbers are typically not used directly and instead seed a CSPRNG.
-
Also covered reported alongside — the timeline has no entry for these yet
-
first by HN Best, 1d ago · also HN Frontpage
What people are saying 7 voices from 1 site · best of 19 · verbatim
- Does the bug affect rdrand32 and rdrand64, or only the 16-bit variant?
- Was this bug fixed after Zen 2, or does it vary by specific Zen 3 SKU?
- Why did AMD's hardware validation suite miss a statistically obvious failure in a core security primitive?
- Yesterday
-
Another random boundary case: SQLite's RANDOM() won't generate the minimum i64 value, because: i64 MIN: −2⁶³ i64 MAX: 2⁶³-1 Since RANDOM() is used with ABS(), that floor value is lopped off. (Can you imagine if it weren't, and you got a bug 1 in every 2⁶⁴ calls?)
-
AMD's random number generator probably can't generate a 0 ;)Anyways, I think it is good practice to consider the output of any hardware RNG to be biased and to only use it indirectly as a source of entropy. The actual numbers come from a PRNG, secure of not depending on your needs, that have a guaranteed distribution.It can still cause problems if…
- Sep 22
-
I remember setting up a new git CI build server many years ago, which at the time rather quickly started failing build pipelines in a nodejs css frontend build script, turns out there was something funky with the AMD processor's RDRAND. A motherboard BIOS flash update fixed it.
-
I wonder if this, or something like it, is the issue:> 32-bit XorShift should usually not be used to produce 32-bit numbers, because it only produces each number once, and never produces zero.(From this page I found while trying to see if this was a common flaw in PRNGs: https://www.pcg-random.org/other-rngs.html )
-
If I remember correctly, we had a setting in every Linux server we owned to remove CPU as a RNG seeder for the kernel because of those bugs with AMD CPUs.I.e., we had `random.trust_cpu=off nordrand` in `GRUB_CMDLINE_LINUX`.
-
I can reproduce it too with rdrand16 on Zen2.But it looks like the rdrand16 instruction can produce zeros just fine, it just sets CF=0 erroneously (indicating an error and that the user program should retry).So keep that in mind when you try to reproduce it too and use some abstraction that could implement retries internally.
-
Chased a similar bug in a KDF once and only caught it by histogramming the 16 bit draws, statistical suites never flagged it.