Recently, while doing some assembly code to render data intro charts, and using 'rdrand' and 'rdseed' to provide that data to the displayed, I've figured out by accident what appears to be a bug (problem) only with AMD processors (maybe Zen2 only problem): they can't generate a number 0 at a given size! Running the same programs on an Intel processor, and the 0's are there with no problem.

You can help me figure out this by using my application to seek for any 0 number generated, and maybe post your results at this forum thread...

I also must mention that this application is a very deep showcase on how to control and render data to the console screen at arbitrary positions, which I remember someone here was trying to achieve the same under Linux cli, and he asked for help on this subject before.

Attached, I've provided that exact chart test application that showcases the AMD's RNG 0 problem: you'll probably, on an AMD host, never see the first bar change colors from green (which uses a TSC method I've created to generate random numbers), and also never see the base chart scale up from 0. On Intel processor, no problem, and the chart scale its base (minimum) beyond 0. The first bar renders how many zeroes are being generated by rdrand (red), rdseed (blue) and TSC-custom technique (green), as well as other bars render the other 65535 numbers from the 16-bit space.
Note: it requires fastcall_v1 macro kit if anyone wants to compile and test it as is.

Cheers!

So far, my results...

Do the lowest 16-bits ever equal all-zero for 32/64-bit outputs?

Yes, when using either 32-bit or 64-bit number, the lowest portion can output a zero, as I suggested on the attached example file as a modification to fix the problem.
But a true zero (fitting the requested size), on AMD, never happens.

I hope this is not something stupid from AMD that decided zero is not a random number.

Maybe some C?O person executed RDRAND, got zero, declared it was broken and made the engineers "fix" it.

Haha, good point, I was thinking the same when this problem has presented itself to me.
I'll probably will e-mail AMD about this, and if they answered, I'll be back here to share what they said.

At the time I was wandering in information system security, there was that rule of thumb: never ever use hardware accelerated crypto...

For trusted hardware: Hardware accelerated crypto is definitely the way to go IMO.

For untrusted hardware: Don't do any crypto with it, software or hardware.

For best security with RDRAND, it might be backdoored, it might not. IDK, but never use it in isolation, always mix it with other sources. It doesn't hurt to add non-random data into an already random seed. It isn't possible to un-random a random value with non-randomness, it just mixes up the random bits a bit more.

If the application isn't for crypto then none of this matters, use RDRAND for anything. Go for it.

'trusted hardware' does not exist, unless it is YOUR hardware, of YOUR design (based on best know how), with tight control of the manufacturing process.

Even in this case, you will simply be mistaken in thinking that the hardware has no vulnerabilities.

I said 'trusted hardware', not trusted hardware................

We all know "trusted" hardware does not exist, it is a spectrum: "trusted" is actually some amount of "trust" decided based on some contexts and specifics.

At the time, when I was wandering in information system security groups: all this 'security hardware' was rumored to have flaws: entropy/maths/bugs/etc which users cannot cleanly fix, or actually even fix.

maybe because any number multiplied by zero is zero and any number divided by zero is overflow...