[Cryptography] [RFC] random: add new pseudorandom number generator

[Sandy Harris]

On Mon, Oct 4, 2021 Tom Mitchell <mitch at niftyegg.com> wrote:

> How do you plan to get this into the Linux community for testing?
> In a cluster of machines a PRNG kernel update and verification process
> seems tedious and difficult to tidy up after a problem is found or
> suspected.

I'll submit it as a kernel patch; there's a procedure in place to test
those before acceptance. I'm doing this RFC version first to try
and be certain I have it right before submitting.

> Spinlocks ... hmmm... now I need to look at how the kernel can ignore
> or not need them?

The spinlocks in my code are rather dubious emulations used
for out-of-kernel testing. My comments include:

* The locking here is completely untested and quite likely
* to be partly wrong. I just define emulations for spin_lock()
* and spin_unlock() and stick them in as reminders of where
* locks are needed.
....
 * this will catch some basic blunders
 * like taking a lock that the calling code holds
 *
 * it is definitely not enough for serious lock tests

The current driver uses spinlocks fairly extensively.
There was a thread on the linux crypto list about
getting rid of those locks:
https://www.spinics.net/lists/linux-crypto/msg55255.html
but as far as I know the prposal went nowhere.

Another comment in my code is:
* I add two new locks, one for xtea and and an output lock
* which all output routines take. Contexts are updated
* within that lock, so duplicate outputs are astronomically
* unlikely.
*
* In the rest of the code, I only lock data structures which
* are being written to, never ones that are only read. If
* someone writes while we are reading then read output becomes
* indeterminate, and in most applications that would be a Bad
* Thing. In an rng, though, it is at worst harmless, and
* arguably even a Good Thing.