From: "Ahmed S. Darwish" <darwish.07@gmail.com> To: Willy Tarreau <w@1wt.eu> Cc: Lennart Poettering <mzxreary@0pointer.de>, "Theodore Y. Ts'o" <tytso@mit.edu>, Linus Torvalds <torvalds@linux-foundation.org>, "Alexander E. Patrakov" <patrakov@gmail.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Andreas Dilger <adilger.kernel@dilger.ca>, Jan Kara <jack@suse.cz>, Ray Strode <rstrode@redhat.com>, William Jon McCann <mccann@jhu.edu>, zhangjs <zachary@baishancloud.com>, linux-ext4@vger.kernel.org, lkml <linux-kernel@vger.kernel.org> Subject: Re: [PATCH RFC v3] random: getrandom(2): optionally block when CRNG is uninitialized Date: Sun, 15 Sep 2019 12:02:01 +0200 Message-ID: <20190915100201.GA2663@darwi-home-pc> (raw) In-Reply-To: <20190915093057.GF20811@1wt.eu> On Sun, Sep 15, 2019 at 11:30:57AM +0200, Willy Tarreau wrote: > On Sun, Sep 15, 2019 at 10:59:07AM +0200, Lennart Poettering wrote: > > We live in a world where people run HTTPS, SSH, and all that stuff in > > the initrd already. It's where SSH host keys are generated, and plenty > > session keys. > > It is exactly the type of crap that create this situation : making > people developing such scripts believe that any random source was OK > to generate these, and as such forcing urandom to produce crypto-solid > randoms! Willy, let's tone it down please... the thread is already getting a bit toxic. > No, distro developers must know that it's not acceptable to > generate lifetime crypto keys from the early boot when no entropy is > available. At least with this change they will get an error returned > from getrandom() and will be able to ask the user to feed entropy, or > be able to say "it was impossible to generate the SSH key right now, > the daemon will only be started once it's possible", or "the SSH key > we produced will not be saved because it's not safe and is only usable > for this recovery session". > > > If Linux lets all that stuff run with awful entropy then > > you pretend things where secure while they actually aren't. It's much > > better to fail loudly in that case, I am sure. > > This is precisely what this change permits : fail instead of block > by default, and let applications decide based on the use case. > Unfortunately, not exactly. Linus didn't want getrandom to return an error code / "to fail" in that case, but to silently return CRNG-uninitialized /dev/urandom data, to avoid user-space even working around the error code through busy-loops. I understand the rationale behind that, of course, and this is what I've done so far in the V3 RFC. Nonetheless, this _will_, for example, make systemd-random-seed(8) save week seeds under /var/lib/systemd/random-seed, since the kernel didn't inform it about such weakness at all.. The situation is so bad now, that it's more of "some user-space are more equal than others".. Let's just at least admit this while discussing the RFC patch in question. thanks, > > Quite frankly, I don't think this is something to fix in the > > kernel. > > As long as it offers a single API to return randoms, and that it is > not possible not to block for low-quality randoms, it needs to be > at least addressed there. Then userspace can adapt. For now userspace > does not have this option just due to the kernel's way of exposing > randoms. > > Willy
next prev parent reply index Thread overview: 213+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-08 20:59 Linux 5.3-rc8 Linus Torvalds 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 [this message] 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-20 0:51 ` [random] ec47a799bf: WARNING:at_drivers/char/random.c:#getrandom_wait kernel test robot 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 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=20190915100201.GA2663@darwi-home-pc \ --to=darwish.07@gmail.com \ --cc=adilger.kernel@dilger.ca \ --cc=jack@suse.cz \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mccann@jhu.edu \ --cc=mtk.manpages@gmail.com \ --cc=mzxreary@0pointer.de \ --cc=patrakov@gmail.com \ --cc=rstrode@redhat.com \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ --cc=w@1wt.eu \ --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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lkml.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lkml.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lkml.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lkml.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lkml.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lkml.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lkml.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lkml.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lkml.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lkml.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lkml.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git