[src/trunk]: src/sys/arch/arm/sunxi sun8icrypto(4): Attach rndsource as RND_T...

[riastradh <riastradh%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/4757ceb11e1d
branches:  trunk
changeset: 363960:4757ceb11e1d
user:      riastradh <riastradh%NetBSD.org@localhost>
date:      Fri Mar 18 23:36:42 2022 +0000

description:
sun8icrypto(4): Attach rndsource as RND_TYPE_RNG.

Previously this was attached as RND_TYPE_UNKNOWN, at a time when the
kernel assumed _any_ RNG-type rndsource produced independent uniform
random bits and subjected it to automatic tests that would fail with
high probability for many other distributions.  But sun8icrypto(4) is
very nonuniform (probably yields consecutive samples of a ring
oscillator, which are very much not independent).

Now the kernel no longer makes this assumption, so it is valid to
label this as what it is -- a hardware RNG.  We should ideally still
have better information from the vendor about what's going on under
the hood before enabling nonzero entropy for it.  But at least we can
label its type accurately.

diffstat:

 sys/arch/arm/sunxi/sun8i_crypto.c |  12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diffs (36 lines):

diff -r 23033dbb8813 -r 4757ceb11e1d sys/arch/arm/sunxi/sun8i_crypto.c
--- a/sys/arch/arm/sunxi/sun8i_crypto.c Fri Mar 18 23:35:48 2022 +0000
+++ b/sys/arch/arm/sunxi/sun8i_crypto.c Fri Mar 18 23:36:42 2022 +0000
@@ -1,4 +1,4 @@
-/*     $NetBSD: sun8i_crypto.c,v 1.27 2022/03/18 23:35:48 riastradh Exp $      */
+/*     $NetBSD: sun8i_crypto.c,v 1.28 2022/03/18 23:36:42 riastradh Exp $      */
 
 /*-
  * Copyright (c) 2019 The NetBSD Foundation, Inc.
@@ -43,7 +43,7 @@
  */
 
 #include <sys/cdefs.h>
-__KERNEL_RCSID(1, "$NetBSD: sun8i_crypto.c,v 1.27 2022/03/18 23:35:48 riastradh Exp $");
+__KERNEL_RCSID(1, "$NetBSD: sun8i_crypto.c,v 1.28 2022/03/18 23:36:42 riastradh Exp $");
 
 #include <sys/types.h>
 #include <sys/param.h>
@@ -1284,14 +1284,12 @@
        }
 
        /*
-        * Attach the rndsource.  This is _not_ marked as RND_TYPE_RNG
-        * because the output is not uniformly distributed.  The bits
-        * are heavily weighted toward 0 or 1, at different times, and
-        * I haven't scienced a satisfactory story out of it yet.
+        * Attach the rndsource.  This will trigger an initial call to
+        * it since we have RND_FLAG_HASCB.
         */
        rndsource_setcb(&rng->cr_rndsource, sun8i_crypto_rng_get, sc);
        rnd_attach_source(&rng->cr_rndsource, device_xname(self),
-           RND_TYPE_UNKNOWN,
+           RND_TYPE_RNG,
            RND_FLAG_COLLECT_VALUE|RND_FLAG_ESTIMATE_VALUE|RND_FLAG_HASCB);
 
        /* Success!  */