Linux kernel can't "fix" it without the hardware support. You're right, just accepting RDRAND as the entropy source magically makes /dev/random nonblocking on the CPUs that have it, as it is quite fast. I'd personally use it as one of the valid entropy sources. The last time I've read about its use in Linux kernel, if I understood, it was not considered as such, being xored only after the entropy estimation of other sources with much much less bandwidth.
So even if once Intel gets to be "less evil in the eyes of worried people" for a "sin" of providing RDRAND although the same people otherwise trust the company to let its CPU's execute all their programs, what should the poor kernel writers do on the systems without RDRAND?
But you are completely right, having the VM's and distributions agreeing on protocols for providing initial randomness to the VM is certainly a step in the right direction and the proper solution to one real problem.
Whereas promoting belief in regular user-space use of the /dev/random as the magic solution is, in my humble opinion, something like a cargo cult. I'm not commenting your statements here, just attempting to make my position in this whole discussion clear.
> So even if once Intel gets to be "less evil in the eyes of worried people" for a "sin" of providing RDRAND although the same people otherwise trust the company to let its CPU's execute all their programs
This isn't fair. Most instructions compute deterministic functions of their operands. It's easy for people to tell if the CPU is computing the correct result. (Remember the Pentium FDIV bug?) RDRAND, by definition and design, is nondeterministic. Only by examining a long sequence of its results could one gain any confidence that it isn't backdoored ... and then one might still be overlooking something.
> Only by examining a long sequence of its results could one gain any confidence that it isn't backdoored
Actually, you can't. A properly backdoored RNG is indistinguishable from a non-backdoored RNG. Imagine a backdoored RNG that is simply a counter encrypted with AES. The output looks completely random, but it can be completely broken by the holder of the AES key.
So even if once Intel gets to be "less evil in the eyes of worried people" for a "sin" of providing RDRAND although the same people otherwise trust the company to let its CPU's execute all their programs, what should the poor kernel writers do on the systems without RDRAND?
But you are completely right, having the VM's and distributions agreeing on protocols for providing initial randomness to the VM is certainly a step in the right direction and the proper solution to one real problem.
Whereas promoting belief in regular user-space use of the /dev/random as the magic solution is, in my humble opinion, something like a cargo cult. I'm not commenting your statements here, just attempting to make my position in this whole discussion clear.