From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: Large post detailing recent Linux RNG improvements
Date: Thu, 24 Mar 2022 08:11:38 -0600 [thread overview]
Message-ID: <CAHmME9rWxkjgmXet=gQFWvhB6xvPgvAwkadZHRwdWrNGO6LZ0Q@mail.gmail.com> (raw)
In-Reply-To: <CACXcFmnhHpGQdU7ZcYNqjSss8VHMOtTvmJRETn18p0AY3AsEuQ@mail.gmail.com>
On Thu, Mar 24, 2022 at 4:29 AM Sandy Harris <sandyinchina@gmail.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?
Explanation in <https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=6e8ec2552c7d>.
There's also a link to a paper in there.
Jason
prev parent reply other threads:[~2022-03-24 14:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 0:00 Large post detailing recent Linux RNG improvements Jason A. Donenfeld
2022-03-24 6:51 ` Sandy Harris
2022-03-24 10:29 ` Sandy Harris
2022-03-24 14:11 ` Jason A. Donenfeld [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHmME9rWxkjgmXet=gQFWvhB6xvPgvAwkadZHRwdWrNGO6LZ0Q@mail.gmail.com' \
--to=jason@zx2c4.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sandyinchina@gmail.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).