Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()

["Alexander E. Patrakov" <patrakov@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3608 bytes --]

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

[-- Attachment #1.2: 0001-hw_random-Add-jitterentropy_hwrng.patch --]
[-- Type: text/x-patch, Size: 4507 bytes --]

From 2836990aff5bc1dab6a4e927304247dae469c774 Mon Sep 17 00:00:00 2001
From: "Alexander E. Patrakov" <patrakov@gmail.com>
Date: Thu, 19 Sep 2019 01:18:39 +0500
Subject: [PATCH] hw_random: Add jitterentropy_hwrng

This re-exports the existing "jitterentropy_rng" cryptoapi RNG as a
hwrng. The use case is to replace haveged, which distributions
often misconfigure by running it too late, while it is really needed
even in the initramfs on some systems.

Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
---
 drivers/char/hw_random/Kconfig               | 20 ++++++
 drivers/char/hw_random/Makefile              |  1 +
 drivers/char/hw_random/jitterentropy-hwrng.c | 70 ++++++++++++++++++++
 3 files changed, 91 insertions(+)
 create mode 100644 drivers/char/hw_random/jitterentropy-hwrng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 59f25286befe..ff2102c0159c 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -35,6 +35,26 @@ config HW_RANDOM_TIMERIOMEM
 
 	  If unsure, say Y.
 
+config HW_RANDOM_JITTERENTROPY
+        tristate "Jitter Entropy HW Random Number Generator support"
+        select CRYPTO_JITTERENTROPY
+        ---help---
+          This driver provides kernel-side support for extracting entropy
+          from CPU and memory clock jitter.
+
+          jitterentropy-hwrng serves the same purpose as haveged, but is in
+          the kernel. So, if you otherwise would have to run haveged, build
+          this driver instead, it has an advantage of being available very
+          early in the boot process.
+
+          Note that it is still not known whether clock jitter provides any
+          actual entropy.
+
+          To compile this driver as a module, choose M here: the
+          module will be called jitterentropy-hwrng.
+
+          If unsure, say N.
+
 config HW_RANDOM_INTEL
 	tristate "Intel HW Random Number Generator support"
 	depends on (X86 || IA64) && PCI
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 7c9ef4a7667f..9c6d1d3626f6 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_HW_RANDOM) += rng-core.o
 rng-core-y := core.o
 obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
+obj-$(CONFIG_HW_RANDOM_JITTERENTROPY) += jitterentropy-hwrng.o
 obj-$(CONFIG_HW_RANDOM_INTEL) += intel-rng.o
 obj-$(CONFIG_HW_RANDOM_AMD) += amd-rng.o
 obj-$(CONFIG_HW_RANDOM_ATMEL) += atmel-rng.o
diff --git a/drivers/char/hw_random/jitterentropy-hwrng.c b/drivers/char/hw_random/jitterentropy-hwrng.c
new file mode 100644
index 000000000000..b7aeefe4f47d
--- /dev/null
+++ b/drivers/char/hw_random/jitterentropy-hwrng.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 Alexander E. Patrakov <patrakov@gmail.com>
+ *
+ * Driver that exposes CPU clock jitter as a hardware random number generator
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/hw_random.h>
+#include <crypto/rng.h>
+
+static struct crypto_rng *drng;
+
+static int jitterentropy_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
+{
+	int err;
+
+	/* Prevent the hwrng_fill thread from impeding progress of everything else */
+	if (wait)
+		schedule();
+
+	err = crypto_rng_get_bytes(drng, data, max);
+	if (err)
+		return err;
+	return max;
+}
+
+static struct hwrng jitterentropy_rng = {
+	.name		= KBUILD_MODNAME,
+	.read		= jitterentropy_rng_read,
+	.quality	= 4, /* minimum that guarantees progress in hwrng_fill thread */
+};
+
+static int __init mod_init(void)
+{
+	int ret;
+
+	pr_info("Registering the driver\n");
+	drng = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+	if (!drng) {
+		pr_err("crypto_alloc_rng() failed\n");
+		return -ENODEV;
+	}
+
+	ret = hwrng_register(&jitterentropy_rng);
+	if (ret) {
+		crypto_free_rng(drng);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void __exit mod_exit(void)
+{
+	hwrng_unregister(&jitterentropy_rng);
+	crypto_free_rng(drng);
+}
+
+module_init(mod_init);
+module_exit(mod_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alexander E. Patrakov <patrakov@gmail.com>");
+MODULE_DESCRIPTION("Exposes clock jitter as a hwrng");
+MODULE_SOFTDEP("pre: jitterentropy_rng");
-- 
2.23.0


[-- Attachment #2: Криптографическая подпись S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4052 bytes --]