Before 2012, generating cryptographic randomness meant scraping entropy from mouse jitter, disk seek times, and interrupt intervals — a slow, boot-starved process that made /dev/random block for seconds. Then Ivy Bridge shipped RDRAND, exposing an on-die hardware entropy source as a single instruction.

The silicon underneath is a metastable latch: two cross-coupled inverters driven into an unstable state where thermal noise decides which side wins. That raw bit stream feeds an online health test, then an AES-CBC-MAC conditioner that whitens the output, then a NIST SP 800-90A CTR_DRBG (an AES-128 counter-mode PRNG) that gets reseeded every 511 samples. RDRAND gives you the DRBG output; RDSEED (Broadwell+) gives you the conditioner output directly — suitable for seeding your own DRBG.

Both instructions can fail. The CF flag signals success:

• CF=1: valid 16/32/64-bit random value in destination register
• CF=0: entropy pool underflowed — retry

Intel's spec says retry up to 10 times for RDRAND, and use exponential backoff for RDSEED (which fails more often since it's not amplified by a DRBG). A typical asm sequence:

retry:  rdrand  rax
        jnc     retry       ; carry clear = no random this cycle

Real-world example: OpenSSL's rand_pool_acquire_entropy() mixes RDSEED (preferred) or RDRAND output into its own DRBG rather than trusting the CPU's PRNG directly. This is deliberate paranoia: the FreeBSD project famously refused to feed RDRAND straight into /dev/random in 2013 after Snowden disclosures raised questions about NSA influence on Intel's DRBG. Linux compromised — it XORs RDRAND into the entropy pool alongside other sources, so a compromised RDRAND can't weaken the output, only fail to strengthen it.

Performance rule of thumb: RDRAND on modern Intel delivers ~200 MB/s per core, but with a latency of ~200 cycles per invocation. RDSEED is slower (~3 MB/s aggregate across all cores — the entropy source is shared uncore hardware). If you need bulk randomness, seed a userspace ChaCha20 DRBG from RDSEED once and generate gigabytes from that; if you call RDRAND in a tight loop across 32 cores, you'll bottleneck on the shared conditioner and see throughput collapse.

One subtle gotcha: RDRAND is not a serializing instruction, but it does implicitly consume from a shared queue, so it acts as a partial ordering point in contended workloads — surprising if you're benchmarking.