Your dismissive tone is rude and uncalled for. There's nothing fundamentally impossible about the method tlb is suggesting. It would actually be quite a clever hack.
It can't be done. Between the RdRand instruction and the next XOR nothing guarantees that:
1 - The task won't be preempted
2 - That XOR will be used for entropy calculation
And even if n. 1 doesn't happen, n. 2 is very hard to guarantee (and easy to avoid)
Of course I'm dismissive because it's obvious to me it can't work like that. But please let's continue discussing impossible theories and barking at wrong trees.
There are easier and more effective attacks than that.
More to the point, a change like this is very likely to be _noticed_. Both in terms of the complexity that would be required to make such a change in the microcode, and if the logic screws up and tampers with the wrong XOR, it will cause a bug that people will search for and eventually discover that the CPU was screwing up XOR under some circumstances. Remember the firestorm over the FDIV bug?
It doesn't have to work every time, just occasionally (1 in 1,000,000) is enough to introduce an exploitable weakness. So task preemption isn't a problem.
XOR is used for entropy calculation in the Linux kernel, as Dale Emmons points out in the article.
