Hi Ahmad,

On Tue, May 17, 2022 at 06:25:08PM +0200, Ahmad Fatoum wrote:

Hello Mimi,

[Cc'ing RNG maintainers in case they want to chime in]

Thanks for adding me to this thread.

On 17.05.22 17:52, Mimi Zohar wrote:

quoted

On Fri, 2022-05-13 at 16:57 +0200, Ahmad Fatoum wrote:

quoted

 static int __init init_trusted(void)
 {
+       int (*get_random)(unsigned char *key, size_t key_len);
        int i, ret = 0;
 
        for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {

@@ -322,6 +333,28 @@ static int __init init_trusted(void)
                            strlen(trusted_key_sources[i].name)))
                        continue;
 
+               /*
+                * We always support trusted.rng="kernel" and "default" as
+                * well as trusted.rng=$trusted.source if the trust source
+                * defines its own get_random callback.
+                */

 
While TEE trusted keys support was upstreamed, there was a lot of
discussion about using kernel RNG.  One of the concerns was lack of or
insuffiencent entropy during early boot on embedded devices.  This
concern needs to be clearly documented in both Documentation/admin-
guide/kernel-parameters.txt and Documentation/security/keys/trusted-
encrypted.rst.

If a user decides to use kernel RNG for trusted keys, wait_for_random_bytes()
called first thing in the used get_random_bytes_wait() will (quoting
documentation) "wait for the input pool to be seeded and thus [is] guaranteed
to supply cryptographically secure random numbers."

Does this address your concerns about Kernel RNG use?

Indeed if get_random_bytes_wait() or wait_for_random_bytes() is called,
then the RNG will just block until it's accumulated 256 bits of
estimated entropy. The RNG will also make use of whatever hwrng or
cpu rng capabilities are available, and mix those in to augment its own
output.

Jason