All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v10 2/3] arm64: random: Add data to pool from setup_arch()
Date: Wed, 15 Jan 2020 14:01:33 +0000	[thread overview]
Message-ID: <20200115140133.GI3897@sirena.org.uk> (raw)
In-Reply-To: <20200115101107.GA32549@lakrids.cambridge.arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1622 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

  reply	other threads:[~2020-01-15 14:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 12:23 [PATCH v10 0/3] ARMv8.5-RNG support Mark Brown
2020-01-10 12:23 ` [PATCH v10 1/3] arm64: Implement archrandom.h for ARMv8.5-RNG Mark Brown
2020-01-14 17:44   ` Will Deacon
2020-01-15  7:40     ` Ard Biesheuvel
2020-01-15  9:16       ` Will Deacon
2020-01-15  9:24         ` Ard Biesheuvel
2020-01-15 11:07           ` Mark Brown
2020-01-15 11:16             ` Will Deacon
2020-01-15 14:26             ` Catalin Marinas
2020-01-16  0:23               ` Richard Henderson
2020-01-16 11:02                 ` Catalin Marinas
2020-01-16 11:10                   ` Ard Biesheuvel
2020-01-16 11:40                     ` Catalin Marinas
2020-01-10 12:23 ` [PATCH v10 2/3] arm64: random: Add data to pool from setup_arch() Mark Brown
2020-01-10 12:35   ` Mark Rutland
2020-01-13 19:09   ` Richard Henderson
2020-01-15  7:48   ` Ard Biesheuvel
2020-01-15  9:16     ` Will Deacon
2020-01-15  9:22       ` Ard Biesheuvel
2020-01-15 10:11         ` Mark Rutland
2020-01-15 14:01           ` Mark Brown [this message]
2020-01-15 12:07       ` Mark Brown
2020-01-15 12:42         ` Will Deacon
2020-01-15 13:36           ` Ard Biesheuvel
2020-01-15 17:04             ` Mark Brown
2020-01-16 11:33               ` Will Deacon
2020-01-15 15:40           ` Mark Brown
2020-01-10 12:23 ` [PATCH v10 3/3] arm64: Use v8.5-RNG entropy for KASLR seed Mark Brown
2020-01-10 12:35   ` Mark Rutland
2020-01-13 19:09   ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200115140133.GI3897@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=richard.henderson@linaro.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.