[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9qvdKy6zCHQEUp1zp-dL0Sco1Ujtn7jXK=EFde_yDx8wA@mail.gmail.com>
Date: Mon, 27 May 2019 17:43:03 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: "Theodore Ts'o" <tytso@....edu>,
Naveen Nathan <naveen@...tninja.net>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Kevin Easton <kevin@...rana.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: urandom reads block when CRNG is not initialized.
On Mon, May 27, 2019 at 4:07 PM Theodore Ts'o <tytso@....edu> wrote:
>
> This is guaranteed to cause the system to fail for systems using
> systemd. (Unless you are running an x86 with random.trust_cpu=1 ---
> in which case, this patch/config is pointless.) And many embedded
> systems *do* use systemd. I know lots of people like to wish that
> systemd doesn't exist, but we need to face reality.
>
> *Seriously,* if this is something the system builder should be using,
> they should be fixing userspace. And if they care enough that they
> would want to enable this patch, they could just scan dmesg looking
> for the warnings from the kernel.
Really, it's a chicken & egg thing. If people who make userspaces
never have an option to design around the correct behavior, they'll
continue to rely on the broken behavior. But if we give them a way to
compile their kernels with the correct behavior, eventually some
userspaces will run fine with it. "But they should just use
getrandom()!" you shout. Yes, and maybe the code most userspace
builders provide does do this. But people like to plug-in plenty of
third party things into their userspaces, and I think there's some
value in a userspace being able to say, "we've dealt with the
/dev/urandom situation, and we now do the right thing, so we can
enable this option, and now the code you run on our userspace will
give good randomness."
More concretely, distros might ship an init system that allows
enabling this option without creating issues. Systemd might improve.
OpenRC and runit-based distros appear to exist. Some folks do very
custom stuff. If they manage to make it work with the correct urandom
behavior, then that's a good situation for everything else to build
on, and for providing better guarantees for third party software that
runs on that distro. But none of this is possible without the ability
to compile the kernel with the correct behavior.
Powered by blists - more mailing lists