Agreed. This article is very one-sided, and after posting a calmly worded comment regarding Linus's standpoint[1] on his attitude, it was deleted. The article is simply link bait and is not professional journalism.
That being said, I have more confidence in Linus's knowledge regarding /dev/random. Mostly because XOR in this context is secure:
1. XOR is an incredibly powerful encryption algorithm (not primitive); one of the best we have. The problem with XOR is that you MUST use a UNIQUE one time pad (that is the length of the data) for every message AND you need to be able to securely transmit that one time pad. AES CTR is effectively using AES to create a one time pad for XOR encryption, as an example.
2. The prior steps are effectively creating a irrecoverable OTP meaning that any malicious intent in RRAND is effectively encrypted away.
The argument is that RDRAND may have access to the previously generated OTP. If that is true, a malicious RDRAND can cancel out any randomness from that OTP. In that case the "incredibly powerful encryption algorithm" XOR can be tricked to generate a stream of zeros, shakespeares complete works, or whatever you like.
Agreed. However any form of "tricking" would be ultimately pointless because a small adjustment could be made to random.c. Existing CPUs can't be "changed" (barring microcode, but avoiding that is simple - don't install new microcode) so they would no longer work against the system.
In addition the amount of transistors required to actively circumvent random.c is prohibitive: CPUs would need to be significantly larger to pull off attacks like this.
Who the christ is feeding the output of /dev/random for its use as a cryptographic function without checking that what they read is in fact NOT just a stream of zeroes? Because that's an outcome which can happen from any truly random number generator just by chance - its unlikely, but not unreasonable.
That being said, I have more confidence in Linus's knowledge regarding /dev/random. Mostly because XOR in this context is secure:
1. XOR is an incredibly powerful encryption algorithm (not primitive); one of the best we have. The problem with XOR is that you MUST use a UNIQUE one time pad (that is the length of the data) for every message AND you need to be able to securely transmit that one time pad. AES CTR is effectively using AES to create a one time pad for XOR encryption, as an example.
2. The prior steps are effectively creating a irrecoverable OTP meaning that any malicious intent in RRAND is effectively encrypted away.
[1]: http://marc.info/?l=linux-kernel&m=137391223711946&w=2