[PATCH v10 2/3] arm64: random: Add data to pool from setup_arch()

Mark Brown broonie at kernel.org
Wed Jan 15 09:04:59 PST 2020

On Wed, Jan 15, 2020 at 02:36:32PM +0100, Ard Biesheuvel wrote:
> On Wed, 15 Jan 2020 at 13:42, Will Deacon <will at kernel.org> wrote:

> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20200115/ce181e03/attachment.sig>

More information about the linux-arm-kernel mailing list