On 6/3/2020 9:25 PM, Michael Walle wrote:
Hi Horia, Hi Heinrich,
thanks for reviewing.
Am 2020-06-03 19:35, schrieb Heinrich Schuchardt:
On 6/3/20 6:50 PM, Horia Geantă wrote:
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).
I would assume that all hardware RNGs use some algorithms to even out the distribution of the random bits coming from noise source. My understanding of the UEFI spec is that EFI_RNG_ALGORITHM_RAW simply does not provide any guarantee for the distribution quality while a PRNG reseeded via a hardware ring provides some guarantees.
Should you be aware that the FSL hardware RNG does not provide a well distributed entropy it would be preferable to pass the stream through a PRNG even if provided as EFI_RNG_ALGORITHM_RAW.
For CAAM prediction resistance (PR) details I suggest looking in the kernel: https://lore.kernel.org/linux-crypto/VI1PR0402MB3485EF10976A4A69F90E5B0F9858... 358ba762d9f1 crypto: caam - enable prediction resistance in HRWNG ea53756d831a crypto: caam - limit single JD RNG output to maximum of 16 bytes
I noticed that PR bit, but I wanted to keep things simple. Does all SEC
If UCLASS_RNG does not mandate for a TRNG, i.e. providing randomness from a PRNG / DRBG is acceptable, then adding PR support is not needed.
modules and versions support this, i.e. the kernel checks versions of some management controller in QorIQ SoCs.
All SEC / CAAM having RNG4 block support the PR bit.
I assume the version checking you are referring to is for the Management Complex (MC) firmware. MC block is available on SoCs with DPAA2 architecture: LS1088A, LS2088A, LX2160A The reason the check was added is that up to a certain point the f/w did not configure the RNG with PR support, and kernel would have to re-initialize the RNG only for those legacy f/w versions.
+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/*.
Is this also true for IMX and the PPC QorIQ SoCs?
CAAM is _NOT_ HW coherent on i.MX SoCs, while on the other PPC / ARM SoCs (QorIQ, Layerscape) it is.
Horia