Re: Lightweight support for instruction RNGs

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Dec 20, 2015 at 05:44:35PM -0500, Thor Lancelot Simon wrote:
> 
> Even without the latter, surely there is value to the former.  I
> believe it would serve for a number of other CPUs; for example I
> believe the RNG on Octeon and its successors is instruction based,
> and this way we could have a _single_ rndsource driver for all
> such CPUs rather than many drivers.

Not Octeon -- digging around, it must have been a different MIPSy
thing I was playing with.  So far, the original VIA design, plus the
two Intel ones.

I personally think it's nice to have an abstraction that covers at
least these 3 cases, which I really do think is directly analogous
to how we wrap cycle counter instructions with cpu_counter().

I can certainly wrap it in a rndsource, and drop the RNG code from the
Padlock driver, though I am not so sure that is better than what I
already did (again, please, I would really appreciate it if anyone would
_look at the code_ and think about it before commenting!).

If one doesn't think CPU RNGs are trustworthy (and many people seem
not to) then I would submit one should be happier with what I did
than with such a source wrapped in a rndsource, because what I did
guarantees that every single CPU RNG sample is mixed with input
from another source.  And it's cheaper, and it's much less code.

I can do it the other way too.  But could I get anyone to look at
the code and comment?

Thor