linux-kernel - Re: [PATCH RFC v0] random: block in /dev/urandom

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]

Message-Id: <fbdd43e1-a305-48d1-8ccb-2deffcb715f7@www.fastmail.com>
Date:   Sat, 12 Feb 2022 19:15:31 -0800
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "Linux Crypto Mailing List" <linux-crypto@...r.kernel.org>
Cc:     "Paul Walmsley" <paul.walmsley@...ive.com>,
        "Palmer Dabbelt" <palmer@...belt.com>,
        "Albert Ou" <aou@...s.berkeley.edu>,
        linux-riscv@...ts.infradead.org,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        linux-m68k@...ts.linux-m68k.org,
        "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
        linux-mips@...r.kernel.org,
        "Dominik Brodowski" <linux@...inikbrodowski.net>,
        "Eric Biggers" <ebiggers@...gle.com>,
        "Ard Biesheuvel" <ardb@...nel.org>,
        "Arnd Bergmann" <arnd@...db.de>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Kees Cook" <keescook@...omium.org>,
        "Lennart Poettering" <mzxreary@...inter.de>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH RFC v0] random: block in /dev/urandom



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 jitter
> 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’s 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’s owner has to play for real. If it repeats the same game on occasion, the owner can be disappointed or amused. If it gets a weak seed that can be brute forced, then the owner can have fun brute forcing it.

If, on the other hand, it waits 750ms for enough jitter entropy to be perfect, it’s 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 real problem. Keep in mind that some language runtimes randomize their hash table seeds at startup, possibly using /dev/urandom. This patch may break actual, correct, working code.