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