Read carefully what Linus actually wrote, not what you believe he writes. Here he suggests an even better implementation than the one actually implemented afterwards: feeding hwrng to the pool just like the all other sources. The last time I've checked (a year or a two ago) the hwrng was there but had the special treatment, not passing the same path as the other sources.
So it's more "why wasn't hwrng treated as the other sources later" than why he wrote what he wrote here.
IIRC, Bernstein actually disagrees with (almost) any use of rdrand. Consider, as a toy example, an rdrand that poisons a register, so that xor'ing it with anything results in a known value; this might be worse than useless.
I also don't see why we should assume that Intel would implement RDRAND as looking at the randomness pool and at the same time believe that they can't do even more funny things when they control the whole CPU. If the active maliciousness is assumed then the CPU can't be used at all.
I feel like I remember him saying something about how as long as it's just another thing hashed into the randomness pool, it's not that big of a deal. But I haven't seen that in writing anywhere. I could just be wrong.
I.e. feeding hwrng into the pool, the one that says in the comment at the top "this is not secure against malicious intent"? That one? Actual quote:
Randomness from these sources are
added to an "entropy pool", which is mixed using a CRC-like function.
**This is not cryptographically strong**, but it is adequate assuming
the randomness is not chosen maliciously
Thanks. That can explain why they still don't mix hwrng directly to the pool. They don't want to increase the "estimate" of the "random bits available" in that pool.
Few posts above, I write "read carefully what Linus actually wrote." This time I can only say, "read what I actually wrote" don't take a few words from the sentence. My assumption in this discussion was that others know from other sources more about the subject. I have the impression that that background is missing in your reply. Still, even if we remain by what I've written:
In my older post I claim that I've read the random.c source cca 1-2 years ago. Note: the source, the C code, not the comments. My older sentence was: "Here he suggests an even better implementation than the one actually implemented afterwards: feeding hwrng to the pool just like the all other sources. The last time I've checked (a year or a two ago) the hwrng was there but had the special treatment, not passing the same path as the other sources."
I think it's clear: "The last time I've checked (a year or a two ago) the hwrng (..) had the special treatment, not passing the same path as the other sources."
Then in the later post my words are: "they still don't mix hwrng directly to the pool." I wrote it as I've actually checked the current git master of the random.c.
I don't see anything contradictory.
I also have more understanding for the idea behind the current implementation. Now it looks to me like they try to handle the hwrng as something that can be actively malicious, not just having a known seed (while just having the known seed, to my understanding, shouldn't be a problem to mix together with with other inputs). I personally think that the assumption of active maliciousness is to much, because the same company produces the whole CPU, and if you assume that, then you shouldn't use the CPU at all: they can be actively malicious all the time, not just with one instruction.
And, by the way, mixing through the same path but without increasing the "entropy counter" were maybe possible, but maybe it was cleaner this way.
So it's more "why wasn't hwrng treated as the other sources later" than why he wrote what he wrote here.