[Cryptography] [RFC] random: add new pseudorandom number generator
sandyinchina at gmail.com
Mon Oct 4 03:22:41 EDT 2021
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
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:
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
* 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.
More information about the cryptography