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: <CAHmME9pkhqjLtwn2kt5SkSWBQ9UW+2WLGL9momZUmY3L2wDryQ@mail.gmail.com>
Date:   Fri, 11 Feb 2022 22:56:03 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "open list:BROADCOM NVRAM DRIVER" <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>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Lennart Poettering <mzxreary@...inter.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH RFC v0] random: block in /dev/urandom

Hey Linus,

One thing I should clarify is that the GRND_INSECURE stuff for
getrandom(2) is a bit of a red herring with regards to the primary
intent of this patch, which is making /dev/urandom, the old char
device, block waiting for entropy.

Right now, we have:

/dev/random = getrandom(0)
/dev/urandom = getrandom(GRND_INSECURE)

This proposal is to make that:

/dev/random = getrandom(0)
/dev/urandom = getrandom(0)

Along the way I also got rid of GRND_INSECURE, but arguably that
should be a separate patch. This here is mostly about making
/dev/urandom block.

On 2/11/22, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> When try_to_generate_entropy() doesn't work, I think you now removed
> the possible fallback for user space to say "yeah, just give me best
> effort". And you might re-introduce a deadlock as a result.
>
> Those systems are arguably broken from a randomness standpoint - what
> the h*ll are you supposed to do if there's nothing generating entropy
> - but broken or not, I suspect they still exists. Those horrendous
> MIPS things were quite common in embedded networking (routers, access
> points - places that *should* care)
>
> Do I have a constructive suggestion for those broken platforms? No, I
> don't. That arguably is the reason for GRND_INSECURE existing, and the
> reason to keep it around.

It sounds like you're proposing a middle way here, which would be to
just call try_to_generate_entropy() (the "Linus Jitter Dance" code) if
!crng_ready() in /dev/urandom and getrandom(GRND_INSECURE). That's
actually a pretty good idea. It wouldn't break anything and would only
make the situation better on most systems. I think I'll probably take
your suggestion there, as it seems uncontroversially to be an
improvement.

Revisiting the original proposal though:

> I'd be willing to apply such a thing anyway - at some point "worry
> about broken platforms" ends up being too weak an excuse not to just
> apply it - but I'd like to hear more of a reason for this
simplification.

The justification for always waiting for randomness and never
returning insecure randomness to userspace isn't so much about
simplifying the code -- this patch isn't very large anyway -- but
rather for simplifying userspace crypto footguns. After several
decades of endless user confusion, we'd finally be able to say, "use
any single one of our random interfaces and you'll be fine. They're
all the same. It doesn't matter." And that, I think, would really be
something. Finally all of those blog posts and disagreeing forums and
contradictory articles would all become right about whatever they
recommended. So the one side of this is, "misconfigured userspace in a
computer history museum might run into trouble." The other side is,
"everybody gets good random numbers always." Today's thread's new
addition to that old argument is that your jitter dance makes the
downside a heck of a lot less than it used to be.

What do you make of that line of thought?

Jason