Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CACXcFm=-E_wnDdRPztKJwDo8hvt6ENf84D90iFUXReuw2s0kuQ@mail.gmail.com>
 <CAAMy4UTgnpO9dv3hLzB_DWYfC-OAx6SYactSjL_J8oDJ76XfhA@mail.gmail.com>
In-Reply-To: <CAAMy4UTgnpO9dv3hLzB_DWYfC-OAx6SYactSjL_J8oDJ76XfhA@mail.gmail.com>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Mon, 4 Oct 2021 15:22:41 +0800
Message-ID: <CACXcFmnLa5gGa9+V5Do6Wbimup5rh3nkaUcTwThUGpWZH8gyxw@mail.gmail.com>
Subject: Re: [Cryptography] [RFC] random: add new pseudorandom number generator
To:     Tom Mitchell <mitch@niftyegg.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Cryptography <cryptography@metzdowd.com>,
        "Ted Ts'o" <tytso@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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