AMD's random number generator can't generate a 0?
Investigation: Potential Zero-Generation Bug in AMD Hardware RNG
This report summarizes a technical discussion from the flat assembler (FASM) community regarding a peculiar behavior observed in AMD processors concerning hardware-based random number generation.
🚨 The Discovery
User Jessé (from Brazil) reported a potential bug affecting AMD CPUs—specifically noting it might be isolated to the Zen 2 architecture. While developing assembly code for data visualization charts, Jessé discovered that the hardware instructions rdrand and rdseed appear incapable of producing a value of 0 when a specific small size is requested.
Comparison of Behavior
The following table illustrates the difference in behavior between processor vendors:
| Feature | Intel Processors | AMD Processors |
|---|---|---|
| Can generate 0 (16-bit) | ✅ Yes | ❌ No |
| Chart Base Scaling | Scales beyond 0 | Stuck at 0 |
| RNG Reliability | Standard |
🛠️ The Technical Evidence
To prove this, Jessé developed a chart test application (gtk4-bargraph.tar.gz).
Application Details
- Purpose: A showcase of console data rendering at arbitrary positions under Linux CLI.
- Requirement: Must be compiled with the
fastcall_v1macro kit. - Visual Indicators:
- 🔴 Red Bar:
rdrandresults. - 🔵 Blue Bar:
rdseedresults. - 🟢 Green Bar: A custom TSC-based (Time Stamp Counter) method.
- 🔴 Red Bar:
Observation: On AMD hosts, the green bar (TSC method) changes colors and the chart scales normally, but the red and blue bars never indicate the generation of a zero.
Logic Flow of the Bug
💡 The Workaround
Jessé found a way to bypass this limitation. Instead of requesting a 16-bit random number directly, the developer should:
- Request a 32-bit or 64-bit value using
rdrandorrdseed. - Extract the lowest 16 bits for the application.
Example Logic:
; Instead of requesting 16-bit directly:
; rdrand ax <-- This may never be 0 on AMD
; Use a larger register:
rdrand eax ; Generate 32-bit value
mov ax, ax ; Use the lower 16 bits (which can now be 0)
💬 Community Discussion & Nuance
The "Corporate" Theory
User revolution joked that this might be a result of poor management:
"I hope this is not something stupid from AMD that decided zero is not a random number. Maybe some C?O person executed RDRAND, got zero, declared it was broken and made the engineers fix it."
The Security Debate
The conversation shifted toward the philosophy of Hardware Accelerated Cryptography.
- sylware's View: Never use hardware-accelerated crypto. They argue that "trusted hardware" is a myth unless you design and manufacture it yourself.
- revolution's Counter-point: Hardware acceleration is the way to go for trusted hardware. However, for maximum security:
Do not use RDRAND in isolation.- Always mix hardware RNG with other entropy sources.
- Adding non-random data to a random seed cannot "un-random" the result; it only increases the mix.
- macomics' Critique: Even if you design your own hardware, you are simply "mistaken in thinking that the hardware has no vulnerabilities."
Summary of Security Stances
- Non-Crypto Apps: Use
RDRANDfreely. - High-Security Apps: Mix multiple entropy sources.
- Absolute Trust: Impossible (Hardware is a spectrum of trust).
📝 Final Notes
The thread concludes with a comment from alCoPaUL suggesting a mathematical reason, though the thought was cut off: "maybe because any number multiplied by..."
Current Status: Jessé intended to email AMD for clarification.