This was his post on Sept. 2013:
   [1]https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J

     I am so glad I resisted pressure from Intel engineers to let
     /dev/random rely only on the RDRAND instruction.   To quote from the
     article below:
     "By this year, the Sigint Enabling Project had found ways inside
     some of the encryption chips that scramble information for
     businesses and governments, either by working with chipmakers to
     insert back doors...."
     Relying solely on the hardware random number generator which is
     using an implementation sealed inside a chip which is impossible to
     audit is a BAD idea.



   This was Intel's statement on Nov. 2012:
   [2]https://software.intel.com/en-us/blogs/2012/11/17/the-difference-bet
   ween-rdrand-and-rdseed

     In contrast, RDRAND is the output of a 128-bit PRNG that is
     compliant to NIST SP 800-90A. It is intended for applications that
     simply need high-quality random numbers. The numbers returned by
     RDRAND have additive prediction resistance because they are the
     output of a pseurandom number generator. If you put two 64-bit
     values with additive prediction resistance togehter, the prediction
     resistance of the resulting value is only 65 bits...




   I feel increased confidence in the Linux team's efforts to provide
   security. Keeping track of dependencies is hard.

References

   1. https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
   2. https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed