mov     eax, 1
    cpuid
    test    ecx, 1 shl 30
    jz      unsupported
    mov     rcx, 1000000
try_loop:   rdrand rax
    sbb     dl, dl
    loopz   try_loop
    jrcxz   error_no_value    

RDRAND - Loads a hardware generated random value and store it in the destination register. The size of the random value is
determined by the destination register size and operating mode. The Carry Flag indicates whether a random value
is available at the time the instruction is executed. CF=1 indicates that the data in the destination is valid. Other-
wise CF=0 and the data in the destination operand will be returned as zeros for the specified width. All other flags
are forced to 0 in either situation. Software must check the state of CF=1 for determining if a valid random value
has been returned, otherwise it is expected to loop and retry execution of RDRAND (see Intel® 64 and IA-32 Archi-
tectures Software Developer’s Manual, Volume 1, Section 7.3.17, “Random Number Generator Instructions”).
This instruction is available at all privilege levels.
In 64-bit mode, the instruction's default operation size is 32 bits. Using a REX prefix in the form of REX.B permits
access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bit oper-
ands. See the summary chart at the beginning of this section for encoding data and limits.

RDSEED - Loads a hardware generated random value and store it in the destination register. The random value is generated
from an Enhanced NRBG (Non Deterministic Random Bit Generator) that is compliant to NIST SP800-90B and NIST
SP800-90C in the XOR construction mode. The size of the random value is determined by the destination register
size and operating mode. The Carry Flag indicates whether a random value is available at the time the instruction
is executed. CF=1 indicates that the data in the destination is valid. Otherwise CF=0 and the data in the destination
operand will be returned as zeros for the specified width. All other flags are forced to 0 in either situation. Software
must check the state of CF=1 for determining if a valid random seed value has been returned, otherwise it is
expected to loop and retry execution of RDSEED (see Section 1.2).
The RDSEED instruction is available at all privilege levels. The RDSEED instruction executes normally either inside
or outside a transaction region.
In 64-bit mode, the instruction's default operation size is 32 bits. Using a REX prefix in the form of REX.B permits
access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bit oper-
ands. See the summary chart at the beginning of this section for encoding data and limits.

7.3.17 Random Number Generator Instructions
The instructions for generating random numbers to comply with NIST SP800-90A, SP800-90B, and SP800-90C
standards are described in this section.
7.3.17.1 RDRAND
The RDRAND instruction returns a random number. All Intel processors that support the RDRAND instruction indi-
cate the availability of the RDRAND instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1.
RDRAND returns random numbers that are supplied by a cryptographically secure, deterministic random bit gener-
ator DRBG. The DRBG is designed to meet the NIST SP 800-90A standard. The DRBG is re-seeded frequently from
an on-chip non-deterministic entropy source to guarantee data returned by RDRAND is statistically uniform, non-
periodic and non-deterministic.
...

Code:

----------------------------------------------------------------------------------------
#define SUCCESS 1
#define RETRY_LIMIT_EXCEEDED 0
#define RETRY_LIMIT 10
int get_random_64( unsigned __int64 * arand)
{
  int i ;
  for ( i = 0; i < RETRY_LIMIT; i++) {
    if(_rdrand64_step(arand) ) return SUCCESS;
  }
  return RETRY_LIMIT_EXCEEDED;
}
-------------------------------------------------------------------------------    

I use Park-Miller PRNG.

The Lehmer random number generator (named after D. H. Lehmer), sometimes also referred to as the Park–Miller random number generator (after Stephen K. Park and Keith W. Miller), is a type of linear congruential generator (LCG) that operates in multiplicative group of integers modulo n.

And therein lies the problem.

Quote:

And therein lies the problem.

Is it big deal to modify the result at your own? Who know what did you made with it? Shift bits for example, replace bytes, etc

the security or the randomness.

... conspiracy theories too. Its funny, nothing else.

NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm.

But back to CPU instruction, it is absolute different thing. You don't ask CPU to create some trusted keys or crypt your secrets. It just provide some sort of random trash you have to configure for own purpose.

Experts know what they are talking about more than everyone else, that's why they are the experts.

The bedrock of cryptography is having good random numbers.

The bedrock of cryptography is having good random numbers. So to say it isn't necessary is really bad. Without randomness cryptography isn't possible. All you end up with is encoding and transformations, and no security.

Anyhow, up to you if you are okay to use rdrand without reservation. For many non-cryptographic purposes it will be fine.

I choose to trust open libraries that don't hide things, over implementations that have hidden secrets that can't be verified. Claims about security without proof are worthless. Intel;s claims about their super-uber-rdrand are also worthless. No serious cryptography expert accepts such claims without proof. Amateurs shouldn't dismiss the experts so easily IMO. Experts know what they are talking about more than everyone else, that's why they are the experts.