[PATCH v10 1/3] arm64: Implement archrandom.h for ARMv8.5-RNG

Will Deacon will at kernel.org
Wed Jan 15 01:16:52 PST 2020


On Wed, Jan 15, 2020 at 08:40:46AM +0100, Ard Biesheuvel wrote:
> On Tue, 14 Jan 2020 at 18:44, Will Deacon <will at kernel.org> wrote:
> >
> > On Fri, Jan 10, 2020 at 12:23:39PM +0000, Mark Brown wrote:
> > > From: Richard Henderson <richard.henderson at linaro.org>
> > >
> > > Expose the ID_AA64ISAR0.RNDR field to userspace, as the RNG system
> > > registers are always available at EL0.
> > >
> > > Implement arch_get_random_seed_long using RNDR.  Given that the
> > > TRNG is likely to be a shared resource between cores, and VMs,
> > > do not explicitly force re-seeding with RNDRRS.  In order to avoid
> > > code complexity and potential issues with hetrogenous systems only
> > > provide values after cpufeature has finalized the system capabilities.
> > >
> > > Signed-off-by: Richard Henderson <richard.henderson at linaro.org>
> > > [Modified to only function after cpufeature has finalized the system
> > > capabilities and move all the code into the header -- broonie]
> > > Signed-off-by: Mark Brown <broonie at kernel.org>
> > > Reviewed-by: Mark Rutland <mark.rutland at arm.com>
> > > ---
> > >  Documentation/arm64/cpu-feature-registers.rst |  2 +
> > >  arch/arm64/Kconfig                            | 12 ++++
> > >  arch/arm64/include/asm/archrandom.h           | 67 +++++++++++++++++++
> > >  arch/arm64/include/asm/cpucaps.h              |  3 +-
> > >  arch/arm64/include/asm/sysreg.h               |  4 ++
> > >  arch/arm64/kernel/cpufeature.c                | 13 ++++
> > >  6 files changed, 100 insertions(+), 1 deletion(-)
> > >  create mode 100644 arch/arm64/include/asm/archrandom.h
> >
> > In which case, should we also add an HWCAP for this?
> >
> 
> Isn't this covered by the 'cpuid' HWCAP? We can't prevent EL0 from
> accessing these system registers anyway, even if we wanted to.

I see your argument, but I was just going on the side of consistency because
we're continuing to expose other features as HWCAPs when the capability is
just a proxy for the cpuid field. I was in favour of stopping the addition
of such HWCAPs years ago, but I couldn't convince Catalin ;)

The way I see it, we'll soon run out of HWCAP2 bits and then we'll have
our hand forced.

Will



More information about the linux-arm-kernel mailing list