From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: "Ahmed S. Darwish" <darwish.07@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
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] random: getrandom(2): don't block on non-initialized entropy pool
Date: Sat, 14 Sep 2019 19:08:13 +0500 [thread overview]
Message-ID: <008f17bc-102b-e762-a17c-e2766d48f515@gmail.com> (raw)
In-Reply-To: <20190914122500.GA1425@darwi-home-pc>
(resending without HTML this time, sorry for the duplicate)
14.09.2019 17:25, Ahmed S. Darwish пишет:
> getrandom() has been created as a new and more secure interface for
> pseudorandom data requests. Unlike /dev/urandom, it unconditionally
> blocks until the entropy pool has been properly initialized.
>
> While getrandom() has no guaranteed upper bound for its waiting time,
> user-space has been abusing it by issuing the syscall, from shared
> libraries no less, during the main system boot sequence.
>
> Thus, on certain setups where there is no hwrng (embedded), or the
> hwrng is not trusted by some users (intel RDRAND), or sometimes it's
> just broken (amd RDRAND), the system boot can be *reliably* blocked.
>
> The issue is further exaggerated by recent file-system optimizations,
> e.g. b03755ad6f33 (ext4: make __ext4_get_inode_loc plug), which
> merges directory lookup code inode table IO, and thus minimizes the
> number of disk interrupts and entropy during boot. After that commit,
> a blocked boot can be reliably reproduced on a Thinkpad E480 laptop
> with standard ArchLinux user-space.
>
> Thus, don't trust user-space on calling getrandom() from the right
> context. Just never block, and return -EINVAL if entropy is not yet
> available.
>
> Link: https://lkml.kernel.org/r/CAHk-=wjyH910+JRBdZf_Y9G54c1M=LBF8NKXB6vJcm9XjLnRfg@mail.gmail.com
> Link: https://lkml.kernel.org/r/20190912034421.GA2085@darwi-home-pc
> Link: https://lkml.kernel.org/r/20190911173624.GI2740@mit.edu
> Link: https://lkml.kernel.org/r/20180514003034.GI14763@thunk.org
Let me reword the commit message for a hopefully better historical
perspective.
===
getrandom() has been created as a new and more secure interface for
pseudorandom data requests. It attempted to solve two problems, as
compared to /dev/{u,}random: the need to open a file descriptor (which
can fail) and possibility to get not-so-random data from the
incompletely initialized entropy pool. It has succeeded in the first
improvement, but failed horribly in the second one: it blocks until the
entropy pool has been properly initialized, if called without
GRND_NONBLOCK, while none of these behaviors are suitable for the early
boot stage.
The issue is further exaggerated by recent file-system optimizations,
e.g. b03755ad6f33 (ext4: make __ext4_get_inode_loc plug), which merges
directory lookup code inode table IO, and thus minimizes the number of
disk interrupts and entropy during boot. After that commit, a blocked
boot can be reliably reproduced on a Thinkpad E480 laptop with standard
ArchLinux user-space.
Thus, on certain setups where there is no hwrng (embedded systems or
non-KVM virtual machines), or the hwrng is not trusted by some users
(intel RDRAND), or sometimes it's just broken (amd RDRAND), the system
boot can be *reliably* blocked. It can be therefore argued that there is
no way to use getrandom() on Linux correctly, especially from shared
libraries: GRND_NONBLOCK has to be used, and a fallback to some other
interface like /dev/urandom is required, thus making the net result no
better than just using /dev/urandom unconditionally.
While getrandom() has no guaranteed upper bound for its waiting time,
user-space has been using it incorrectly by issuing the syscall, from
shared libraries no less, during the main system boot sequence, without
GRND_NONBLOCK.
We can't trust user-space on calling getrandom() from the right context.
Therefore, just never block, and return -EINVAL (with some entropy still
in the buffer) if the requested amount of entropy is not yet available.
Link:
https://github.com/openbsd/src/commit/edb2eeb7da8494998d0073f8aaeb8478cee5e00b
Link:
https://lkml.kernel.org/r/CAHk-=wjyH910+JRBdZf_Y9G54c1M=LBF8NKXB6vJcm9XjLnRfg@mail.gmail.com
Link: https://lkml.kernel.org/r/20190912034421.GA2085@darwi-home-pc
Link: https://lkml.kernel.org/r/20190911173624.GI2740@mit.edu
Link: https://lkml.kernel.org/r/20180514003034.GI14763@thunk.org
===
That said, I have an issue with the -EINVAL return code here: it is also
returned in cases where the parameters passed are genuinely not
understood by the kernel, and no entropy has been written to the buffer.
Therefore, the caller has to assume that the call has failed, waste all
the bytes in the buffer, and try some fallback strategy. Can we think of
some other error code?
The other part of me thinks that triggering a fallback, by returning an
error code, is never the right thing to do. If the "uninitialized" state
exists at all, applications and libraries have to care (and I would
expect their authors who don't pass GRND_RANDOM to just fall back to
/dev/urandom). Therefore, we are back to square one, except that the
fallback code in the application is something that is only rarely
exercised, and thus has higher chances to accumulate bugs. Because the
only expected/reasonable fallback is to read from /dev/urandom, the
whole result looks like shifting the responsibility/blame without
achieving anything useful. As the issue is not really solvable, just
give the application not-so-random data, as /dev/urandom does, without
any indication - this would at least keep the benefit of not needing a
file descriptor. It is simply not possible to do anything better without
eliminating the userspace-visible "uninitialized" crng state, e.g. with
the help of entropy input from the boot loader or a configurable config
or command line option to trust the jitter entropy in-kernel.
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> ---
>
> Notes:
> This feels very risky at the very end of -rc8, so only sending
> this as an RFC. The system of course reliably boots with this,
> and the log, as expected, powerfully warns all callers:
>
> $ dmesg | grep random
> [0.236472] random: get_random_bytes called from start_kernel+0x30f/0x4d7 with crng_init=0
> [0.680263] random: fast init done
> [2.500346] random: lvm: uninitialized urandom read (4 bytes read)
> [2.595125] random: systemd-random-: invalid getrandom request (512 bytes): crng not ready
> [2.595126] random: systemd-random-: uninitialized urandom read (512 bytes read)
> [3.427699] random: dbus-daemon: uninitialized urandom read (12 bytes read)
> [3.979425] urandom_read: 1 callbacks suppressed
> [3.979426] random: polkitd: uninitialized urandom read (8 bytes read)
> [3.979726] random: polkitd: uninitialized urandom read (8 bytes read)
> [3.979752] random: polkitd: uninitialized urandom read (8 bytes read)
> [4.473398] random: gnome-session-b: invalid getrandom request (16 bytes): crng not ready
> [4.473404] random: gnome-session-b: invalid getrandom request (16 bytes): crng not ready
> [4.473409] random: gnome-session-b: invalid getrandom request (16 bytes): crng not ready
> [5.265636] random: crng init done
> [5.265649] random: 3 urandom warning(s) missed due to ratelimiting
> [5.265652] random: 1 getrandom warning(s) missed due to ratelimiting
>
> drivers/char/random.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 4a50ee2c230d..309dc5ddf370 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -511,6 +511,8 @@ static struct ratelimit_state unseeded_warning =
> RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3);
> static struct ratelimit_state urandom_warning =
> RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
> +static struct ratelimit_state getrandom_warning =
> + RATELIMIT_STATE_INIT("warn_getrandom_notavail", HZ, 3);
>
> static int ratelimit_disable __read_mostly;
>
> @@ -1053,6 +1055,12 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
> urandom_warning.missed);
> urandom_warning.missed = 0;
> }
> + if (getrandom_warning.missed) {
> + pr_notice("random: %d getrandom warning(s) missed "
> + "due to ratelimiting\n",
> + getrandom_warning.missed);
> + getrandom_warning.missed = 0;
> + }
> }
> }
>
> @@ -1915,6 +1923,7 @@ int __init rand_initialize(void)
> crng_global_init_time = jiffies;
> if (ratelimit_disable) {
> urandom_warning.interval = 0;
> + getrandom_warning.interval = 0;
> unseeded_warning.interval = 0;
> }
> return 0;
> @@ -2138,8 +2147,6 @@ const struct file_operations urandom_fops = {
> SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
> unsigned int, flags)
> {
> - int ret;
> -
> if (flags & ~(GRND_NONBLOCK|GRND_RANDOM))
> return -EINVAL;
>
> @@ -2152,9 +2159,13 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
> if (!crng_ready()) {
> if (flags & GRND_NONBLOCK)
> return -EAGAIN;
> - ret = wait_for_random_bytes();
> - if (unlikely(ret))
> - return ret;
> +
> + if (__ratelimit(&getrandom_warning))
> + pr_notice("random: %s: invalid getrandom request "
> + "(%zd bytes): crng not ready",
> + current->comm, count);
> +
> + return -EINVAL;
> }
> return urandom_read(NULL, buf, count, NULL);
> }
> --
> 2.23.0
>
--
Alexander E. Patrakov
next prev parent reply other threads:[~2019-09-14 14:08 UTC|newest]
Thread overview: 214+ 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 [this message]
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-20 0:51 ` [random] ec47a799bf: WARNING:at_drivers/char/random.c:#getrandom_wait kernel test robot
2019-09-20 0:51 ` 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=008f17bc-102b-e762-a17c-e2766d48f515@gmail.com \
--to=patrakov@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=darwish.07@gmail.com \
--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=rstrode@redhat.com \
--cc=torvalds@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.