From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Alexander E. Patrakov" <patrakov@gmail.com>
Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>,
"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>,
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 12:19:23 -0700 [thread overview]
Message-ID: <CAHk-=whSbo=dBiqozLoa6TFmMgbeB8d9krXXvXBKtpRWkG0rMQ@mail.gmail.com> (raw)
In-Reply-To: <8c2a47cc-a519-ad94-5d9a-18bb03ba2fd7@gmail.com>
On Sat, Sep 14, 2019 at 10:09 AM Alexander E. Patrakov
<patrakov@gmail.com> wrote:
>
> > Which means that we're all kinds of screwed. The whole "we guarantee
> > entropy" model is broken.
>
> I agree here. Given that you suggested "to just fill the buffer and
> return 0" in the previous mail (well, I think you really meant "return
> buflen", otherwise ENOENTROPY == 0 and your previous objection applies),
Right.
The question remains when we should WARN_ON(), though.
For example, if somebody did save entropy between boots, we probably
should accept that - at least in the sense of not warning when they
then ask for randomness data back.
And if the hardware does have a functioning rdrand, we probably should
accept that too - simply because not accepting it and warning sounds a
bit too annoying.
But we definitely *should* have a warning for people who build
embedded devices that we can't see any reasonable amount of possible
entropy. Those have definitely happened, and it's a serious and real
security issue.
> let's do just that. As a bonus, it saves applications from the complex
> dance with retrying via /dev/urandom and finally brings a reliable API
> (modulo old and broken kernels) to get random numbers (well, as random
> as possible right now) without needing a file descriptor.
Yeah, well, the question in the end always is "what is reliable".
Waiting has definitely not been reliable, and has only ever caused problems.
Returning an error (or some status while still doing a best effort)
would be reasonable, but I really do think that people will mis-use
that. We just have too much of a history of people having the mindset
that they can just fall back to something better - like waiting - and
they are always wrong.
Just returning random data is the right thing, but we do need to make
sure that system developers see a warning if they do something
obviously wrong (so that the embedded people without even a real-time
clock to initialize any bits of entropy AT ALL won't think that they
can generate a system key on their router).
Linus
next prev parent reply other threads:[~2019-09-14 19:19 UTC|newest]
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
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 [this message]
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-=whSbo=dBiqozLoa6TFmMgbeB8d9krXXvXBKtpRWkG0rMQ@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
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).