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 [thread overview]
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 other threads:[~2019-09-20 13:46 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHk-=whW_AB0pZ0u6P9uVSWpqeb5t2NCX_sMpZNGy8shPDyDNg@mail.gmail.com>
[not found] ` <CAHk-=wi_yXK5KSmRhgNRSmJSD55x+2-pRdZZPOT8Fm1B8w6jUw@mail.gmail.com>
[not found] ` <20190911173624.GI2740@mit.edu>
[not found] ` <20190912034421.GA2085@darwi-home-pc>
[not found] ` <20190912082530.GA27365@mit.edu>
[not found] ` <CAHk-=wjyH910+JRBdZf_Y9G54c1M=LBF8NKXB6vJcm9XjLnRfg@mail.gmail.com>
[not found] ` <20190914122500.GA1425@darwi-home-pc>
[not found] ` <008f17bc-102b-e762-a17c-e2766d48f515@gmail.com>
[not found] ` <20190915052242.GG19710@mit.edu>
[not found] ` <CAHk-=wgg2T=3KxrO-BY3nHJgMEyApjnO3cwbQb_0vxsn9qKN8Q@mail.gmail.com>
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
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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).