Under unknown conditions, Zen5 chips running rdseed can produce (val=0,CF=1) over 10% of the time (when rdseed is successful). CF=1 indicates success, while val=0 is typically only produced when rdseed fails (CF=0).
This suggests there is a bug which causes rdseed to silently fail.
This was reproduced reliably by launching 2-threads per available core, 1-thread per for hamming on RDSEED, and 1-thread per core collectively eating and hammering on ~90% of memory.
This was observed on more than 1 Zen5 model, so it should be disabled for all of Zen5 until/unless a comprehensive blacklist can be built.
Cc: stable@vger.kernel.org Signed-off-by: Gregory Price gourry@gourry.net --- arch/x86/kernel/cpu/amd.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 5398db4dedb4..1af30518d3e7 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1037,6 +1037,10 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
static void init_amd_zen5(struct cpuinfo_x86 *c) { + /* Disable RDSEED on AMD Turin because of an error. */ + clear_cpu_cap(c, X86_FEATURE_RDSEED); + msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18); + pr_emerg("RDSEED is not reliable on this platform; disabling.\n"); }
static void init_amd(struct cpuinfo_x86 *c)
On Fri, Oct 17, 2025 at 10:40:10PM -0400, Gregory Price wrote:
Under unknown conditions, Zen5 chips running rdseed can produce (val=0,CF=1) over 10% of the time (when rdseed is successful). CF=1 indicates success, while val=0 is typically only produced when rdseed fails (CF=0).
This suggests there is a bug which causes rdseed to silently fail.
This was reproduced reliably by launching 2-threads per available core, 1-thread per for hamming on RDSEED, and 1-thread per core collectively eating and hammering on ~90% of memory.
Which version of RDSEED was used? 32-bit perhaps? Can you repro this with the 64-bit version of RDSEED?
This was observed on more than 1 Zen5 model, so it should be disabled for all of Zen5 until/unless a comprehensive blacklist can be built.
As I said the last time, we're working on it. Be patient pls.
Thx.
Hi Borislav,
On Sat, Oct 18, 2025 at 12:03:14PM +0200, Borislav Petkov wrote:
This was observed on more than 1 Zen5 model, so it should be disabled for all of Zen5 until/unless a comprehensive blacklist can be built.
As I said the last time, we're working on it. Be patient pls.
While your team is checking into this, I'd be most interested to know one way or the other whether this affects RDRAND too. Since RDRAND uses the same source as RDSEED for seeding its DRBG, I could imagine it triggering this bug too (in unlikely circumstances), and then generating random looking output that's actually based on a key that has some runs of zeros in it. We'd have a hard time figuring this out from looking at the output (or even triggering it deliberately), but it seems like something that should be knowable by the team doing root cause analysis of the RDSEED bug.
Thanks, Jason
On Sun, Oct 19, 2025 at 04:46:06PM +0200, Jason A. Donenfeld wrote:
While your team is checking into this, I'd be most interested to know one way or the other whether this affects RDRAND too.
No it doesn't, AFAIK. The only one affected is the 32-bit or 16-bit dest operand version of RDSEED. Again, AFAIK.
On Sun, Oct 19, 2025 at 05:00:27PM +0200, Borislav Petkov wrote:
On Sun, Oct 19, 2025 at 04:46:06PM +0200, Jason A. Donenfeld wrote:
While your team is checking into this, I'd be most interested to know one way or the other whether this affects RDRAND too.
No it doesn't, AFAIK. The only one affected is the 32-bit or 16-bit dest operand version of RDSEED. Again, AFAIK.
Oh good. So on 64-bit kernels, the impact to random.c is zilch.
Jason
linux-stable-mirror@lists.linaro.org
-
Borislav Petkov -
Gregory Price -
Jason A. Donenfeld