Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5
Mime-Version: 1.0
Message-Id: <fbdd43e1-a305-48d1-8ccb-2deffcb715f7@www.fastmail.com>
In-Reply-To: <20220211210757.612595-1-Jason@zx2c4.com>
References: <20220211210757.612595-1-Jason@zx2c4.com>
Date:   Sat, 12 Feb 2022 19:15:31 -0800
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        "Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>
Cc:     "Paul Walmsley" <paul.walmsley@sifive.com>,
        "Palmer Dabbelt" <palmer@dabbelt.com>,
        "Albert Ou" <aou@eecs.berkeley.edu>,
        linux-riscv@lists.infradead.org,
        "Geert Uytterhoeven" <geert@linux-m68k.org>,
        linux-m68k@lists.linux-m68k.org,
        "Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
        linux-mips@vger.kernel.org,
        "Dominik Brodowski" <linux@dominikbrodowski.net>,
        "Eric Biggers" <ebiggers@google.com>,
        "Ard Biesheuvel" <ardb@kernel.org>,
        "Arnd Bergmann" <arnd@arndb.de>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        "Kees Cook" <keescook@chromium.org>,
        "Lennart Poettering" <mzxreary@0pointer.de>,
        "Linus Torvalds" <torvalds@linux-foundation.org>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [PATCH RFC v0] random: block in /dev/urandom
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Fri, Feb 11, 2022, at 1:07 PM, Jason A. Donenfeld wrote:
> This is very much an RFC patch, or maybe even an RFG -- request for
> grumbles. This topic has come up a million times, and usually doesn't =
go
> anywhere. This time I thought I'd bring it up with a slightly narrower
> focus. Before you read further, realize that I do not intend to merge
> this without there being an appropriate amount of consensus for it and
> discussion about it.
>
> Ever since Linus' 50ee7529ec45 ("random: try to actively add entropy
> rather than passively wait for it"), the RNG does a haveged-style jitt=
er
> dance around the scheduler, in order to produce entropy (and credit it)
> for the case when we're stuck in wait_for_random_bytes(). How ever you
> feel about the Linus Jitter Dance is beside the point: it's been there
> for three years and usually gets the RNG initialized in a second or so.

I dislike this patch for a reason that has nothing to do with security. =
Somewhere there=E2=80=99s a Linux machine that boots straight to Nethack=
 in a glorious 50ms.  If Nethack gets 256 bits of amazing entropy from /=
dev/urandom, then the machine=E2=80=99s owner has to play for real. If i=
t repeats the same game on occasion, the owner can be disappointed or am=
used. If it gets a weak seed that can be brute forced, then the owner ca=
n have fun brute forcing it.

If, on the other hand, it waits 750ms for enough jitter entropy to be pe=
rfect, it=E2=80=99s a complete fail.  No one wants to wait 750ms to play=
 Nethack.

Replace Nethack with something with a backup camera or a lightbulb, both=
 of which have regulations related to startup time, and there may be a r=
eal problem. Keep in mind that some language runtimes randomize their ha=
sh table seeds at startup, possibly using /dev/urandom. This patch may b=
reak actual, correct, working code.