arm64: random: implement arch_get_random_int/_long based on RNDR

When support for RNDR/RNDRRS was introduced, we elected to only implement arch_get_random_seed_int/_long(), and back them by RNDR instead of RNDRRS. This was needed to prevent potential performance and/or starvation issues resulting from the fact that the /dev/random driver used to invoke these routines on various hot paths.

- map arch_get_random_int/_long() onto RNDR, which returns the output of a DRBG that is reseeded at an implemented defined rate;

arch/arm64/include/asm/archrandom.h +1 -1

 	 */
-	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndrrs(v))
 		return true;
 
 	return false;

Hi Ard,

Wow, didn't expect for this to come so fast. Excellent.

Quoted 2 lines · Ard Biesheuvel

- map arch_get_random_int/_long() onto RNDR, which returns the output of a DRBG that is reseeded at an implemented defined rate;

implemented -> implementation?

arch/arm64/include/asm/archrandom.h static inline bool __arm64_rndr(unsigned long *v) · line 74

Quoted 12 lines

static inline bool __must_check arch_get_random_long(unsigned long *v) {

arch/arm64/include/asm/archrandom.h +8 -0

+     /*
+      * Only support the generic interface after we have detected
+      * the system wide capability, avoiding complexity with the
+      * cpufeature code and with potential scheduling between CPUs
+      * with and without the feature.
+      */
+     if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+             return true;
      return false;
 }

Can't this just become:

  return cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v);

arch/arm64/include/asm/archrandom.h static inline bool __arm64_rndr(unsigned long *v) · line 87

Quoted 13 lines

static inline bool __must_check arch_get_random_int(unsigned int *v) {

arch/arm64/include/asm/archrandom.h +8 -0

+     if (cpus_have_const_cap(ARM64_HAS_RNG)) {
+             unsigned long val;
+
+             if (__arm64_rndr(&val)) {
+                     *v = val;
+                     return true;
+             }
+     }
      return false;
 }

Why not implement arch_get_random_int with the same type of flow as arch_get_random_long?

static inline bool __must_check arch_get_random_int(unsigned int *v)

{
        unsigned long val;
        if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(&val))) {
                *v = val;
                return true;
        }
        return false;
}

Or, even better, just define arch_get_random_int in terms of arch_get_random_long:

static inline bool __must_check arch_get_random_int(unsigned int *v)

{
        unsigned long val;
        if (arch_get_random_long(&val)) {
                *v = val;
                return true;
        }
        return false;
}

arch/arm64/include/asm/archrandom.h static inline bool __must_check arch_get_random_seed_long(unsigned long *v) · line 110

Quoted 11 lines

arch/arm64/include/asm/archrandom.h +3 -4

@@ -71,12 +105,11 @@ static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
      }
 
      /*
-      * Only support the generic interface after we have detected
-      * the system wide capability, avoiding complexity with the
-      * cpufeature code and with potential scheduling between CPUs
-      * with and without the feature.
+      * RNDRRS is not backed by an entropy source but by a DRBG that is
+      * reseeded after each invocation. This is not a 100% fit but good
+      * enough to implement this API if no other entropy source exists.

The docs are actually a bit more optimistic than that:

https://developer.arm.com/documentation/ddi0595/2021-03/AArch64-Registers/RNDRRS--Reseeded-Random-Number

~ Reseeded Random Number. Returns a 64-bit random number which is reseeded ~ from the True Random Number source immediately before the read of the ~ random number.

If I'm reading that correctly, it looks like the reseeding happens *before* the read, and it looks like it comes from a TRNG. In other words, it sounds to me like it's just doing something like HASH(READ_TRNG()). That would be pretty darn good.

Quoted 7 lines

arch/arm64/include/asm/archrandom.h +1 -1

       */
-     if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+     if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndrrs(v))
              return true;
 
      return false;

arch/arm64/include/asm/archrandom.h static inline bool __must_check arch_get_random_seed_int(unsigned int *v) · line 135

Quoted 8 lines

arch/arm64/include/asm/archrandom.h +1 -1

