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.
- 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.