linux-kernel - Re: [PATCH v2] x86/amd: Disable RDSEED on AMD Zen5 because of an error.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9o+cVsBzkVN9Gnhos+4hH7Y7N6Sfq9C5G=bkkz=jzRUUA@mail.gmail.com>
Date: Tue, 4 Nov 2025 15:28:07 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Christopher Snowhill <chris@...e54.net>, Gregory Price <gourry@...rry.net>, x86@...nel.org, 
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com, 
	dave.hansen@...ux.intel.com, hpa@...or.com, peterz@...radead.org, 
	mario.limonciello@....com, riel@...riel.com, yazen.ghannam@....com, 
	me@...aill.net, kai.huang@...el.com, sandipan.das@....com, 
	darwi@...utronix.de, stable@...r.kernel.org, thiago.macieira@...el.com
Subject: Re: [PATCH v2] x86/amd: Disable RDSEED on AMD Zen5 because of an error.

On Tue, Nov 4, 2025 at 2:21 PM Borislav Petkov <bp@...en8.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