It seems to me that a complication in implementing such an attack is that the malicious RNG producing r must know the value of x and y (and other numbers it will be hashed with). I suppose if you had the executable of the program you were trying to exploit, you could see what memory locations x and y are placed in and have the RNG in your CPU fetch from those locations. But that exploit would only work for a limited amount of time. Once the developers release a new version, the compiler will probably put x and y in a completely different memory location. It certainly doesn’t seem worth it to insert such a backdoor at the hardware level.
Yes. In the case of OpenBSD, and the assumed RDRAND backdoor, the rdrand instruction needs to find and read quite a bit of state, roll it backwards, and then hope that nothing random happens after the rdrand instruction (very unlikely).
It’s less like H(x, y, z) where z is malicious and can peek at x and y. It’s H(x, y, z, a, b, c, d) where a, b, c, d all come after z.
It’s an attack to think about, but fortunately I don’t think real world random number generators are easily vulnerable to it.
It depends on the rate of change of the application’s entropy sources. You might get pretty good mileage out of a hardware attack on a particular /dev/random implementation. Attacks that dynamically determine the location of interesting kernel structures are fairly common.