On Mon, Oct 4, 2021 Tom Mitchell <mitch@xxxxxxxxxxxx> 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.