@@ -96,7 +129,7 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
      }
 
      if (cpus_have_const_cap(ARM64_HAS_RNG)) {
-             if (__arm64_rndr(&val)) {
+             if (__arm64_rndrrs(&val)) {
                      *v = val;
                      return true;
              }

I suppose the same control flow simplification stuff mentioned above could be done here too, if you feel like what I mentioned earlier is worthwhile.

From a randomness perspective:

Acked-by Jason A. Donenfeld <[email protected]>

Sure, but I just retained the original style.
If I was interested in rewriting this header file, I might consider all these options. For now, I am just trying to focus the change on the parts that actually matter.

No it does not. RNDR and RNDRRS both return the output of a DRBG, the only difference is the reseed interval.

Specifically, this means that, even though the ARM ARM references NIST SP800-90B directly, the RNDRRS construction is a black box containing a entropy source + DRBG, and so we shouldn't pretend that RNDRRS itself can be treated as a source of true entropy. This is especially relevant when it comes to seeding a DRBG of a certain security strength N >= the security strength of the hidden DRBG, as concatenating multiple RNDRRS results does not satisfy the requirements for seeding a DRBG of security strength N.

Wow, didn't expect for this to come so fast. Excellent.

Quoted 2 lines · Ard Biesheuvel

- map arch_get_random_int/_long() onto RNDR, which returns the output of a DRBG that is reseeded at an implemented defined rate;

implemented -> implementation?

arch/arm64/include/asm/archrandom.h static inline bool __arm64_rndr(unsigned long *v) · line 74

Quoted 12 lines

static inline bool __must_check arch_get_random_long(unsigned long *v) {

arch/arm64/include/asm/archrandom.h +8 -0

+	/*
+	 * Only support the generic interface after we have detected
+	 * the system wide capability, avoiding complexity with the
+	 * cpufeature code and with potential scheduling between CPUs
+	 * with and without the feature.
+	 */
+	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+		return true;
 	return false;
 }  

Can't this just become:

  return cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v);

arch/arm64/include/asm/archrandom.h static inline bool __arm64_rndr(unsigned long *v) · line 87

Quoted 13 lines

static inline bool __must_check arch_get_random_int(unsigned int *v) {

arch/arm64/include/asm/archrandom.h +8 -0

+	if (cpus_have_const_cap(ARM64_HAS_RNG)) {
+		unsigned long val;
+
+		if (__arm64_rndr(&val)) {
+			*v = val;
+			return true;
+		}
+	}
 	return false;
 }  

Why not implement arch_get_random_int with the same type of flow as arch_get_random_long?

static inline bool __must_check arch_get_random_int(unsigned int *v)

{
	unsigned long val;
	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(&val))) {
		*v = val;
		return true;
	}
	return false;
}

Or, even better, just define arch_get_random_int in terms of arch_get_random_long:

static inline bool __must_check arch_get_random_int(unsigned int *v)

{
	unsigned long val;
	if (arch_get_random_long(&val)) {
		*v = val;
		return true;
	}
	return false;
}

arch/arm64/include/asm/archrandom.h static inline bool __must_check arch_get_random_seed_long(unsigned long *v) · line 110

Quoted 11 lines

arch/arm64/include/asm/archrandom.h +3 -4

@@ -71,12 +105,11 @@ static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
 	}
 
 	/*
-	 * Only support the generic interface after we have detected
-	 * the system wide capability, avoiding complexity with the
-	 * cpufeature code and with potential scheduling between CPUs
-	 * with and without the feature.
+	 * RNDRRS is not backed by an entropy source but by a DRBG that is
+	 * reseeded after each invocation. This is not a 100% fit but good
+	 * enough to implement this API if no other entropy source exists.  

The docs are actually a bit more optimistic than that:

https://developer.arm.com/documentation/ddi0595/2021-03/AArch64-Registers/RNDRRS--Reseeded-Random-Number

~ Reseeded Random Number. Returns a 64-bit random number which is reseeded ~ from the True Random Number source immediately before the read of the ~ random number.

If I'm reading that correctly, it looks like the reseeding happens *before* the read, and it looks like it comes from a TRNG. In other words, it sounds to me like it's just doing something like HASH(READ_TRNG()). That would be pretty darn good.

Quoted 7 lines

arch/arm64/include/asm/archrandom.h +1 -1

 	 */
-	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndrrs(v))
 		return true;
 
 	return false;

