On Wed, Jan 15, 2020 at 02:36:32PM +0100, Ard Biesheuvel wrote:

On Wed, 15 Jan 2020 at 13:42, Will Deacon [off-list ref] wrote:

quoted

I'd also really like Ard's ack on anything relating to RNGs.

Patches #1 and #3 are fine with me, modulo the HWCAP bit which I don't
deeply care about.

But the way this patch works around our workaround for mismatched RNG
caps between cores doesn't make sense to me.

I'd be totally happy to drop patch 2 entirely, it's a *bit*
marginal if it's useful - I mainly wrote it because it's so
trivial to do not because I think it's a wonderful idea.

arch_get_random_seed_long() should just have some out of line __init
path that gets invoked only during early boot, exactly how we are
using it in patch #3 to seed KASLR, where we don't care about whether

Yes, I think that would be a good place to get to if we can - if
the early init thing is a separate call then we have to worry
about the callers always running from the right context which
sounds like trouble.  It's just trying to figure out a way to
write things which is clearly robust when looking at the arch
code by itself, and I don't want to completely discount the
possibility of a new interface from the random code to help with
that yet.

or not other CPUs have the extension. (Note that rand_initialize() is
called very early, way before the point where we have to care about
being scheduled from a CPU with RNG to one without)

Everything is simple during rand_initialize(), though the actual
calls to get entropy that it does happen in crng_initialize()
which is also used to initialize the per-node pools for NUMA
systems but that should happen after the capabilities code has
run I think (pretty sure, but I need to check) so we can rely on
cpus_have_const_cap().  There's also calls in prandom_init()
which runs at core_initcall() so that should be fine too.