RDSEED

RDSEED looks like RDRAND: same opcode (0F C7) with /7 in place of /6, 16-, 32- and 64-bit register forms, CF = 1 when the number is valid and OF, SF, ZF, AF and PF cleared. What it returns differs. On Intel’s processors RDRAND reads a deterministic generator that the hardware reseeds, while RDSEED reads the non-deterministic source behind it, built to NIST SP 800-90B and 90C. Its numbers are meant to seed a generator of the program’s own, such as the one a cryptographic library keeps, not to be used in bulk. AMD’s manual calls the value a hardware-generated seed and says no more about its source.

It runs dry more readily#

Intel’s volume 1 describes RDRAND running out under load as possible but unlikely, and RDSEED running out as possible: the entropy source is slower than the generator it feeds. So the retry loop that both manuals ask for (a limited number of tries, then an error) is part of every use, not an afterthought. Both manuals agree that a failed RDSEED leaves 0 in the destination. GCC 14 at -O2 turns _rdseed32_step(&x) into RDSEED, a store of the register and SETC; Clang 23 uses CMOVAE as it does for RDRAND, relying on that 0. Both need -mrdseed or an -march that has it, such as broadwell or znver1; x86-64-v3 and v4 do not.

On Zen 5#

The three recorded cases, one per size, all set CF, with the other flags cleared, bits 63:16 of the 16-bit form’s register kept and bits 63:32 of the 32-bit form’s cleared. They are too few to show a fault that AMD’s bulletin AMD-SB-7055 (CVE-2025-62626) describes: on Zen 5 the 16- and 32-bit forms may return 0, with CF set, far more often than a random source would, and the 64-bit form is not affected. Until a microcode update, the bulletin suggests the 64-bit form, hiding the CPUID bit, or treating a 0 with CF set as a failure. Linux 7.3 turns RDSEED off on Zen 5 below a fixed microcode revision, with the message “RDSEED32 is broken”; CPUID in the probe’s process still reported it (leaf 07H, EBX bit 18), so a program that asks CPUID uses it regardless.

AMD’s Zen 5 guide lists RDSEED as microcoded, like RDRAND, with no latency given.

In the optimization guide

What the optimization guide says about RDSEED, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Haswell and Broadwell

• What Broadwell changed: Broadwell adds ADCX and ADOX, RDSEED and PREFETCHW, which -march=broadwell enables in LLVM; code built that way can fault on Haswell, which has none of them.

Silvermont to Goldmont Plus

• Vectors and cryptography: Goldmont is the first Atom core with the SHA extensions and RDSEED.

Vulnerability mitigations

Mitigations of these processor vulnerabilities use RDSEED:

• CVE-2025-62626: RDSEED Failure on Zen 5
• CVE-2022-21127: Special Register Buffer Data Sampling (Special Register Buffer Data Sampling update)
• CVE-2020-0543: Special Register Buffer Data Sampling

Forms

Latency and throughput

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

ok = seed_ready()                # the generator's: 1 when it has a
                                 # number for RDSEED, a random one
dest.write(seed(OSIZE) if ok else 0)
cf = ok                          # 16 bits: bits 63:16 kept; 32 bits:
of = sf = zf = af = pf = 0       # bits 63:32 cleared
# with none ready, the destination is 0 (both manuals), and a
# program tries again. Intel's RDSEED draws from the entropy source
# itself, a non-deterministic generator: numbers to seed one of the
# program's own.
# Zen 5's 16- and 32-bit forms return 0 with CF set at a rate that
# no random source has, its 64-bit form does not (AMD-SB-7055,
# CVE-2025-62626). Linux 7.3 turns RDSEED off on Zen 5 below a
# microcode revision (arch/x86/kernel/cpu/amd.c, lines 1032-1051);
# the recorded cases' CPUID reports it (leaf 07H, EBX[18])

Operands

Flags

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.