Re: Lightweight support for instruction RNGs

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

On Mon, Dec 21, 2015 at 12:06:38AM +0000, Taylor R Campbell wrote:
> 
> This is an API concern.  It sounds like the operative difference of
> the cpu_rng API from the rndsource API is that the cpu_rng API is
> optimized for callback-only entropy sources which never sleep for I/O
> or require any inter-CPU communication.  E.g., it sounds like
> bcmrng(4) would satisfy this contract too.

Looked at from that point of view, the Octeon RNG (which just reads an
I/O register that's actually local to the CPU) is close enough too.

I do not think you will ever encounter a CPU that has more than one
onboard entropy source (RDRAND and RDSEED are just two different ways
to read from the same source); so I do think that a simple, MI cpu_rng
wrapper is a good abstraction to have.

If you're going to slim down and speed up the rndsource implementation,
we can probably use a single, clean, little driver to hook any port's
cpu_rng up to it, and all done.

Does that make sense to you?

Keccak would be a lot better than the current rndpool mess, and 
per-CPU pools better than one global pool, so long as we avoid some
of the pain Linux bought that way.

Thor