Re: Lightweight support for instruction RNGs

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

On Sun, Dec 20, 2015 at 10:34:29PM +0000, Taylor R Campbell wrote:
>    Date: Sat, 19 Dec 2015 19:37:22 -0500
>    From: Thor Lancelot Simon <tls%panix.com@localhost>
> 
>    I was playing with code for a RDRAND/RDSEED entropy source and it
>    just felt like -- much like opencrypto is poorly suited for crypto
>    via unprivileged CPU instructions -- our rndsource interface is
>    a little too heavy for CPU RNGs implemented as instructions.
> 
> Why is it a little too heavy?

There's a huge amount of locking and recordkeeping, when the entire
point of an RNG implemented as a CPU instruction is that it's so quick
and cheap you can use it without worrying about the cost.

> How does the cpu_rng abstraction improve it?

It's pretty much the simplest possible glue, wrapped around the RNG
instruction.  All it really does is ensure the CPU you're running on
_has_ such an instruction before calling it.

> I'm very leery of adding more mechanism to an already unbelievably
> complicated entropy pool system, and particularly of a special
> mechanism for RDRAND/RDSEED.

Please note that that's exactly what I did *not* do.  I built a very
thin abstraction that's roughly equivalent to cpu_counter(), and I
adjusted the existing rndpool code to call it in exactly one place.

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.

I was hoping someone -- anyone -- would actually look at the code
rather than commenting without looking.  It might be best of all
if it were you.  Please?

Thor