You are right. The code I posted in this thread is indeed useless. You can't trust RDRAND to return some random values. It was a bad idea.
It is never used as unique source of entropy in mORMot. Just as part of a lot of entropy gathering.
Here is the documentation of mORMot about the initialization of our cryprographic AES-based PRNG:
/// retrieve some entropy bytes from the Operating System
// - entropy comes from CryptGenRandom API on Windows, and /dev/urandom or
// /dev/random on Linux/POSIX
// - this system-supplied entropy is then XORed with the output of a SHA-3
// cryptographic SHAKE-256 generator in XOF mode, of several entropy sources
// (timestamp, thread and system information, SynCommons.Random32 function)
// unless SystemOnly is TRUE
// - depending on the system, entropy may not be true randomness: if you need
// some truly random values, use TAESPRNG.Main.FillRandom() or TAESPRNG.Fill()
// methods, NOT this class function (which will be much slower, BTW)
class function GetEntropy(Len: integer; SystemOnly: boolean=false): RawByteString; virtual;
https://github.com/synopse/mORMot/blob/ecc375adc96e5b78d63dd58a88418874a0f622d8/SynCrypto.pas#L1114
And about RDRAND, when mORMot checks the CPUID, it also runs RDRAND and if it fails to return random values, it unset its internal flag, and it will never be used, and not used as entropy.
It is even worse on AMD, which can have CF=1 but always return 0 or -1 !!!
So in practice, mORMot seems to follow your wise suggestions.
My answer in this thread, and my RDRAND use was confusing, for sure. 🙂