It doesn't really assume that at all. You can maliciously generate the result of RDRAND according to the instructions that are going to use it - that doesn't prevent that value being used later.
The way a CPU works internally, intermediate results are written to registers, and the registers specified by the machine code are rewritten onto a larger set of real registers. The CPU knows at the instruction decode stage which results are going to be used by which instructions, so that it can schedule them for out of order execution. It also knows when it can throw away the result of a real register because the machine code register it represents has been overwritten with another value. So if the result is used by a second instruction, that doesn't matter
Yes, if you wrote the result of RDRAND to main memory and read it in again, you would destroy that knowledge, but I would bet that the random number generator doesn't do that.
It could certainly be used as an integrity check. If you get different results from the same operations on what should be the same numbers, you know your hardware is maliciously unfit for purpose.
No, you store the register value holding the RDRAND result into memory, then you store the register value holding the number from your other sources of entropy.
Then you read them back from memory and XOR the same numbers again. You compare that result with the XOR from the register values and see if they are the same.
If they are different, the chip is substituting a different XOR result whenever it is capable of determining that one of the operands is the output of an RDRAND instruction.
You might presume that an efficient mixer of multiple entropy sources would just XOR all of its various inputs together, so compromising XOR would be an easy way to discard the entropy of the other inputs in a way that is not easily detected without writing assembly code specifically to check it.
That doesn't protect against the CPU choosing the return value of RDRAND maliciously - just against the XOR operation being duff. To be honest, it's much easier for a CPU to have a malicious RDRAND than compromise XOR. As demonstrated in another post, returning "edx XOR <something predictable>" hoses the Linux RNG.
But a malicious RDRAND is, at worst, useless, contributing zero entropy to a pool of multiple sources. A malicious XOR could reduce the entropy of the pool.
The way a CPU works internally, intermediate results are written to registers, and the registers specified by the machine code are rewritten onto a larger set of real registers. The CPU knows at the instruction decode stage which results are going to be used by which instructions, so that it can schedule them for out of order execution. It also knows when it can throw away the result of a real register because the machine code register it represents has been overwritten with another value. So if the result is used by a second instruction, that doesn't matter
Yes, if you wrote the result of RDRAND to main memory and read it in again, you would destroy that knowledge, but I would bet that the random number generator doesn't do that.