[PATCH 4/4] crypto/fsl: add RNG support

[Horia Geantă]

On 6/3/2020 1:06 AM, Michael Walle wrote:
> Register the random number generator with the rng subsystem in u-boot.
> This way it can be used by EFI as well as for the 'rng' command.
> 
I am trying to understand what's expected from UCLASS_RNG...

UEFI spec mentions:
<<The “raw” algorithm, when supported, is intended to provide entropy
directly from the source, without it going through
some deterministic random bit generator.>>

lib/efi_loader/efi_rng.c uses EFI_RNG_ALGORITHM_RAW and is happy
with whatever UCLASS_RNG implementation it gets.

>From above I'd conclude all UCLASS_RNG implementations are expected to
provide "full" entropy directly from a TRNG source, without any DRBG
connected in the middle (b/w TRNG and user).

Is this correct?
If so, note that using CAAM's job ring interface without prediction resistance
to extract randomness does not fit the bill, since TRNG output
is connected to a DRBG (DRBG_Hash, SP800-90A compliant).

For CAAM prediction resistance (PR) details I suggest looking in the kernel:
https://lore.kernel.org/linux-crypto/VI1PR0402MB3485EF10976A4A69F90E5B0F98580@VI1PR0402MB3485.eurprd04.prod.outlook.com
358ba762d9f1 crypto: caam - enable prediction resistance in HRWNG
ea53756d831a crypto: caam - limit single JD RNG output to maximum of 16 bytes

Steps required to add PR support:
-initialize ("instantiate") the RNG state handles (the DRBGs)
with PR support; if already instantiated (by ROM, OP-TEE etc.),
they must be re-instantiated if PR support was not enabled
-use the "PR" option when extracting randomness from the DRBG;
this forces a re-seed of the DRBG
-limit the data size drawn from the DRBG; this is already done
(see CAAM_RNG_MAX_FIFO_STORE_SIZE)

> @@ -665,6 +666,14 @@ int sec_init_idx(uint8_t sec_idx)
>  			printf("SEC%u: RNG instantiation failed\n", sec_idx);
>  			return -1;
>  		}
> +#ifdef CONFIG_DM_RNG
> +		if (IS_ENABLED(CONFIG_DM_RNG)) {
Shouldn't one or the other (#ifdef / IS_ENABLED) suffice?

> +static int caam_rng_read_one(struct caam_rng_platdata *pdata)
> +{
> +	int size = CAAM_RNG_MAX_FIFO_STORE_SIZE;
> +	int ret;
> +
> +	ret = run_descriptor_jr(pdata->desc);
> +	if (ret < 0)
> +		return -EIO;
> +
> +	invalidate_dcache_range((unsigned long)pdata->data,
> +				(unsigned long)pdata->data + size);
Side note: this is not required on Layerscape SoCs, since CAAM is HW coherent.
Most surely this needs to be handled in a separate patch set,
throughout drivers/crypto/fsl/*.

Horia