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

[Michael Walle]

Am 2020-06-04 17:45, schrieb Heinrich Schuchardt:
> On 04.06.20 15:20, Michael Walle wrote:
>> Am 2020-06-04 14:58, schrieb Heinrich Schuchardt:
>>> On 04.06.20 14:52, Michael Walle wrote:
>>>> Am 2020-06-04 14:26, schrieb Heinrich Schuchardt:
>>>>> On 04.06.20 10:05, Horia Geantă wrote:
>>>>>> On 6/4/2020 5:31 AM, Heinrich Schuchardt wrote:
>>>> 
>>>>>> From what I see, driver added by Michael is using the PRNG / DRBG
>>>>>> and not the TRNG. Is this acceptable?
>>>>>> 
>>>>> 
>>>>> If it is only PRNG, this is not what we look for. If a PRNG/DRBG is
>>>>> used
>>>>> to ameliorate the raw entropy stream like Linux does for the
>>>>> /dev/random
>>>>> device this is fine. We need something non-deterministic.
>>>> 
>>>> What do you mean by "only PRNG"?
>>>> 
>>>>>> -a PRNG / DRBG (SP800-90A compliant DRBG_Hash) - which is seeded
>>>>>> from the TRNG
>>>> 
>>>> So while it is a PRNG, it is non-deterministic because its seeded
>>>> from the TRNG.
>>> 
>>> If for every byte that your DM_RNG driver outputs at least one byte 
>>> from
>>> the TRNG is consumed, it is fine. Otherwise it is not what we are
>>> looking for.
>> 
>> And why is that? This should really be documented somewhere.
> 
> We want to provide raw entropy in the EFI_RNG_PROTOCOL. So this cannot
> be a deterministic sequence of bytes where you only have to know the
> current state of a PRNG to find the next byte.

I wasn't aware of the fact that UCLASS_RNG was solely for
EFI_RNG_PROTOCOL. And there are no requirements for the UCLASS_RNG,
are there?

TBH I find this somewhat overkill for just having a random seed for
KASLR. Everyone is complaining about the size of the bootloader steadily
increasing, but then we throw in more and more for what use? Even the 
UEFI
spec states:

   When a Deterministic Random Bit Generator (DRBG) is used on the output
   of a (raw) entropy source, its security level must be at least 256 
bits.

Why does linux use ALGORITHM_RAW? What happens if that is not supported?

> As mentioned above you have a TRNG available. What is problematic about
> providing its output?

See v2, it should be now be the TRNG output, or at least it it reseeded
on every read and the read is limited to 16 bytes, like Horia said in
its very first reply. So I conclude the PRNG is at least seeded with
16 bytes.

-michael