linux-kernel - RE: [RFC] Should writes to /dev/urandom immediately affect reads?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 21 Sep 2023 21:57:26 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Eric Biggers <ebiggers@...nel.org>
CC:     "Jason A. Donenfeld" <Jason@...c4.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>,
        "Dominik Brodowski" <linux@...inikbrodowski.net>,
        Jann Horn <jannh@...gle.com>
Subject: RE: [RFC] Should writes to /dev/urandom immediately affect reads?

From: Linus Torvalds
> Sent: 20 September 2023 21:41
> 
> On Wed, 20 Sept 2023 at 13:32, Linus Torvalds
> <torvalds@...ux-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)