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

[Heinrich Schuchardt]

On 04.06.20 10:05, Horia Geantă wrote:
> On 6/4/2020 5:31 AM, Heinrich Schuchardt wrote:
>> On 6/3/20 12:05 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.
>>>
>>> Signed-off-by: Michael Walle <michael at walle.cc>
>>> ---
>>>  drivers/crypto/fsl/Kconfig   | 11 +++++
>>>  drivers/crypto/fsl/Makefile  |  1 +
>>>  drivers/crypto/fsl/jobdesc.c |  9 ++++
>>>  drivers/crypto/fsl/jobdesc.h |  3 ++
>>>  drivers/crypto/fsl/jr.c      |  9 ++++
>>>  drivers/crypto/fsl/rng.c     | 84 ++++++++++++++++++++++++++++++++++++
>>>  6 files changed, 117 insertions(+)
>>>  create mode 100644 drivers/crypto/fsl/rng.c
>>>
>>> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
>>> index 181a1e5e99..5936b77494 100644
>>> --- a/drivers/crypto/fsl/Kconfig
>>> +++ b/drivers/crypto/fsl/Kconfig
>>> @@ -45,3 +45,14 @@ config SYS_FSL_SEC_COMPAT
>>>
>>>  config SYS_FSL_SEC_LE
>>>  	bool "Little-endian access to Freescale Secure Boot"
>>> +
>>> +if FSL_CAAM
>>> +
>>> +config FSL_CAAM_RNG
>>> +	bool "Enable Random Number Generator support"
>>> +	depends on DM_RNG
>>> +	default y
>>> +	help
>>> +	  Enable support for the random number generator module of the CAAM.
>>
>> Hello Michael,
>>
>> when typing CAAM into Google I got a lot of answers but "Cryptographic
>> Accelerator and Assurance Module" was not under the first 50 hits.
>>
>> If this is a hardware RNG I think we should put this into the text.
>>
> Totally agree.
>
> Besides other cryptographic services, CAAM offers:
> -a hardware RNG / TRNG
> -a PRNG / DRBG (SP800-90A compliant DRBG_Hash) - which is seeded
> from the TRNG
>
> Both are accessible by SW, so clarifying what the driver does
> would be useful (unless DM_RNG / UCLASS_RNG already implies
> one or the other).

The idea of DM_RNG is to collect entropy from hardware RNGs needed for
implementing the EFI_RNG_PROTOCOL. Our implementation of the
EFI_RNG_PROTOCOL up to now can only supply raw entropy. The UEFI
specification allows to additionally implement certain PRNG algorithms
seeded by the raw entropy which the caller can choose. So in a later
embodiment it may make sense to use what exists as hardware acceleration
for these.

Cf. UEFI Specification Version 2.8 (Errata A) (released February 2020)
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf

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

Isn't this what Linux' drivers/crypto/caam/caamrng.c does?

Best regards

Heinrich

> Conceptually this is similar to choosing between
> RDSEED vs. RDRDAND x86 instructions:
> https://software.intel.com/content/www/us/en/develop/blogs/the-difference-between-rdrand-and-rdseed.html
>
>> So how about:
>>
>> "Enable support the hardware random number generator of Freescale SOCs
>> using the Cryptographic Accelerator and Assurance Module (CAAM)."
>>
> The CAAM acronym is expanded at the top of the same file,
> under FSL_CAAM's help:
> <<Enables the Freescale's Cryptographic Accelerator and Assurance
> Module (CAAM), also known as the SEC version 4 (SEC4). The driver uses
> Job Ring as interface to communicate with CAAM.>>
>
> Horia
>