linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-kernel@vger.kernel.org,
	Andre Przywara <andre.przywara@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	kvmarm@lists.cs.columbia.edu,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source
Date: Thu, 5 Nov 2020 14:29:49 +0000	[thread overview]
Message-ID: <20201105142949.GB4856@sirena.org.uk> (raw)
In-Reply-To: <20201105140322.GH82102@C02TD0UTHF1T.local>


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

On Thu, Nov 05, 2020 at 02:03:22PM +0000, Mark Rutland wrote:
> On Thu, Nov 05, 2020 at 01:41:42PM +0000, Mark Brown wrote:

> > It isn't obvious to me why we don't fall through to trying the SMCCC
> > TRNG here if for some reason the v8.5-RNG didn't give us something.
> > Definitely an obscure possibility but still...

> I think it's better to assume that if we have a HW RNG and it's not
> giving us entropy, it's not worthwhile trapping to the host, which might
> encounter the exact same issue.

There's definitely a good argument for that, but OTOH it's possible the
SMCCC implementation is doing something else (it'd be an interesting
implementation decision but...).  That said I don't really mind, I think
my comment was more that if we're doing this the code should be explicit
about what the intent is since right now it isn't obvious.  Either a
comment or having an explicit "what method are we choosing" thing.

> That said, I'm not sure it's great to plumb this under the
> arch_get_random*() interfaces, e.g. given this measn that
> add_interrupt_randomness() will end up trapping to the host all the time
> when it calls arch_get_random_seed_long().

> Is there an existing interface for "slow" runtime entropy that we can
> plumb this into instead?

Yeah, I was wondering about this myself - it seems like a better fit for
hwrng rather than the arch interfaces but that's not used until
userspace comes up, the arch stuff is all expected to be quick.  I
suppose we could implement the SMCCC stuff for the early variants of the
API you added so it gets used for bootstrapping purposes and then we
rely on userspace keeping things topped up by fetching entropy through
hwrng or otherwise but that feels confused so I have a hard time getting
enthusiastic about it.

[-- 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

  parent reply	other threads:[~2020-11-05 14:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 12:56 [PATCH v2 0/5] ARM: arm64: Add SMCCC TRNG entropy service Andre Przywara
2020-11-05 12:56 ` [PATCH v2 1/5] firmware: smccc: Add SMCCC TRNG function call IDs Andre Przywara
2020-11-05 12:56 ` [PATCH v2 2/5] firmware: smccc: Introduce SMCCC TRNG framework Andre Przywara
2020-11-05 12:56 ` [PATCH v2 3/5] ARM: implement support for SMCCC TRNG entropy source Andre Przywara
2020-11-05 17:15   ` kernel test robot
2020-11-05 17:56     ` André Przywara
2020-11-05 17:15   ` kernel test robot
2020-11-06 15:29   ` Marc Zyngier
2020-11-06 15:30     ` Ard Biesheuvel
2020-11-06 15:35       ` Marc Zyngier
2020-11-05 12:56 ` [PATCH v2 4/5] arm64: Add " Andre Przywara
2020-11-05 13:41   ` Mark Brown
2020-11-05 14:03     ` Mark Rutland
2020-11-05 14:04       ` Ard Biesheuvel
2020-11-05 14:30         ` Mark Rutland
2020-11-05 14:34           ` Ard Biesheuvel
2020-11-05 14:45             ` Mark Rutland
2020-11-05 14:48             ` Marc Zyngier
2020-11-05 14:29       ` Mark Brown [this message]
2020-11-05 14:38         ` Mark Rutland
2020-11-12 16:03           ` André Przywara
2020-11-05 14:30       ` André Przywara
2020-11-05 12:56 ` [PATCH v2 5/5] KVM: arm64: implement the TRNG hypervisor call Andre Przywara
2020-11-05 14:13   ` Marc Zyngier
2020-11-05 16:19     ` Ard Biesheuvel

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=20201105142949.GB4856@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=sudeep.holla@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).