Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <CAHmME9q55ifnzxE9zLuLT=Hgjv=qcvjU-O-c8G=_o_V_O+p44Q@mail.gmail.com>
 <CACXcFmnb87qqzVkw9GfojPNh5sDkYGsqq9TYxUXBvrC1R+Lr3w@mail.gmail.com>
In-Reply-To: <CACXcFmnb87qqzVkw9GfojPNh5sDkYGsqq9TYxUXBvrC1R+Lr3w@mail.gmail.com>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Thu, 24 Mar 2022 18:29:28 +0800
Message-ID: <CACXcFmnhHpGQdU7ZcYNqjSss8VHMOtTvmJRETn18p0AY3AsEuQ@mail.gmail.com>
Subject: Re: Large post detailing recent Linux RNG improvements
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Kernel Hardening <kernel-hardening@lists.openwall.com>,
        "Theodore Ts'o" <tytso@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Sandy Harris <sandyinchina@gmail.com> wrote:

> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > Thought I should mention here that I've written up the various RNG
> > things I've been working on for 5.17 & 5.18 here:
> > https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ .
> >
> > Feel free to discuss on list here if you'd like, or if you see
> > something you don't like, I'll happily review patches!
>
> Your code includes:
>
> enum {
>     POOL_BITS = BLAKE2S_HASH_SIZE * 8,
>     POOL_MIN_BITS = POOL_BITS /* No point in settling for less. */
> };
>
> static struct {
>     struct blake2s_state hash;
>     spinlock_t lock;
>     unsigned int entropy_count;
> } input_pool = {
>     .hash.h = { BLAKE2S_IV0 ^ (0x01010000 | BLAKE2S_HASH_SIZE),
>             BLAKE2S_IV1, BLAKE2S_IV2, BLAKE2S_IV3, BLAKE2S_IV4,
>             BLAKE2S_IV5, BLAKE2S_IV6, BLAKE2S_IV7 },
>     .hash.outlen = BLAKE2S_HASH_SIZE,
>     .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
> };
>
> As far as I can tell, you have eliminated the 4K-bit input pool
> that this driver has always used & are just using the hash
> context as the input pool. To me, this looks like an error.
>
> A side effect of that is losing the latent-entropy attribute
> on input_pool[] so we no longer get initialisation from
> the plugin. Another error.

I could see reasonable arguments for reducing the size of
the input pool since that would save both kernel memory
and time used by the hash. Personally, though, I would
not consider anything < 2Kbits without seeing strong
arguments to justify it.

You seem to have gone to 512 bits without showing
any analysis to justify it. Have I just missed them?