On 1/9/20 6:41 AM, Mark Brown wrote:

+/*
+ * Our ARCH_RANDOM implementation does not function until relatively
+ * late in the boot when cpufeature has detertmined system
+ * capabilities so the core code can't use arch_get_random*() to
+ * initialize, instead we call this function to inject data from
+ * setup_arch() if the boot CPU supports v8.5-RNG.
+ */
+static inline void __init arm64_add_early_rndr_entropy(void)
+{
+	unsigned long val;
+	int i;
+
+	if (!__early_cpu_has_rndr())
+		return;
+
+	/* Add multiple values to mirror the generic code. */
+	for (i = 0; i < 16; i++)
+		if (__arm64_rndr(&val))
+			add_device_randomness(&val, sizeof(val));
+}

This is not nearly the same thing as what crng_initialize does.  In particular,
it's not going to advance crng_init at all.

You could use add_hwgenerator_randomness, but you have no way to honor the
random.trust_cpu command-line parameter that way.

The only thing I can imagine that would satisfy MarkR's constraints is to have
a new archrandom.h interface, arch_get_random_boot_long().


r~

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel