From: Linus Torvalds <torvalds@linux-foundation.org> To: "Ahmed S. Darwish" <darwish.07@gmail.com> Cc: "Theodore Y. Ts'o" <tytso@mit.edu>, 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, Lennart Poettering <lennart@poettering.net>, lkml <linux-kernel@vger.kernel.org> Subject: Re: Linux 5.3-rc8 Date: Sat, 14 Sep 2019 09:30:19 -0700 Message-ID: <CAHk-=wjuVT+2oj_U2V94MBVaJdWsbo1RWzy0qXQSMAUnSaQzxw@mail.gmail.com> (raw) In-Reply-To: <20190914150206.GA2270@darwi-home-pc> On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish <darwish.07@gmail.com> wrote: > > On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote: > > > > An alternative might be to make getrandom() just return an error > > instead of waiting. Sure, fill the buffer with "as random as we can" > > stuff, but then return -EINVAL because you called us too early. > > ACK, that's probably _the_ most sensible approach. Only caveat is > the slight change in user-space API semantics though... > > For example, this breaks the just released systemd-random-seed(8) > as it _explicitly_ requests blocking behvior from getrandom() here: > Actually, I would argue that the "don't ever block, instead fill buffer and return error instead" fixes this broken case. > => src/random-seed/random-seed.c: > /* > * Let's make this whole job asynchronous, i.e. let's make > * ourselves a barrier for proper initialization of the > * random pool. > */ > k = getrandom(buf, buf_size, GRND_NONBLOCK); > if (k < 0 && errno == EAGAIN && synchronous) { > log_notice("Kernel entropy pool is not initialized yet, " > "waiting until it is."); > > k = getrandom(buf, buf_size, 0); /* retry synchronously */ > } Yeah, the above is yet another example of completely broken garbage. You can't just wait and block at boot. That is simply 100% unacceptable, and always has been, exactly because that may potentially mean waiting forever since you didn't do anything that actually is likely to add any entropy. > if (k < 0) { > log_debug_errno(errno, "Failed to read random data with " > "getrandom(), falling back to " > "/dev/urandom: %m"); At least it gets a log message. So I think the right thing to do is to just make getrandom() return -EINVAL, and refuse to block. As mentioned, this has already historically been a huge issue on embedded devices, and with disks turnign not just to NVMe but to actual polling nvdimm/xpoint/flash, the amount of true "entropy" randomness we can give at boot is very questionable. We can (and will) continue to do a best-effort thing (including very much using rdread and friends), but the whole "wait for entropy" simply *must* stop. > I've sent an RFC patch at [1]. > > [1] https://lkml.kernel.org/r/20190914122500.GA1425@darwi-home-pc Looks reasonable to me. Except I'd just make it simpler and make it a big WARN_ON_ONCE(), which is a lot harder to miss than pr_notice(). Make it clear that it is a *bug* if user space thinks it should wait at boot time. Also, we might even want to just fill the buffer and return 0 at that point, to make sure that even more broken user space doesn't then try to sleep manually and turn it into a "I'll wait myself" loop. Linus
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 [this message] 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 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='CAHk-=wjuVT+2oj_U2V94MBVaJdWsbo1RWzy0qXQSMAUnSaQzxw@mail.gmail.com' \ --to=torvalds@linux-foundation.org \ --cc=adilger.kernel@dilger.ca \ --cc=darwish.07@gmail.com \ --cc=jack@suse.cz \ --cc=lennart@poettering.net \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mccann@jhu.edu \ --cc=patrakov@gmail.com \ --cc=rstrode@redhat.com \ --cc=tytso@mit.edu \ --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