From: "Ahmed S. Darwish" <darwish.07@gmail.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lennart Poettering <mzxreary@0pointer.de>, "Theodore Y. Ts'o" <tytso@mit.edu>, "Eric W. Biederman" <ebiederm@xmission.com>, "Alexander E. Patrakov" <patrakov@gmail.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Willy Tarreau <w@1wt.eu>, Matthew Garrett <mjg59@srcf.ucam.org>, lkml <linux-kernel@vger.kernel.org>, linux-ext4@vger.kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2() Date: Fri, 20 Sep 2019 15:46:09 +0200 Message-ID: <20190920134609.GA2113@pc> (raw) In-Reply-To: <CAHk-=wiCqDiU7SE3FLn2W26MS_voUAuqj5XFa1V_tiGTrrW-zQ@mail.gmail.com> Hi, On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote: > On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish <darwish.07@gmail.com> wrote: > > > > Since Linux v3.17, getrandom(2) has been created as a new and more > > secure interface for pseudorandom data requests. It attempted to > > solve three problems, as compared to /dev/urandom: > > I don't think your patch is really _wrong_, but I think it's silly to > introduce a new system call, when we have 30 bits left in the flags of > the old one, and the old system call checked them. > > So it's much simpler and more straightforward to just introduce a > single new bit #2 that says "I actually know what I'm doing, and I'm > explicitly asking for secure/insecure random data". > > And then say that the existing bit #1 just means "I want to wait for entropy". > > So then you end up with this: > > /* > * Flags for getrandom(2) > * > * GRND_NONBLOCK Don't block and return EAGAIN instead > * GRND_WAIT_ENTROPY Explicitly wait for entropy > * GRND_EXPLICIT Make it clear you know what you are doing > */ > #define GRND_NONBLOCK 0x0001 > #define GRND_WAIT_ENTROPY 0x0002 > #define GRND_EXPLICIT 0x0004 > > #define GRND_SECURE (GRND_EXPLICIT | GRND_WAIT_ENTROPY) > #define GRND_INSECURE (GRND_EXPLICIT | GRND_NONBLOCK) > > /* Nobody wants /dev/random behavior, nobody should use it */ > #define GRND_RANDOM 0x0002 > > which is actually fairly easy to understand. So now we have three > bits, and the values are: > > 000 - ambiguous "secure or just lazy/ignorant" > 001 - -EAGAIN or secure > 010 - blocking /dev/random DO NOT USE > 011 - nonblocking /dev/random DO NOT USE > 100 - nonsense, returns -EINVAL > 101 - /dev/urandom without warnings > 110 - blocking secure > 111 - -EAGAIN or secure > Hmmm, the point of the new syscall was **exactly** to avoid the 2^3 combinations above, and to provide developers only two, sane and easy, options: - GRND2_INSECURE - GRND2_SECURE_UNBOUNDED_INITIAL_WAIT You *must* pick one of these, and that's it. (!) Then the proposed getrandom_wait(7) manpage, also mentioned in the V4 patch WARN message, would provide a big rationale, and encourage everyone to use the new getrandom2(2) syscall instead. But yeah, maybe we should add the extra flags to the old getrandom() instead, and let glibc implement a getrandom_safe(3) wrapper only with the sane options available. Problem is, glibc is still *really* slow in adopting linux syscall wrappers, so I'm not optimistic about that... I still see the new system call as the sanest path, even provided the cost of a new syscall number.. @Linus, @Ted: Final thoughts? > and people would be encouraged to use one of these three: > > - GRND_INSECURE > - GRND_SECURE > - GRND_SECURE | GRND_NONBLOCK > > all of which actually make sense, and none of which have any > ambiguity. And while "GRND_INSECURE | GRND_NONBLOCK" works, it's > exactly the same as just plain GRND_INSECURE - the point is that it > doesn't block for entropy anyway, so non-blocking makes no different. > [...] > > There is *one* other small semantic change: The old code did > urandom_read() which added warnings, but each warning also _reset_ the > crng_init_cnt. Until it decided not to warn any more, at which point > it also stops that resetting of crng_init_cnt. > > And that reset of crng_init_cnt, btw, is some cray cray. > > It's basically a "we used up entropy" thing, which is very > questionable to begin with as the whole discussion has shown, but > since it stops doing it after 10 cases, it's not even good security > assuming the "use up entropy" case makes sense in the first place. > > So I didn't copy that insanity either. And I'm wondering if removing > it from /dev/urandom might also end up helping Ahmed's case of getting > entropy earlier, when we don't reset the counter. > Yeah, noticed that, but I've learned not to change crypto or speculative-execution code even if the changes "just look the same" at first glance ;-) (out of curiosity, I'll do a quick test with this CRNG entropy reset part removed. Maybe it was indeed part of the problem..) > But other than those two details, none of the existing semantics > changed, we just added the three actually _sane_ cases without any > ambiguity. > > In particular, this still leaves the semantics of that nasty > "getrandom(0)" as the same "blocking urandom" that it currently is. > But now it's a separate case, and we can make that perhaps do the > timeout, or at least the warning. > Yeah, I would propose to keep the V4-submitted "timeout then WARN" logic. This alone will give user-space / distributions time to adapt. For example, it was interesting that even the 0day bot had limited entropy on boot (virtio-rng / TRUST_CPU not enabled): https://lkml.kernel.org/r/20190920005120.GP15734@shao2-debian If user-space didn't get its act together, then the other extreme measures can be implemented later (the getrandom() length test, using jitter as a credited kernel entropy source, etc., etc.) > And the new cases are defined to *not* warn. In particular, > GRND_INSECURE very much does *not* warn about early urandom access > when crng isn't ready. Because the whole point of that new mode is > that the user knows it isn't secure. > > So that should make getrandom(GRND_INSECURE) palatable to the systemd > kind of use that wanted to avoid the pointless kernel warning. > Yup, that's what was in the submitted V4 patch too. The caller explicitly asked for "insecure", so they know what they're doing. getrandom2(2) never prints any kernel message. > And we could mark this for stable and try to get it backported so that > it will have better coverage, and encourage people to use the new sane > _explicit_ waiting (or not) for entropy. > ACK. I'll wait for an answer to the "Final thoughts?" question above, send a V5 with CC:stable, then disappear from this thread ;-) Thanks a lot everyone! -- Ahmed Darwish
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 ` Linux 5.3-rc8 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 [this message] 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 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=20190920134609.GA2113@pc \ --to=darwish.07@gmail.com \ --cc=ebiederm@xmission.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=mjg59@srcf.ucam.org \ --cc=mtk.manpages@gmail.com \ --cc=mzxreary@0pointer.de \ --cc=patrakov@gmail.com \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ --cc=w@1wt.eu \ /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