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

[Horia Geantă]

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/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
> 
> 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