On Wed, Jan 15, 2020 at 10:11:08AM +0000, Mark Rutland wrote:
> On Wed, Jan 15, 2020 at 10:22:03AM +0100, Ard Biesheuvel wrote:

> > In a previous iteration, we did have a functional
> > arch_get_random_seed_long() early on, which would solve this issue
> > without even needing a patch like this.

> It meant that the common runtime path had code that was only ever meant
> to run at boot time, and would also run on secondary CPUs until we
> finalized the caps, so they'd behave inconsistently across boot and
> hotplug paths. I was concerned that this was messy and would be painful
> to reason about and debug.

> My suggestion was that we either:

> (a) Had the arch code explicitly inject the entropy in the primary setup
>     path, as these patches do, or;

These patches don't quite do that, they inject data but not
entropy so anything that is waiting for the pool to become fully
initialized will still end up waiting, though we do still get the
data mixed in.  There is currently no interface which allows one
to explicitly inject entropy as though from the architecture and
I'm not convinced that having one would be a good idea.

> (b) Had a new callback (e.g. __early_arch_get_random_seed_long()) that
>     the core random code only called during its initialization, separate
>     to the runtime paths.

This is definitely an option, but it is a bit ugly and as things
stand with random.c it would I think have to cope with possibly
running with multiple processors at which point we start to get
back to the complexity you were originally worried about just in
a code path that's less commonly executed.