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)
-- 
2.51.0

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.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

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

On Sun 19 Oct 2025 05:03:25 PM , Jason A. Donenfeld wrote:
> 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
>

Although apparently, the patch does break userspace for any distribution
building packages with -march=znver4

- Christopher

On Mon, Nov 03, 2025 at 02:22:44AM -0800, Christopher Snowhill wrote:
> Although apparently, the patch does break userspace for any distribution
> building packages with -march=znver4

Care to elaborate?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Mon 03 Nov 2025 01:03:19 PM , Borislav Petkov wrote:
> On Mon, Nov 03, 2025 at 02:22:44AM -0800, Christopher Snowhill wrote:
> > Although apparently, the patch does break userspace for any distribution
> > building packages with -march=znver4
> 
> Care to elaborate?

Sorry for the HTML before, apparently I'm not supposed to try writing
replies from my tablet, because it will interpret the quote indenting as
formatting and forcibly send HTML mail.

Anyway. A bug report was sent here:

https://lore.kernel.org/lkml/9a27f2e6-4f62-45a6-a527-c09983b8dce4@cachyos.org/

Qt is built with -march=znver4, which automatically enables -mrdseed.
This is building rdseed 64 bit, but then the software is also performing
kernel feature checks on startup. There is no separate feature flag for
16/32/64 variants.

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

On Mon, Nov 03, 2025 at 03:55:53PM -0800, Christopher Snowhill wrote:
> https://lore.kernel.org/lkml/9a27f2e6-4f62-45a6-a527-c09983b8dce4@cachyos.org/

tglx already summed up what the options are:

https://lore.kernel.org/all/878qgnw0vt.ffs@tglx

> Qt is built with -march=znver4, which automatically enables -mrdseed.
> This is building rdseed 64 bit, but then the software is also performing
> kernel feature checks on startup. There is no separate feature flag for
> 16/32/64 variants.

No, there aren't.

And the problem here is that, AFAICT, Qt is not providing a proper fallback
for !RDSEED. Dunno, maybe getrandom(2) or so. It is only a syscall which has
been there since forever. Rather, it would simply throw hands in the air.

Soon there will be client microcode fixes too so all should be well.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On Tue, Nov 4, 2025 at 2:21 PM Borislav Petkov <bp@alien8.de> wrote:
> And the problem here is that, AFAICT, Qt is not providing a proper fallback
> for !RDSEED. Dunno, maybe getrandom(2) or so. It is only a syscall which has
> been there since forever. Rather, it would simply throw hands in the air.

Qt seems to be kinda wild.

When you use -mcpu=, you generally can then omit cpuid checks. That's
the whole idea. But then Qt checks cpuid anyway and compares it to the
-mcpu= feature set and aborts early. This mismatch happens in the case
Christopher is complaining about when the kernel has masked that out
of the cpuid, due to bugs. But I guess if it just wouldn't check the
cpuid, it would have worked anyway, modulo the actual cpu bug. But
regarding rdseed/rand bugs, there's a workaround for earlier AMD
rdrand bugs: https://github.com/qt/qtbase/blob/dev/src/corelib/global/qsimd.cpp#L781
But then it skips that for -mcpu= with `(_compilerCpuFeatures &
CpuFeatureRDRND)`. Weird.

Another strange thing, though, is the way this is actually used. As
far as I can tell from reading this messy source,
QRandomGenerator::SystemGenerator::generate() tries in order:

1. rdseed
2. rdrand
3. getentropy (getrandom)
4. /dev/urandom
5. /dev/random
6. Something ridiculous using mt19937

In addition to rdseed really not being appropriate here, in order to
have seeds for option (6), no matter what happens with 1,2,3,4,5, it
always stores the first 4 bytes of output from previous calls, just in
case at some point it needs to use (6). Goodbye forward secrecy? And
does this mt19937 stuff leak? And also, wtf?

This is totally strange. It should just be using getrandom() and
falling back to /dev/urandom for old kernels unavailable. Full stop.
Actually, src/corelib/global/minimum-linux_p.h suggests 4.11 is
required ("We require the following features in Qt (unconditional, no
fallback)"), so it could replace basically this entire file with
getentropy() for unix and rtlgenrandom for windows.

I dunno, maybe I read this code wrong --
https://github.com/qt/qtbase/blob/dev/src/corelib/global/qrandom.cpp
-- you can look at yourself. But this whole thing seems to be muddled
and pretty bad.

So I'm slightly unsympathetic.

I'm CC'ing Thiago; he'll maybe have some sort of defense of all this
weirdness. But really -- you're doing it wrong. Just use getrandom()!

Jason

The documentation really isn't helping things either.

https://doc.qt.io/qt-6/qrandomgenerator.html

From the intro: "QRandomGenerator::securelySeeded() can be used to
create a QRandomGenerator that is securely seeded with
QRandomGenerator::system(), meaning that the sequence of numbers it
generates cannot be easily predicted. Additionally,
QRandomGenerator::global() returns a global instance of
QRandomGenerator that Qt will ensure to be securely seeded." And then
later, reading about QRandomGenerator::global(), it starts by saying,
"Returns a pointer to a shared QRandomGenerator that was seeded using
securelySeeded()."

Sounds great, like we should just use QRandomGenerator::global() for
everything, right? Wrong. It turns out QRandomGenerator::system() is
the one that uses 1,2,3,4,5,(6godforbid) in my email above.
QRandomGenerator::global(), on the contrary uses
"std::mersenne_twister_engine<quint32,32,624,397,31,0x9908b0df,11,0xffffffff,7,0x9d2c5680,15,0xefc60000,18,1812433253>".

So then you keep reading the documentation and it mentions that
::system() is "to access the system's cryptographically-safe random
generator." So okay maybe if you're really up with the lingo, you'll
know to use that. But to your average reader, what's the difference
between "securely seeded" and "system's cryptographically-safe random
number generator"? And even to me, I was left wondering what exactly
was securely seeded before I looked at the source. For example,
OpenBSD's arc4random securely seeds a chacha20 instance in libc before
proceeding. That's a lot different from std::mersenne_twister_engine!

I was looking for uses of ::system() on my laptop so that I could
verify the behavior described in my last email dynamically, when I
came across this from my favorite music player (author CC'd):
https://github.com/strawberrymusicplayer/strawberry/blob/master/src/utilities/randutils.cpp#L50

QString CryptographicRandomString(const int len) {
  const QString
UseCharacters(u"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~"_s);
  return GetRandomString(len, UseCharacters);
}
QString GetRandomString(const int len, const QString &UseCharacters) {
  QString randstr;
  for (int i = 0; i < len; ++i) {
    const qint64 index = QRandomGenerator::global()->bounded(0,
UseCharacters.length());

Using ::global() for something "cryptographic". I don't blame the
author at all! The documentation is confusing as can be.

And this is all on top of the fact that ::system() is pretty mucky, as
described in my last email.

Jason