[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6adb02d4-c486-a945-7f51-d007d6de45b2@gmail.com>
Date: Fri, 20 Sep 2019 01:45:40 +0500
From: "Alexander E. Patrakov" <patrakov@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
"Theodore Y. Ts'o" <tytso@....edu>
Cc: "Ahmed S. Darwish" <darwish.07@...il.com>,
Lennart Poettering <mzxreary@...inter.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
lkml <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org,
linux-man@...r.kernel.org
Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and
introduce getrandom2()
20.09.2019 01:04, Linus Torvalds пишет:
> instead. Yeah, it still doesn't help on machines that don't even have
> a cycle counter, but it at least means that you don't have to have a
> CPU rdrand (or equivalent) but you do have a cycle counter, now the
> extraction of randomness from the pool doesn't just do the
> (predictable) mutation for the backtracking, but actually means that
> you have some very hard to predict timing effects.
>
> Again, in this case a cycle counter really does add a small amount of
> entropy (everybody agrees that modern CPU's are simply too complex to
> be predictable at a cycle level), but that's not really the point. The
> point is that now doing the extraction really fundamentally changes
> the state in unpredictable ways, so that you don't have that "if I
> recognize a value, I know what the next value will be" kind of attack.
This already resembles in-kernel haveged (except that it doesn't credit
entropy), and Willy Tarreau said "collect the small entropy where it is,
period" today. So, too many people touched upon the topic in one day,
and therefore I'll bite.
We already have user-space software (haveged and modern versions of
rngd) that extract supposed entropy from clock jitter and feed it back
to the kernel via /dev/random (crediting it). Indeed, at present, on
some hardware this is the only way for distributions and users to
collect enough entropy during boot and avoid stalls - all other
suggestions are simply non-constructive. Also, Google's Fuchsia OS does
use and credit jitter entropy.
For the record: I do not have a justifiable opinion whether haveged/rngd
output (known as jitter entropy) actually contains any entropy. I
understand that there are two possible viewpoints here. The rest of the
email is written under the assumption that haveged does provide real
entropy and not fake one.
The problem that I have with the current situation is that distributions
and users, when they set up their systems to run haveged or rngd, often
do it incorrectly (even, as mentioned, under the assumption that haveged
is something valid and useful). The most common mistake is relying on
systemd-provided default dependencies, thus not starting such software
as early as possible. Even worse, no initramfs generator allows one to
easily include haveged/rngd in the initramfs and run it there. And for
me, the first urandom warning comes from the initramfs, so anything
started from the main system is, arguably, already too late.
Therefore, I think, an in-kernel hwrng that exposes jitter entropy is
something useful (for those who agree that jitter entropy is not fake),
because it avoids the pitfall-ridden userspace setup. Just as an
exercise, I have implemented a very simple driver (attached as a patch)
that does just that. I am only half-serious here, the driver is only
lightly tested in KVM without any devices except an unconnected virtio
network card, not on any real hardware. Someone else can also find it
useful as a test/fake hwrng driver.
I am aware that there was an earlier decision that jitter entropy should
not be credited, i.e. effectively a pre-existing NAK from Theodore Ts'o.
But, well, distributions are already overriding this decision in
userspace, and do it badly, so in my viewpoint, the driver would be a
net win if some mechanism is added that makes it a no-op by default even
if the driver is built-in. E.g. an explicit "enable" parameter, but I am
open to other suggestions, too.
--
Alexander E. Patrakov
View attachment "0001-hw_random-Add-jitterentropy_hwrng.patch" of type "text/x-patch" (4368 bytes)
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4052 bytes)
Powered by blists - more mailing lists