From: Andy Lutomirski <luto@amacapital.net>
To: Willy Tarreau <w@1wt.eu>
Cc: Andy Lutomirski <luto@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Ahmed S. Darwish" <darwish.07@gmail.com>,
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>,
Matthew Garrett <mjg59@srcf.ucam.org>,
lkml <linux-kernel@vger.kernel.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-man <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 12:52:28 -0700 [thread overview]
Message-ID: <C5BE6F0F-15B1-404B-A490-5B4E5C8C61A0@amacapital.net> (raw)
In-Reply-To: <20190920193740.GD1889@1wt.eu>
> On Sep 20, 2019, at 12:37 PM, Willy Tarreau <w@1wt.eu> wrote:
>
> On Fri, Sep 20, 2019 at 12:22:17PM -0700, Andy Lutomirski wrote:
>> Perhaps userland could register a helper that takes over and does
>> something better?
>
> If userland sees the failure it can do whatever the developer/distro
> packager thought suitable for the system facing this condition.
>
>> But I think the kernel really should do something
>> vaguely reasonable all by itself.
>
> Definitely, that's what Linus' proposal was doing. Sleeping for some time
> is what I call "vaguely reasonable".
I don’t buy it. We have existing programs that can deadlock on boot. Just throwing -EAGAIN at them in a syscall that didn’t previously block does not strike me as reasonable.
>
>> If nothing else, we want the ext4
>> patch that provoked this whole discussion to be applied,
>
> Oh absolutely!
>
>> which means
>> that we need to unbreak userspace somehow, and returning garbage it to
>> is not a good choice.
>
> It depends how it's used. I'd claim that we certainly use randoms for
> other things (such as ASLR/hashtables) *before* using them to generate
> long lived keys thus we can have a bit more time to get some more
> entropy before reaching the point of producing these keys.
The problem is that we don’t know what userspace is doing with the output from getrandom(..., 0), so I think we have to be conservative. New kernels need to work with old user code. It’s okay if they’re slower to boot than they could be.
>
>> Here are some possible approaches that come to mind:
>>
>> int count;
>> while (crng isn't inited) {
>> msleep(1);
>> }
>>
>> and modify add_timer_randomness() to at least credit a tiny bit to
>> crng_init_cnt.
>
> Without a timeout it's sure we'll still face some situations where
> it blocks forever, which is the current problem.
The point is that we keep the timer running by looping like this, which should cause add_timer_randomness() to get called continuously, which should prevent the deadlock. I assume the deadlock is because we go into nohz-idle and we sit there with nothing happening at all.
>
>> Or we do something like intentionally triggering readahead on some
>> offset on the root block device.
>
> You don't necessarily have such a device, especially when you're
> in an initramfs. It's precisely where userland can be smarter. When
> the caller is sfdisk for example, it does have more chances to try
> to perform I/O than when it's a tiny http server starting to present
> a configuration page.
What I mean is: allow user code to register a usermode helper that helps get entropy. Or just convince distros to bundle some useful daemon that starts at early boot and lives in the initramfs.
next prev parent reply other threads:[~2019-09-20 19:52 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
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 [this message]
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=C5BE6F0F-15B1-404B-A490-5B4E5C8C61A0@amacapital.net \
--to=luto@amacapital.net \
--cc=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=luto@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).