From: Willy Tarreau <w@1wt.eu> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "Theodore Y. Ts'o" <tytso@mit.edu>, Vito Caputo <vcaputo@pengaru.com>, "Ahmed S. Darwish" <darwish.07@gmail.com>, Lennart Poettering <mzxreary@0pointer.de>, Andreas Dilger <adilger.kernel@dilger.ca>, Jan Kara <jack@suse.cz>, Ray Strode <rstrode@redhat.com>, William Jon McCann <mccann@jhu.edu>, "Alexander E. Patrakov" <patrakov@gmail.com>, zhangjs <zachary@baishancloud.com>, linux-ext4@vger.kernel.org, lkml <linux-kernel@vger.kernel.org> Subject: Re: Linux 5.3-rc8 Date: Mon, 16 Sep 2019 08:12:52 +0200 Message-ID: <20190916061252.GA24002@1wt.eu> (raw) In-Reply-To: <CAHk-=wg4cONuiN32Tne28Cg2kEx6gsJCoOVroqgPFT7_Kg18Hg@mail.gmail.com> On Sun, Sep 15, 2019 at 10:02:02PM -0700, Linus Torvalds wrote: > On Sun, Sep 15, 2019 at 9:30 PM Willy Tarreau <w@1wt.eu> wrote: > > > > I'd be in favor of adding in the man page something like "this > > random source is only suitable for applications which will not be > > harmed by getting a predictable value on output, and as such it is > > not suitable for generation of system keys or passwords, please > > use GRND_RANDOM for this". > > The problem with GRND_RANDOM is that it also ends up extracting > entropy, and has absolutely horrendous performance behavior. It's why > hardly anybody uses /dev/random. > > Which nobody should really ever do. I don't understand why people want > that thing, considering that the second law of thermodynamics really > pretty much applies. If you can crack the cryptographic hashes well > enough to break them despite reseeding etc, people will have much more > serious issues than the entropy accounting. That's exactly what I was thinking about a few minutes ago and which drove me back to mutt :-) > So the problem with getrandom() is that it only offered two flags, and > to make things worse they were the wrong ones. (...) > - GRND_RANDOM | GRND_NONBLOCK - don't use > > This won't block, but it will decrease the blocking pool entropy. > > It might be an acceptable "get me a truly secure ring with reliable > performance", but when it fails, you're going to be unhappy, and there > is no obvious fallback. > > So three out of four flag combinations end up being mostly "don't > use", and the fourth one isn't what you'd normally want (which is just > plain /dev/urandom semantics). I'm seeing it from a different angle. I now understand better why getrandom() absolutely wants to have an initialized pool, it's to encourage private key producers to use a secure, infinite source of randomness. Something that neither /dev/random nor /dev/urandom reliably provide. Unfortunately it does it by changing how urandom works while it ought to have done it as the replacement of /dev/random. The 3 random generation behaviors we currently support are : - /dev/random: only returns safe random (blocks), AND depletes entropy. getrandom(GRND_RANDOM) does the same. - /dev/urandom: returns whatever (never blocks), inexhaustible - getrandom(0): returns safe random (blocks), inexhaustible Historically we used to want to rely on /dev/random for SSH keys and certificates. It's arguable that with the massive increase of crypto usage, what used to be done only once in a system's life happens a bit more often and using /dev/random here can sometimes become a problem because it harms the whole system (thus why I said I think that we could almost require CAP_something to access it). Applications falling back to /dev/urandom obviously resulted in the massive mess we've seen years ago, even if it apparently solved the problem for their users. Thus getrandom(0) does make sense, but not as an alternative to urandom but to random, since it returns randoms safe for use for long lived keys. Couldn't we simply change the way things work ? Make GRND_RANDOM *not* deplate entropy, and document it as the only safe source, and make the default call return the same as /dev/urandom ? We can then use your timeout mechanism for the first one (which is not supposed to be called often and would be more accepted with a moderately long delay). Applications need to evolve as well. It's fine to use libraries to do whatever you need for you but ultimately the lib exports a function for a generic use case and doesn't know how to best adapt to the use case. Typically I would expect an SSH/HTTP daemon running in a recovery initramfs to produce unsafe randoms so that I can connect there without having to dance around it. However the self-signed cert produced there must not be saved, just like the SSH host key. But this means that the application (here the ssh-keygen or openssl) also need to be taught to purposely produce insecure keys when explicitly instructed to do so. Otherwise we know what will happen in the long term, since history repeats itself as long as the conditions are not changed :-/ Willy
next prev parent reply index Thread overview: 211+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CAHk-=whBQ+6c-h+htiv6pp8ndtv97+45AH9WvdZougDRM6M4VQ@mail.gmail.com> 2019-09-10 4:21 ` Ahmed S. Darwish 2019-09-10 11:33 ` Linus Torvalds 2019-09-10 12:21 ` Linus Torvalds 2019-09-10 17:33 ` Ahmed S. Darwish 2019-09-10 17:47 ` Reindl Harald 2019-09-10 18:21 ` Linus Torvalds 2019-09-11 16:07 ` Theodore Y. Ts'o 2019-09-11 16:45 ` Linus Torvalds 2019-09-11 17:00 ` Linus Torvalds 2019-09-11 17:36 ` Theodore Y. Ts'o 2019-09-12 3:44 ` Ahmed S. Darwish 2019-09-12 8:25 ` Theodore Y. Ts'o 2019-09-12 11:34 ` Linus Torvalds 2019-09-12 11:58 ` Willy Tarreau 2019-09-14 12:25 ` [PATCH RFC] random: getrandom(2): don't block on non-initialized entropy pool Ahmed S. Darwish 2019-09-14 14:08 ` Alexander E. Patrakov 2019-09-15 5:22 ` [PATCH RFC v2] random: optionally block in getrandom(2) when the CRNG is uninitialized Theodore Y. Ts'o 2019-09-15 8:17 ` [PATCH RFC v3] random: getrandom(2): optionally block when " Ahmed S. Darwish 2019-09-15 8:59 ` Lennart Poettering 2019-09-15 9:30 ` Willy Tarreau 2019-09-15 10:02 ` Ahmed S. Darwish 2019-09-15 10:40 ` Willy Tarreau 2019-09-15 10:55 ` Ahmed S. Darwish 2019-09-15 11:17 ` Willy Tarreau 2019-09-15 17:32 ` [PATCH RFC v2] random: optionally block in getrandom(2) when the " Linus Torvalds 2019-09-15 18:32 ` Willy Tarreau 2019-09-15 18:36 ` Willy Tarreau 2019-09-15 19:08 ` Linus Torvalds 2019-09-15 19:18 ` Willy Tarreau 2019-09-15 19:31 ` Linus Torvalds 2019-09-15 19:54 ` Willy Tarreau 2019-09-15 18:59 ` Linus Torvalds 2019-09-15 19:12 ` Willy Tarreau 2019-09-16 2:45 ` Ahmed S. Darwish 2019-09-16 18:08 ` Lennart Poettering 2019-09-16 19:16 ` Willy Tarreau 2019-09-18 21:15 ` [PATCH RFC v4 0/1] random: WARN on large getrandom() waits and introduce getrandom2() Ahmed S. Darwish 2019-09-18 21:17 ` [PATCH RFC v4 1/1] " Ahmed S. Darwish 2019-09-18 23:57 ` Linus Torvalds 2019-09-19 14:34 ` Theodore Y. Ts'o 2019-09-19 15:20 ` Linus Torvalds 2019-09-19 15:50 ` Linus Torvalds 2019-09-20 13:13 ` Theodore Y. Ts'o 2019-09-19 20:04 ` Linus Torvalds 2019-09-19 20:45 ` Alexander E. Patrakov 2019-09-19 21:47 ` Linus Torvalds 2019-09-19 22:23 ` Alexander E. Patrakov 2019-09-19 23:44 ` Alexander E. Patrakov 2019-09-20 13:16 ` Theodore Y. Ts'o 2019-09-23 11:55 ` David Laight 2019-09-20 13:08 ` Theodore Y. Ts'o 2019-09-20 13:46 ` Ahmed S. Darwish 2019-09-20 14:33 ` Andy Lutomirski 2019-09-20 16:29 ` Linus Torvalds 2019-09-20 17:52 ` Andy Lutomirski 2019-09-20 18:09 ` Linus Torvalds 2019-09-20 18:16 ` Willy Tarreau 2019-09-20 19:12 ` Andy Lutomirski 2019-09-20 19:51 ` Linus Torvalds 2019-09-20 20:11 ` Alexander E. Patrakov 2019-09-20 20:17 ` Matthew Garrett 2019-09-20 20:51 ` Andy Lutomirski 2019-09-20 22:44 ` Linus Torvalds 2019-09-20 23:30 ` Andy Lutomirski 2019-09-21 3:05 ` Willy Tarreau 2019-09-21 6:07 ` Florian Weimer 2019-09-23 18:33 ` Andy Lutomirski 2019-09-26 21:11 ` Ahmed S. Darwish 2019-09-20 18:12 ` Willy Tarreau 2019-09-20 19:22 ` Andy Lutomirski 2019-09-20 19:37 ` Willy Tarreau 2019-09-20 19:52 ` Andy Lutomirski 2019-09-20 20:02 ` Linus Torvalds 2019-09-20 18:15 ` Alexander E. Patrakov 2019-09-20 18:29 ` Andy Lutomirski 2019-09-20 17:26 ` Willy Tarreau 2019-09-20 17:56 ` Ahmed S. Darwish 2019-09-26 20:42 ` [PATCH v5 0/1] random: getrandom(2): warn on large CRNG waits, introduce new flags Ahmed S. Darwish 2019-09-26 20:44 ` [PATCH v5 1/1] " Ahmed S. Darwish 2019-09-26 21:39 ` Andy Lutomirski 2019-09-28 9:30 ` Ahmed S. Darwish 2019-09-14 15:02 ` Linux 5.3-rc8 Ahmed S. Darwish 2019-09-14 16:30 ` Linus Torvalds 2019-09-14 16:35 ` Alexander E. Patrakov 2019-09-14 16:52 ` Linus Torvalds 2019-09-14 17:09 ` Alexander E. Patrakov 2019-09-14 19:19 ` Linus Torvalds 2019-09-15 6:56 ` Lennart Poettering 2019-09-15 7:01 ` Willy Tarreau 2019-09-15 7:05 ` Lennart Poettering 2019-09-15 7:07 ` Willy Tarreau 2019-09-15 8:34 ` Lennart Poettering 2019-09-15 17:02 ` Linus Torvalds 2019-09-16 3:23 ` Theodore Y. Ts'o 2019-09-16 3:40 ` Linus Torvalds 2019-09-16 3:56 ` Linus Torvalds 2019-09-16 17:00 ` Theodore Y. Ts'o 2019-09-16 17:07 ` Linus Torvalds 2019-09-14 21:11 ` Ahmed S. Darwish 2019-09-14 22:05 ` Martin Steigerwald 2019-09-14 22:24 ` Theodore Y. Ts'o 2019-09-14 22:32 ` Linus Torvalds 2019-09-15 1:00 ` Theodore Y. Ts'o 2019-09-15 1:10 ` Linus Torvalds 2019-09-15 2:05 ` Theodore Y. Ts'o 2019-09-15 2:11 ` Linus Torvalds 2019-09-15 6:33 ` Willy Tarreau 2019-09-15 6:53 ` Willy Tarreau 2019-09-15 6:51 ` Lennart Poettering 2019-09-15 7:27 ` Ahmed S. Darwish 2019-09-15 8:48 ` Lennart Poettering 2019-09-15 16:29 ` Linus Torvalds 2019-09-16 1:40 ` Ahmed S. Darwish 2019-09-16 1:48 ` Vito Caputo 2019-09-16 2:49 ` Theodore Y. Ts'o 2019-09-16 4:29 ` Willy Tarreau 2019-09-16 5:02 ` Linus Torvalds 2019-09-16 6:12 ` Willy Tarreau [this message] 2019-09-16 16:17 ` Linus Torvalds 2019-09-16 17:21 ` Theodore Y. Ts'o 2019-09-16 17:44 ` Linus Torvalds 2019-09-16 17:55 ` Serge Belyshev 2019-09-16 19:08 ` Willy Tarreau 2019-09-16 23:02 ` Matthew Garrett 2019-09-16 23:05 ` Linus Torvalds 2019-09-16 23:11 ` Matthew Garrett 2019-09-16 23:13 ` Alexander E. Patrakov 2019-09-16 23:15 ` Matthew Garrett 2019-09-16 23:18 ` Linus Torvalds 2019-09-16 23:29 ` Ahmed S. Darwish 2019-09-17 1:05 ` Linus Torvalds 2019-09-17 1:23 ` Matthew Garrett 2019-09-17 1:41 ` Linus Torvalds 2019-09-17 1:46 ` Matthew Garrett 2019-09-17 5:24 ` Willy Tarreau 2019-09-17 7:33 ` Martin Steigerwald 2019-09-17 8:35 ` Willy Tarreau 2019-09-17 8:44 ` Martin Steigerwald 2019-09-17 12:11 ` Theodore Y. Ts'o 2019-09-17 12:30 ` Ahmed S. Darwish 2019-09-17 12:46 ` Alexander E. Patrakov 2019-09-17 12:47 ` Willy Tarreau 2019-09-17 16:08 ` Lennart Poettering 2019-09-17 16:23 ` Linus Torvalds 2019-09-17 16:34 ` Reindl Harald 2019-09-17 17:42 ` Lennart Poettering 2019-09-17 18:01 ` Linus Torvalds 2019-09-17 20:28 ` Martin Steigerwald 2019-09-17 20:52 ` Ahmed S. Darwish 2019-09-17 21:38 ` Martin Steigerwald 2019-09-17 21:52 ` Matthew Garrett 2019-09-17 22:10 ` Martin Steigerwald 2019-09-18 13:53 ` Lennart Poettering 2019-09-19 7:28 ` Martin Steigerwald 2019-09-17 23:08 ` Linus Torvalds 2019-09-18 13:40 ` Lennart Poettering 2019-09-17 20:58 ` Linus Torvalds 2019-09-18 9:33 ` Rasmus Villemoes 2019-09-18 10:16 ` Willy Tarreau 2019-09-18 10:25 ` Alexander E. Patrakov 2019-09-18 10:42 ` Willy Tarreau 2019-09-18 19:31 ` Linus Torvalds 2019-09-18 19:56 ` Eric W. Biederman 2019-09-18 20:13 ` Linus Torvalds 2019-09-18 20:15 ` Alexander E. Patrakov 2019-09-18 20:26 ` Linus Torvalds 2019-09-18 22:12 ` Willy Tarreau 2019-09-27 13:57 ` Lennart Poettering 2019-09-27 15:58 ` Linus Torvalds 2019-09-29 9:05 ` Lennart Poettering 2019-09-17 13:11 ` Alexander E. Patrakov 2019-09-17 13:37 ` Alexander E. Patrakov 2019-09-17 15:57 ` Lennart Poettering 2019-09-17 16:21 ` Willy Tarreau 2019-09-17 17:13 ` Lennart Poettering 2019-09-17 17:29 ` Willy Tarreau 2019-09-17 20:42 ` Martin Steigerwald 2019-09-18 13:38 ` Lennart Poettering 2019-09-18 13:59 ` Alexander E. Patrakov 2019-09-18 14:50 ` Alexander E. Patrakov 2019-09-17 20:36 ` Martin Steigerwald 2019-09-17 16:27 ` Linus Torvalds 2019-09-17 16:34 ` Matthew Garrett 2019-09-17 17:16 ` Willy Tarreau 2019-09-17 17:20 ` Matthew Garrett 2019-09-17 17:23 ` Matthew Garrett 2019-09-17 17:57 ` Willy Tarreau 2019-09-17 16:58 ` Alexander E. Patrakov 2019-09-17 17:30 ` Lennart Poettering 2019-09-17 17:32 ` Willy Tarreau 2019-09-17 17:41 ` Alexander E. Patrakov 2019-09-17 17:28 ` Lennart Poettering 2019-09-17 0:03 ` Matthew Garrett 2019-09-17 0:40 ` Matthew Garrett 2019-09-17 7:15 ` a sane approach to random numbers (was: Re: Linux 5.3-rc8) Martin Steigerwald 2019-09-16 18:00 ` Linux 5.3-rc8 Alexander E. Patrakov 2019-09-16 19:53 ` Ahmed S. Darwish 2019-09-17 15:32 ` Lennart Poettering 2019-09-16 3:31 ` Linus Torvalds 2019-09-23 20:49 ` chaos generating driver was " Pavel Machek 2019-09-14 9:25 ` Ahmed S. Darwish 2019-09-14 16:27 ` Theodore Y. Ts'o 2019-09-11 21:41 ` Ahmed S. Darwish 2019-09-11 22:37 ` Ahmed S. Darwish 2019-09-16 3:52 ` Herbert Xu 2019-09-16 4:21 ` Linus Torvalds 2019-09-16 4:53 ` Willy Tarreau 2019-09-10 11:56 ` Theodore Y. Ts'o 2019-09-16 10:33 ` Christoph Hellwig 2019-10-03 21:10 ` Jon Masters 2019-10-03 21:31 ` Jon Masters
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190916061252.GA24002@1wt.eu \ --to=w@1wt.eu \ --cc=adilger.kernel@dilger.ca \ --cc=darwish.07@gmail.com \ --cc=jack@suse.cz \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mccann@jhu.edu \ --cc=mzxreary@0pointer.de \ --cc=patrakov@gmail.com \ --cc=rstrode@redhat.com \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ --cc=vcaputo@pengaru.com \ --cc=zachary@baishancloud.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-ext4 Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-ext4/0 linux-ext4/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-ext4 linux-ext4/ https://lore.kernel.org/linux-ext4 \ linux-ext4@vger.kernel.org public-inbox-index linux-ext4 Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-ext4 AGPL code for this site: git clone https://public-inbox.org/public-inbox.git