Still, I think a common pattern is (1) notice funny symptom, (2) go look at code, puzzle through it for a while, and then "oh!" You're now in a much stronger position to fix the problem or petition for a fix.
With closed-source code, step (2) is a lot harder unless you're in a privileged position...
Open source code still needs people looking at it.
And, of course, if you make it the kernel /dev/random you're making it the source of randomness recommended for long term keys and other important things... while you don't know what the users will use it for, you can safely assume it will include some of "the most critical of applications".
f(<Some number of previous outputs>, <Secret key known to Intel and the NSA>, <Your cpu identifier>) = <next output>
Yes it does. Closed source, to the extent it impairs audits, does mean something is insecure.
It does not prove that the software is backdoored, otherwise compromised, or defective in any way - if that is what you meant, you're correct. But security means not only absence of these conditions, but also that you can verify that these conditions are absent.
Security is relative. "Secure" is a short form of "high enough confidence". There can be a rational basis for high or low confidence, based on various factors, including testing and likely motives of the parties. Closed source itself is a bad factor. Collaboration with the USG is a very bad factor.
Also correct me if I am wrong, but wasn't this about using RdRand as entropy source to the linux /dev/random, which afaik is not injection-proof..
And I would consider /dev/random among the most critial of applications.