If you think RDRAND is examining the L1 and registers in order to derandomise it, why wouldn't the evil chip just skip bothering with RDRAND and instead just attack that random buffer it knows how to find...?
Mucking with RDRAND can easily be done in such a way that it's provably impossible to detect any differences in behaviour. It's much harder to guarantee that if you start mucking with buffers in memory, since there are so many clever ways a developer could check their work and catch you out.
How's the provably impossible to detect bit work again? Surely it'd fail a Chi Square test on reruns with the same input? The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight.
"The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight."
It could potentially use the number of milliseconds since the last hour, or maybe the state of the branch predictor, or any number of other things that have exploitable biases (with NSA resources, 1/1000000000 is pretty good odds).
Why should the CPU not have an internal counter that is backed up in flash memory between reboots? 128bit would be enough, with the highest bits set to the processor serial number. Using this counter in AES-CTR mode – i.e. encrypt the counter with the secret key to generate the pseudo random data – the NSA could reconstruct the internal CPU state from a single block (16 bytes) of random data. As many random data is published verbatim, for example as nonces, getting such a block should not be a problem.
Yeah, or if the onboard flash memory is too difficult to implement, they could even just initialise the lower bits of the counter from the real hardware RNG every boot. Either of these options would be statistically indistinguishable from true randomness unless you knew the key.