Message-ID: <1903914.sHLxoZxqIA@tjmaciei-mobl5>
Date: Wed, 05 Nov 2025 08:41:01 -0800
From: Thiago Macieira <thiago.macieira@...el.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Borislav Petkov <bp@...en8.de>, 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
Subject:
 Re: [PATCH v2] x86/amd: Disable RDSEED on AMD Zen5 because of an error.

On Tuesday, 4 November 2025 17:58:36 Pacific Standard Time Jason A. Donenfeld 
wrote:
> Hi Thiago,
> 
> On Tue, Nov 04, 2025 at 03:50:37PM -0800, Thiago Macieira wrote:
> > Strictly speaking, if you don't have getentropy(), the fallback will be
> > compiled in, in case someone runs the application is a messed up
> > environment with /dev improperly populated. In practice, that never
> > happens and getentropy() appeared in glibc 2.25, which is now older than
> > the oldest distro we still support.
> 
> Great, so I suppose you can entirely remove /dev/[u]random support then.

It's already compiled out if your glibc has 2.25. Likewise, it gets compiled 
out for the BSDs (including macOS). That has been the case since the 
inception.

The /dev/[u]random code needs to remain for QNX and other OSes.
https://www.qnx.com/developers/docs/8.0/search.html?searchQuery=getentropy

> > Indeed. Linux is *impressively* fast in transitioning to kernel mode and
> > back. Your numbers above are showing getrandom() taking about 214 ns,
> > which is about on par what I'd expect for a system call that does some
> > non-trivial work. Other OSes may be an order of magnitude slower, placing
> > them on the other side of RDRAND (616 ns).
> > 
> > Then I have to ask myself if I care. I've been before in the situation
> > where I just say, "Linux can do it (state of the art), so complain to
> > your OS vendor that yours can't". Especially as it also simplifies my
> > codebase.
> 
> Well, if you want performance consistency, use arc4random() on the BSDs,
> and you'll avoid syscalls. Same for RtlGenRandom on Windows. These will
> all have similar performance as vDSO getrandom() on Linux, because they
> live in userspace. Or use the getentropy() syscall on the BSDs and trust
> that it's still probably faster than RDRAND, and certainly faster than
> RDSEED.

Thanks for the info.

> > QRandomGenerator *can* be used as a deterministic generator, but that's
> > neither global() nor system(). Even though global() uses a DPRNG, it's
> > always seeded from system(), so the user can never control the initial
> > seed and thus should never rely on a particular random sequence.
> > 
> > The question remaining is whether we should use the system call for
> > global() or if we should retain the DPRNG. This is not about performance
> > any more, but about the system-wide impact that could happen if someone
> > decided to fill in a couple of GB of of random data. From your data, that
> > would only take a couple of seconds to achieve.
> 
> Oh yea, good question. Well, with every major OS now having a mechanism
> to skip syscalls for random numbers, I guess you could indeed just alias
> global() to system() and call it a day. Then users really cannot shoot
> themselves in the foot. That would be simpler too. Seems like the best
> option.

Indeed.

But consider people who haven't upgraded Linux (yes, we get people asking to 
keep everything intact in their system, but upgrade Qt only, then complain 
when our dependency minimums change). How much of an impact would they have?

> > >       1) New microcode
> > >       
> > >       2) Fix all source code to either use the 64bit variant of RDSEED
> > >       
> > >          or check the result for 0 and treat it like RDSEED with CF=0
> > >          (fail) or make it check the CPUID bit....
> > 
> > Or 3) recompile the code with the runtime detection enabled.
> > 
> > It's a pity that Qt always uses the 64-bit variant, so it would have
> > worked
> > just fine.
> 
> 4) Fix Qt to use getrandom().

That's recompiling Qt anyway. I can't change existing deployments and I can't 
affect much of past, stable releases.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5150 bytes)

Powered by blists - more mailing lists