[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHW4gPdWXc93eAYpHNU3H+Whg-n2mcEKX=Zro0nANhgSg@mail.gmail.com>
Date: Wed, 20 Jan 2021 14:15:59 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Andre Przywara <andre.przywara@....com>,
Android Kernel Team <kernel-team@...roid.com>,
"Theodore Ts'o" <tytso@....edu>, Mark Brown <broonie@...nel.org>,
Sudeep Holla <sudeep.holla@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
kvmarm <kvmarm@...ts.cs.columbia.edu>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v6 0/5] ARM: arm64: Add SMCCC TRNG entropy service
On Wed, 20 Jan 2021 at 14:01, Will Deacon <will@...nel.org> wrote:
>
> On Wed, 6 Jan 2021 10:34:48 +0000, Andre Przywara wrote:
> > a fix to v5, now *really* fixing the wrong priority of SMCCC vs. RNDR
> > in arch_get_random_seed_long_early(). Apologies for messing this up
> > in v5 and thanks to broonie for being on the watch!
> >
> > Will, Catalin: it would be much appreciated if you could consider taking
> > patch 1/5. This contains the common definitions, and is a prerequisite
> > for every other patch, although they are somewhat independent and likely
> > will need to go through different subsystems.
> >
> > [...]
>
> Applied the first patch only to arm64 (for-next/rng), thanks!
>
> [1/5] firmware: smccc: Add SMCCC TRNG function call IDs
> https://git.kernel.org/arm64/c/67c6bb56b649
>
> What's the plan for the rest of the series, and I think the related
> change over at [1]?
>
Given that Ted seems to have lost interest in /dev/random patches, I
was hoping [1] could be taken via the arm64 tree instead. Without this
patch, I don't think we should expose the SMCCC RNG interface via
arch_get_random_seed(), given how insanely often it will be called in
that case.
Note that the KVM patch implements the opposite end of this interface,
and is not affected by [1] at all, so that can be taken at any time.
Powered by blists - more mailing lists