From: David Laight <David.Laight@ACULAB.COM>
To: 'Linus Torvalds' <torvalds@linux-foundation.org>,
Eric Biggers <ebiggers@kernel.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Theodore Ts'o <tytso@mit.edu>,
"Dominik Brodowski" <linux@dominikbrodowski.net>,
Jann Horn <jannh@google.com>
Subject: RE: [RFC] Should writes to /dev/urandom immediately affect reads?
Date: Thu, 21 Sep 2023 21:57:26 +0000 [thread overview]
Message-ID: <4c5a6cd876d7499fa382ba74cd23cc08@AcuMS.aculab.com> (raw)
In-Reply-To: <CAHk-=wh+nAmcXV=Xz6fkDpazne+n+iFfGsnS=p9PjVLiEjiSvQ@mail.gmail.com>
From: Linus Torvalds
> Sent: 20 September 2023 21:41
>
> On Wed, 20 Sept 2023 at 13:32, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > It was why I also asked about entropy. Because *if* you argue that the
> > user-space write contains entropy, then that would be a reason.
>
> To clarify - the jitter entropy question was related to that same
> basic issue: if this was meant to be a way to mitigate the lack of
> jitter entropy on some platform you care about, that would again
> possibly be a reason to care.
>
> Considering that we apparently haven't cared for the last 7 years, I'm
> still a bit surprised, but whatever.
>
> What I *don't* want is just more voodoo discussions about /dev/*random
> behavior that doesn't have a technical reason for it.
This might all be related to an ongoing repeat of the 'how to initialise
/dev/urandom' on the busybox list.
Such systems are much more likely to be running completely jitter-free
cpu that boot from embedded serial flash with absolutely constant
access times.
The only way you are going to get any entropy early on is to have
saved it from the previous boot.
I don't think it makes any real sense so save it too early - you just
end up with an encoded 'count of the number of boots'.
At the moment it is pretty hard to add the saved entropy.
And you do want it to be used immediately - because what the
kernel has it likely to be pretty limited.
Now, once the startup scripts have run you might decide that an
immediate rehash isn't needed.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-09-21 22:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 6:06 [RFC] Should writes to /dev/urandom immediately affect reads? Eric Biggers
2023-09-20 18:48 ` Linus Torvalds
2023-09-20 19:32 ` Eric Biggers
2023-09-20 19:42 ` Linus Torvalds
2023-09-20 20:21 ` Eric Biggers
2023-09-20 20:32 ` Linus Torvalds
2023-09-20 20:41 ` Linus Torvalds
2023-09-21 21:57 ` David Laight [this message]
2023-09-20 20:45 ` Eric Biggers
2023-09-20 20:48 ` Linus Torvalds
2023-09-21 13:30 ` Theodore Ts'o
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=4c5a6cd876d7499fa382ba74cd23cc08@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Jason@zx2c4.com \
--cc=ebiggers@kernel.org \
--cc=jannh@google.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=torvalds@linux-foundation.org \
--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