Hardware Random Number Generation (RDRAND/RDSEED)

RDRAND / RDSEED

RDRAND source

DRBG seeded by an on-die entropy source

RDSEED source

Raw entropy, unconditioned

Availability bit

CPUID leaf 1, ECX bit 30 (RDRAND)

Failure signal

Carry flag clear

A kernel has no keyboard, mouse, or network traffic timing to draw randomness from the way a user-facing operating system typically does, which makes RDRAND and RDSEED the two instructions most kernel-level random number generation on x86 ultimately depends on. Both read from entropy circuitry built into the CPU package itself, but they answer different questions: RDRAND returns output already run through a cryptographic generator, while RDSEED returns the rawer material such a generator would itself be seeded from.

RDRAND: a seeded, conditioned stream

RDRAND does not read raw physical noise directly; it reads the output of a deterministic random bit generator (DRBG), a cryptographic algorithm that is itself continuously reseeded from a physical entropy source built into the chip (thermal noise sampled by a dedicated circuit, on Intel and AMD implementations). This two-stage design exists because a physical entropy source alone is comparatively slow and its raw output can carry small statistical biases; running it through a DRBG produces output at a much higher rate that also passes standard statistical randomness tests cleanly, at the cost of that output being computationally derived rather than physical noise itself.

retry:
    rdrand eax
    jnc retry      ; CF clear means the value was not ready; retry

RDRAND signals success through the carry flag rather than a return value: CF set means EAX (or the equivalent 16/64-bit register) holds a valid random value, CF clear means the internal generator wasn’t ready and the instruction produced nothing usable, requiring a retry. This can fail more than transiently under sustained load from many cores requesting values simultaneously, which is why production code retries a bounded number of times, commonly ten, rather than looping unconditionally, treating repeated failure as a signal to fall back to a different entropy source rather than stalling indefinitely.

RDSEED: the rawer, slower alternative

RDSEED exposes entropy closer to the physical source itself, intended specifically for seeding a separate software-side random generator rather than for direct high-volume consumption the way RDRAND output is. It shares RDRAND’s carry-flag success signal and general calling convention, but draws on a more heavily rate-limited path, since the physical entropy source underlying both instructions can only produce genuinely fresh physical randomness so quickly, and RDSEED insists on that fresher, less-processed supply rather than the DRBG’s amplified output.

retry:
    rdseed eax
    jnc retry

A kernel implementing its own cryptographic random generator (rather than depending on RDRAND’s output directly for every consumer) typically uses RDSEED once, at boot, to seed that generator, then serves ordinary requests from the software generator itself, reserving RDSEED’s slower, more heavily rate-limited output for the specific job of seeding rather than for every individual random value the kernel ever needs.

Checking availability first

Neither instruction is guaranteed present on every x86 CPU capable of running a modern kernel: RDRAND support is reported by CPUID leaf 1, ECX bit 30, and RDSEED support separately by leaf 7 (subleaf 0), EBX bit 18, two independent bits since a CPU can in principle implement one without the other. Executing either instruction on hardware that doesn’t support it raises #UD, the same invalid-opcode fault CPUID already covers as the general reason to check feature availability before use, which is what makes checking these two bits specifically, rather than assuming universal x86 support, a hard requirement rather than a defensive nicety.

int has_rdrand(void) {
    uint32_t eax, ebx, ecx, edx;
    __asm__ volatile("cpuid" : "=a"(eax), "=b"(ebx), "=c"(ecx), "=d"(edx) : "a"(1));
    return (ecx >> 30) & 1;
}

Implementation notes

Neither instruction should be trusted as a kernel’s sole entropy source without at least some fallback: a virtual machine’s CPU model may not expose either bit at all even when the underlying physical hardware does, and relying exclusively on RDRAND/RDSEED with no other entropy path means a kernel silently has no randomness at all the moment it runs somewhere that doesn’t offer them, precisely the availability check above exists to catch before that gap becomes a security problem rather than a build error. A kernel targeting genuinely strong randomness commonly combines hardware entropy with other sources still available in a kernel context, timing jitter between interrupts, for instance, mixed together through its own software generator rather than trusting any single source, hardware included, to be sufficient in isolation.

References

1. ^ Intel, Digital Random Number Generator (DRNG) Software Implementation Guide: the vendor reference for RDRAND/RDSEED behavior, retry guidance, and the DRBG/entropy-source relationship described above.

See also

• CPUID: the instruction and feature bits that report whether RDRAND/RDSEED are available at all.
• Security Mitigations: ASLR, the mitigation whose actual unpredictability depends directly on this entropy being genuine.