arch/arm64/include/asm/archrandom.h static inline bool __must_check arch_get_random_seed_int(unsigned int *v) · line 135

Quoted 8 lines

arch/arm64/include/asm/archrandom.h +1 -1

@@ -96,7 +129,7 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
 	}
 
 	if (cpus_have_const_cap(ARM64_HAS_RNG)) {
-		if (__arm64_rndr(&val)) {
+		if (__arm64_rndrrs(&val)) {
 			*v = val;
 			return true;
 		}  

I suppose the same control flow simplification stuff mentioned above could be done here too, if you feel like what I mentioned earlier is worthwhile.

From a randomness perspective:

Acked-by Jason A. Donenfeld <[email protected]>

Thanks,
Jason

When support for RNDR/RNDRRS was introduced, we elected to only implement arch_get_random_seed_int/_long(), and back them by RNDR instead of RNDRRS. This was needed to prevent potential performance and/or starvation issues resulting from the fact that the /dev/random driver used to invoke these routines on various hot paths.

These issues have all been addressed now [0] [1], and so we can wire up this API more straight-forwardly:

- map arch_get_random_int/_long() onto RNDR, which returns the output of a DRBG that is reseeded at an implemented defined rate;
- map arch_get_random_seed_int/_long() onto the TRNG firmware service, which returns true, conditioned entropy, or onto RNDRRS if the TRNG service is unavailable, which returns the output of a DRBG that is reseeded every time it is used.

[0] 390596c9959c random: avoid arch_get_random_seed_long() when collecting IRQ randomness
[1] 2ee25b6968b1 random: avoid superfluous call to RDRAND in CRNG extraction

Cc Andre Przywara <[email protected]>

Cc Mark Brown <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm64/include/asm/archrandom.h | 45 +++++++++++++++++---
 1 file changed, 39 insertions(+), 6 deletions(-)

arch/arm64/include/asm/archrandom.h +38 -5

index 09e43272ccb0..d1bb5e71df25 100644
@@ -42,13 +42,47 @@ static inline bool __arm64_rndr(unsigned long *v)
 	return ok;
 }
 
+static inline bool __arm64_rndrrs(unsigned long *v)
+{
+	bool ok;
+
+	/*
+	 * Reads of RNDRRS set PSTATE.NZCV to 0b0000 on success,
+	 * and set PSTATE.NZCV to 0b0100 otherwise.
+	 */
+	asm volatile(
+		__mrs_s("%0", SYS_RNDRRS_EL0) "\n"
+	"	cset %w1, ne\n"
+	: "=r" (*v), "=r" (ok)
+	:
+	: "cc");
+
+	return ok;
+}
+
 static inline bool __must_check arch_get_random_long(unsigned long *v)
 {
+	/*
+	 * Only support the generic interface after we have detected
+	 * the system wide capability, avoiding complexity with the
+	 * cpufeature code and with potential scheduling between CPUs
+	 * with and without the feature.
+	 */
+	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+		return true;
 	return false;
 }
 
 static inline bool __must_check arch_get_random_int(unsigned int *v)
 {
+	if (cpus_have_const_cap(ARM64_HAS_RNG)) {
+		unsigned long val;
+
+		if (__arm64_rndr(&val)) {
+			*v = val;
+			return true;
+		}
+	}
 	return false;
 }
 

@@ -71,12 +105,11 @@ static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
 	}
 
 	/*
-	 * Only support the generic interface after we have detected
-	 * the system wide capability, avoiding complexity with the
-	 * cpufeature code and with potential scheduling between CPUs
-	 * with and without the feature.
+	 * RNDRRS is not backed by an entropy source but by a DRBG that is
+	 * reseeded after each invocation. This is not a 100% fit but good
+	 * enough to implement this API if no other entropy source exists.
 	 */
-	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
+	if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndrrs(v))
 		return true;
 
 	return false;

When support for RNDR/RNDRRS was introduced, we elected to only implement arch_get_random_seed_int/_long(), and back them by RNDR instead of RNDRRS. This was needed to prevent potential performance and/or starvation issues resulting from the fact that the /dev/random driver used to invoke these routines on various hot paths.

These issues have all been addressed now [0] [1], and so we can wire up this API more straight-forwardly:

[...]