linux-kernel - Re: [PATCH v1] 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]

Date:   Wed, 23 Feb 2022 18:02:52 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Nick Hu <nickhu@...estech.com>,
        Max Filippov <jcmvbkbc@...il.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        "David S . Miller" <davem@...emloft.net>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Michal Simek <monstr@...str.eu>,
        Borislav Petkov <bp@...en8.de>, Guo Ren <guoren@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Joshua Kinard <kumba@...too.org>,
        David Laight <David.Laight@...lab.com>,
        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>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH v1] random: block in /dev/urandom

Hi Andy,

I think your analysis is a bit mismatched from the reality of the
situation. That reality is that cryptographic users still find
themselves using /dev/urandom, as that's been the "standard good
advice" for a very long time. And people are still encouraged to do
that, either out of ignorance or out of "compatibility". The
cryptographic problem is not going away.

Fixing this issue means, yes, adding a 1 second delay to the small
group of init system users who haven't switched to using
getrandom(GRND_INSECURE) for that less common usage (who even are
those users actually?). That's not breaking compatibility or breaking
userspace or breaking anything; that's accepting the reality of _how_
/dev/urandom is mostly used -- for crypto -- and making that usage
finally secure, at the expense of a 1 second delay for those other
users who haven't switched to getrandom(GRND_INSECURE) yet. That seems
like a _very_ small price to pay for eliminating a footgun.

And in general, deemphasizing the rare performance of the less common
usage in favor of fixing a commonly triggered footgun seems on par
with how things morph and change over time. There's no actual
breakage. There's no ABI change violation. What you're saying simply
isn't so.

In other words, I'm not really at all convinced by what you're saying.

Jason