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
From 2836990aff5bc1dab6a4e927304247dae469c774 Mon Sep 17 00:00:00 2001
From: "Alexander E. Patrakov" <patrakov@xxxxxxxxx>
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@xxxxxxxxx>
---
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@xxxxxxxxx>
+ *
+ * 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@xxxxxxxxx>");
+MODULE_DESCRIPTION("Exposes clock jitter as a hwrng");
+MODULE_SOFTDEP("pre: jitterentropy_rng");
--
2.23.0
Attachment:
smime.p7s
Description: Криптографическая подпись S/MIME
