Messages in this thread | | | From | Ard Biesheuvel <> | Date | Mon, 12 Oct 2020 08:35:26 +0200 | Subject | Re: [PATCH 2/2] arm64: Add support for SMCCC TRNG firmware interface |
| |
On Wed, 7 Oct 2020 at 16:44, André Przywara <andre.przywara@arm.com> wrote: > > On 07/10/2020 15:16, James Morse wrote: > > Hi, > > > On 06/10/2020 21:18, Andre Przywara wrote: > >> The ARM architected TRNG firmware interface, described in ARM spec > >> DEN0098[1], defines an ARM SMCCC based interface to a true random number > >> generator, provided by firmware. > >> This can be discovered via the SMCCC >=v1.1 interface, and provides > >> up to 192 bits of entropy per call. > >> > >> Hook this SMC call into arm64's arch_get_random_*() implementation, > >> coming to the rescue when the CPU does not implement the ARM v8.5 RNG > >> system registers. > >> > >> For the detection, we piggy back on the PSCI/SMCCC discovery (which gives > >> us the conduit to use: hvc or smc), then try to call the > >> ARM_SMCCC_TRNG_VERSION function, which returns -1 if this interface is > >> not implemented. > > > >> arch/arm64/include/asm/archrandom.h | 83 +++++++++++++++++++++++++---- > >> 1 file changed, 73 insertions(+), 10 deletions(-) > > > >> diff --git a/arch/arm64/include/asm/archrandom.h b/arch/arm64/include/asm/archrandom.h > >> index ffb1a40d5475..b6c291c42a48 100644 > >> --- a/arch/arm64/include/asm/archrandom.h > >> +++ b/arch/arm64/include/asm/archrandom.h > >> @@ -7,6 +7,13 @@ > >> #include <linux/bug.h> > >> #include <linux/kernel.h> > >> #include <asm/cpufeature.h> > >> +#include <linux/arm-smccc.h> > >> + > >> +static enum smc_trng_status { > >> + SMC_TRNG_UNKNOWN, > >> + SMC_TRNG_NOT_SUPPORTED, > >> + SMC_TRNG_SUPPORTED > >> +} smc_trng_status = SMC_TRNG_UNKNOWN; > > > > Doesn't this static variable in a header file mean each file that includes this has its > > own copy? Is that intentional? > > Right, and it's not intentional. It doesn't really break, but since > random.h includes archrandom.h, we get an instance everywhere :-( > > I wasn't too happy with this detection method to begin with (and also > not with stuffing everything into a header file), but wanted to > accommodate the early case, where PSCI hasn't been initialised yet, and > so we don't know the SMCCC conduit. A static key sounds better, but gets > a bit hairy with this scenario, I think. > > Any ideas here?
I think the early case isn't worth obsessing about. PSCI is initialized in setup_arch(), which gets called way before rand_initialize(), which is where this functionality will get used the first time typically. And kaslr_early_init() is called extremely early, i.e., straight from head.S, and we should avoid adding any more code there that sets global state (if kaslr_early_init() exits successfully, the kernel will be unmapped and remapped again in a different place, and BSS cleared again etc etc)
> I could copy Ard's solution and introduce random.c, if that makes more > sense. > > Cheers, > Andre
| |