Re: x86 CPU RNG support, take 2

   Date: Fri, 1 Jan 2016 14:37:53 -0500
   From: Thor Lancelot Simon <[email protected]>

   On Sun, Dec 27, 2015 at 02:26:36AM +0000, Taylor R Campbell wrote:
   [...]
   > What does MSR_VIA_RNG_2NOISE actually do?  Can you add a documentation
   > citation?

   As the comment just above noted:
           /* C7 stepping 8 and subsequent CPUs have dual RNG */

   For some reason, you have to turn the second noise source on.  I don't
   have full PadLock docs, but googling around I see a few things that suggest
   originally the intent was to prevent userspace from starving the kernel by
   assigning one noise source to each -- but that that does not actually work.

   The bits are reserved on earlier CPUs and it is likely safe to frob them,
   but given the scarcity of VIA gear for testing these days -- let's not.

OK.  I was wondering more about the semantics of the underlying
hardware, but if the documentation is not public for a citation then
oh well.

   >    +               cpu_rng_init();
   >    +               if (cpu_rng(&test)) {
   >    +                       rndsource_setcb(&rnd_cpu_source, rnd_cpu_get,
   >    +                                       &rnd_cpu_source);
   >    +                       rnd_attach_source(&rnd_cpu_source, "cpurng",
   >    +                                         RND_TYPE_RNG,
   >    +                                         RND_FLAG_COLLECT_VALUE|
   >    +                                         RND_FLAG_HASCB|RND_FLAG_HASENABLE);
   > 
   > Why attach only if it immediately works?  A transient failure here
   > seems plausible enough to me, and there's no harm if it fails later.

   If I do that, we'll get a cpurng entropy source even on CPUs that don't
   actually have one.  I'd rather not.

In that case, why not make cpu_rng_init tell the caller whether or not
there is a CPU RNG?  It seems to me the CPU feature bits should
determine the presence of the rndsource, not the dynamic behaviour of
the hardware itself.