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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Sep 2023 13:21:26 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-kernel@...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?

On Wed, Sep 20, 2023 at 12:42:54PM -0700, Linus Torvalds wrote:
> On Wed, 20 Sept 2023 at 12:32, Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > >
> > > Also, are there any relevant architectures where
> > > "try_to_generate_entropy()" doesn't work? IOW, why do you even care?
> > >
> >
> > There are, as shown by the fact that the full unification of /dev/urandom and
> > /dev/random failed yet again.
> 
> No, no. That only showed that such architectures exist. It didn't show
> that any *relevant* architectures exist.
> 
> The ones reported on were 32-bit arm, m68k, microblaze, sparc32,
> xtensa.. Maybe others.
> 
> > But similarly, that's unrelated.
> 
> They are related in the sense fo "why do you actually *care*?"
> 
> Because I don't see why any of this actually matters.
> 

It seems that what you're claiming (in addition to the RNG always being
initialized quickly on platforms that are "relevant", whatever that means) is
that once the RNG is "initialized", there's no need to reseed it anymore.  This
was covered extensively in previous discussions.  It's true in a theoretical
sense, but in practice the "initialized" state is just an approximation.  In
practice, the RNG might have collected either more *or less* entropy than the
needed 256 bits.  *Probably* more, since many of the entropy sources are
estimated conservatively, but it never knows for sure.  That's why the RNG still
reseeds itself periodically.  The question is, given that, shouldn't the RNG
also reseed right away when userspace explicitly adds something to it.  After
all, regardless of which of the mythical Two Big States (initialized or
uninitialized) the kernel considers the RNG to be in, userspace almost certianly
wants the data it wrote to /dev/{u,}random to actually be used.

It's true that the earlier in the boot it is, the more important reseeding is in
general, and the RNG's reseeding schedule already reflects that by doing faster
reseeds for the first 5 minutes of uptime.  We *could* do something similar and
only do the immediate reseed for the first 5 minutes of uptime.  I expect it's
not worth the complexity vs. unconditionally doing it, but it's an option.

BTW, previously you were supportive of using new entropy immediately:
https://lore.kernel.org/linux-crypto/CAHk-=wiq3bKDdt7noWOaMnDL-yYfFHb1CEsNkk8huq4O7ByetA@mail.gmail.com
So it seems that you've changed your opinion?

- Eric