[PATCH 0/3] enable CAAM's HWRNG as default

[PATCH 0/3] enable CAAM's HWRNG as default

[Andrey Smirnov]

Everyone:

This series is a continuation of original [discussion]. I don't know
if what's in the series is enough to use CAAMs HWRNG system wide, but
I am hoping that with enough iterations and feedback it will be.

Feedback is welcome!

Thanks,
Andrey Smirnov

[discussion] https://patchwork.kernel.org/patch/9850669/

Andrey Smirnov (3):
  crypto: caam - RNG4 TRNG errata
  crypto: caam - enable prediction resistance in HRWNG
  crypto: caam - set hwrng quality level

 drivers/crypto/caam/caamrng.c |  4 +++-
 drivers/crypto/caam/ctrl.c    | 19 +++++++++++++------
 drivers/crypto/caam/desc.h    |  2 ++
 drivers/crypto/caam/regs.h    |  7 +++++--
 4 files changed, 23 insertions(+), 9 deletions(-)

-- 
2.21.0

[PATCH 1/3] crypto: caam - RNG4 TRNG errata

[Andrey Smirnov]

The TRNG as used in RNG4, used in CAAM has a documentation issue. The
effect is that it is possible that the entropy used to instantiate the
DRBG may be old entropy, rather than newly generated entropy. There is
proper programming guidance, but it is not in the documentation.

Signed-off-by: Aymen Sghaier <aymen.sghaier@nxp.com>
Signed-off-by: Vipul Kumar <vipul_kumar@mentor.com>
[andrew.smirnov@gmail.com ported to upstream kernel]
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/crypto/caam/ctrl.c | 11 ++++++++---
 drivers/crypto/caam/regs.h |  3 ++-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index d7c3c3805693..df4db10e9fca 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -338,8 +338,12 @@ static void kick_trng(struct platform_device *pdev, int ent_delay)
 	ctrl = (struct caam_ctrl __iomem *)ctrlpriv->ctrl;
 	r4tst = &ctrl->r4tst[0];
 
-	/* put RNG4 into program mode */
-	clrsetbits_32(&r4tst->rtmctl, 0, RTMCTL_PRGM);
+	/*
+	 * Setting both RTMCTL:PRGM and RTMCTL:TRNG_ACC causes TRNG to
+	 * properly invalidate the entropy in the entropy register and
+	 * force re-generation.
+	 */
+	clrsetbits_32(&r4tst->rtmctl, 0, RTMCTL_PRGM | RTMCTL_ACC);
 
 	/*
 	 * Performance-wise, it does not make sense to
@@ -369,7 +373,8 @@ static void kick_trng(struct platform_device *pdev, int ent_delay)
 	 * select raw sampling in both entropy shifter
 	 * and statistical checker; ; put RNG4 into run mode
 	 */
-	clrsetbits_32(&r4tst->rtmctl, RTMCTL_PRGM, RTMCTL_SAMP_MODE_RAW_ES_SC);
+	clrsetbits_32(&r4tst->rtmctl, RTMCTL_PRGM | RTMCTL_ACC,
+		      RTMCTL_SAMP_MODE_RAW_ES_SC);
 }
 
 static int caam_get_era_from_hw(struct caam_ctrl __iomem *ctrl)
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 05127b70527d..c191e8fd0fa7 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -487,7 +487,8 @@ struct rngtst {
 
 /* RNG4 TRNG test registers */
 struct rng4tst {
-#define RTMCTL_PRGM	0x00010000	/* 1 -> program mode, 0 -> run mode */
+#define RTMCTL_ACC  BIT(5)  /* TRNG access mode */
+#define RTMCTL_PRGM BIT(16) /* 1 -> program mode, 0 -> run mode */
 #define RTMCTL_SAMP_MODE_VON_NEUMANN_ES_SC	0 /* use von Neumann data in
 						     both entropy shifter and
 						     statistical checker */
-- 
2.21.0

[PATCH 2/3] crypto: caam - enable prediction resistance in HRWNG

[Andrey Smirnov]

Instantiate CAAM RNG with prediction resistance enabled to improve its
quality.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/crypto/caam/caamrng.c | 3 ++-
 drivers/crypto/caam/ctrl.c    | 8 +++++---
 drivers/crypto/caam/desc.h    | 2 ++
 drivers/crypto/caam/regs.h    | 4 +++-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index e8baacaabe07..6dde8ae3cd9b 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -202,7 +202,8 @@ static inline int rng_create_sh_desc(struct caam_rng_ctx *ctx)
 	init_sh_desc(desc, HDR_SHARE_SERIAL);
 
 	/* Generate random bytes */
-	append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG);
+	append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
+			 OP_ALG_PR_ON);
 
 	/* Store bytes */
 	append_seq_fifo_store(desc, RN_BUF_SIZE, FIFOST_TYPE_RNGSTORE);
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index df4db10e9fca..a1c879820286 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -36,7 +36,8 @@ static void build_instantiation_desc(u32 *desc, int handle, int do_sk)
 	init_job_desc(desc, 0);
 
 	op_flags = OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
-			(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT;
+			(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT |
+			OP_ALG_PR_ON;
 
 	/* INIT RNG in non-test mode */
 	append_operation(desc, op_flags);
@@ -275,11 +276,12 @@ static int instantiate_rng(struct device *ctrldev, int state_handle_mask,
 		return -ENOMEM;
 
 	for (sh_idx = 0; sh_idx < RNG4_MAX_HANDLES; sh_idx++) {
+		const u32 rdsta_mask = (RDSTA_PR0 | RDSTA_IF0) << sh_idx;
 		/*
 		 * If the corresponding bit is set, this state handle
 		 * was initialized by somebody else, so it's left alone.
 		 */
-		if ((1 << sh_idx) & state_handle_mask)
+		if (rdsta_mask & state_handle_mask)
 			continue;
 
 		/* Create the descriptor for instantiating RNG State Handle */
@@ -302,7 +304,7 @@ static int instantiate_rng(struct device *ctrldev, int state_handle_mask,
 
 		rdsta_val = rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK;
 		if ((status && status != JRSTA_SSRC_JUMP_HALT_CC) ||
-		    !(rdsta_val & (1 << sh_idx))) {
+		    (rdsta_val & rdsta_mask) != rdsta_mask) {
 			ret = -EAGAIN;
 			break;
 		}
diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h
index 4b6854bf896a..e796d3cb9be8 100644
--- a/drivers/crypto/caam/desc.h
+++ b/drivers/crypto/caam/desc.h
@@ -1254,6 +1254,8 @@
 #define OP_ALG_ICV_OFF		(0 << OP_ALG_ICV_SHIFT)
 #define OP_ALG_ICV_ON		(1 << OP_ALG_ICV_SHIFT)
 
+#define OP_ALG_PR_ON		BIT(1)
+
 #define OP_ALG_DIR_SHIFT	0
 #define OP_ALG_DIR_MASK		1
 #define OP_ALG_DECRYPT		0
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index c191e8fd0fa7..fe1f8c1409fd 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -524,9 +524,11 @@ struct rng4tst {
 	u32 rsvd1[40];
 #define RDSTA_SKVT 0x80000000
 #define RDSTA_SKVN 0x40000000
+#define RDSTA_PR0 BIT(4)
+#define RDSTA_PR1 BIT(5)
 #define RDSTA_IF0 0x00000001
 #define RDSTA_IF1 0x00000002
-#define RDSTA_IFMASK (RDSTA_IF1 | RDSTA_IF0)
+#define RDSTA_IFMASK (RDSTA_PR1 | RDSTA_PR0 | RDSTA_IF1 | RDSTA_IF0)
 	u32 rdsta;
 	u32 rsvd2[15];
 };
-- 
2.21.0

[PATCH 3/3] crypto: caam - set hwrng quality level

[Andrey Smirnov]

Set high quality to let the HWRNG framework automatically use it.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Horia Geantă <horia.geanta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/crypto/caam/caamrng.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 6dde8ae3cd9b..23a573ea6cdb 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -299,6 +299,7 @@ static struct hwrng caam_rng = {
 	.name		= "rng-caam",
 	.cleanup	= caam_cleanup,
 	.read		= caam_read,
+	.quality	= 999,
 };
 
 void caam_rng_exit(void)
-- 
2.21.0

Re: [PATCH 0/3] enable CAAM's HWRNG as default

[Lucas Stach]

On Di, 2019-10-29 at 09:29 -0700, Andrey Smirnov wrote:
> Everyone:
> 
> This series is a continuation of original [discussion]. I don't know
> if what's in the series is enough to use CAAMs HWRNG system wide, but
> I am hoping that with enough iterations and feedback it will be.
> 
> Feedback is welcome!

I'm not sure if we can ever use the job based RNG interface to hook it
up to the Linux HWRNG interface. After all the job based RNG interface
is always a DRNG, which only gets seeded by the TRNG. The reseed
interval is given in number of clock cycles, so there is no clear
correlation between really true random input bits and the number of
DRNG output bits.

I've hacked up some proof of concept code which uses the TRNG access in
the control interface to get the raw TRNG random bits. This seems to
yield about 6400 bit/s of true entropy. It may be better to use this
interface to hook up to the Linux HWRNG framework.

Regards,
Lucas

Re: [PATCH 0/3] enable CAAM's HWRNG as default

[Andrey Smirnov]

On Tue, Oct 29, 2019 at 9:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> On Di, 2019-10-29 at 09:29 -0700, Andrey Smirnov wrote:
> > Everyone:
> >
> > This series is a continuation of original [discussion]. I don't know
> > if what's in the series is enough to use CAAMs HWRNG system wide, but
> > I am hoping that with enough iterations and feedback it will be.
> >
> > Feedback is welcome!
>
> I'm not sure if we can ever use the job based RNG interface to hook it
> up to the Linux HWRNG interface. After all the job based RNG interface
> is always a DRNG, which only gets seeded by the TRNG. The reseed
> interval is given in number of clock cycles, so there is no clear
> correlation between really true random input bits and the number of
> DRNG output bits.
>

Doesn't enabling prediction resistance gives us that correlation? E.g.
that every time new random data is generated, DRNG is reseeded? I am
assuming even if this is true we'd have to significantly limit
generated data length (< seed length?), so maybe what you propose
below is still simpler.

> I've hacked up some proof of concept code which uses the TRNG access in
> the control interface to get the raw TRNG random bits. This seems to
> yield about 6400 bit/s of true entropy. It may be better to use this
> interface to hook up to the Linux HWRNG framework.
>

OK, I'll take a look into that and send out a v2 with results.

Thanks,
Andrey Smirnov

Re: [PATCH 0/3] enable CAAM's HWRNG as default

[Herbert Xu]

On Tue, Oct 29, 2019 at 12:58:24PM -0700, Andrey Smirnov wrote:
>
> > I'm not sure if we can ever use the job based RNG interface to hook it
> > up to the Linux HWRNG interface. After all the job based RNG interface
> > is always a DRNG, which only gets seeded by the TRNG. The reseed
> > interval is given in number of clock cycles, so there is no clear
> > correlation between really true random input bits and the number of
> > DRNG output bits.
> 
> Doesn't enabling prediction resistance gives us that correlation? E.g.
> that every time new random data is generated, DRNG is reseeded? I am
> assuming even if this is true we'd have to significantly limit
> generated data length (< seed length?), so maybe what you propose
> below is still simpler.

Prediction resistance should be sufficient in general.  However,
is the prediction resistance reseeding done in real time?

> > I've hacked up some proof of concept code which uses the TRNG access in
> > the control interface to get the raw TRNG random bits. This seems to
> > yield about 6400 bit/s of true entropy. It may be better to use this
> > interface to hook up to the Linux HWRNG framework.
> 
> OK, I'll take a look into that and send out a v2 with results.

I've backed out the patch-set for now but if we can clarify the
prediction resistance implementation details then I'm happy to
put it back in.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/3] enable CAAM's HWRNG as default

[Andrey Smirnov]

On Fri, Nov 8, 2019 at 7:19 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Oct 29, 2019 at 12:58:24PM -0700, Andrey Smirnov wrote:
> >
> > > I'm not sure if we can ever use the job based RNG interface to hook it
> > > up to the Linux HWRNG interface. After all the job based RNG interface
> > > is always a DRNG, which only gets seeded by the TRNG. The reseed
> > > interval is given in number of clock cycles, so there is no clear
> > > correlation between really true random input bits and the number of
> > > DRNG output bits.
> >
> > Doesn't enabling prediction resistance gives us that correlation? E.g.
> > that every time new random data is generated, DRNG is reseeded? I am
> > assuming even if this is true we'd have to significantly limit
> > generated data length (< seed length?), so maybe what you propose
> > below is still simpler.
>
> Prediction resistance should be sufficient in general.  However,
> is the prediction resistance reseeding done in real time?
>

If I am reading the datasheet right reseeding should be done every
time CAAM is asked to generated random data.

> > > I've hacked up some proof of concept code which uses the TRNG access in
> > > the control interface to get the raw TRNG random bits. This seems to
> > > yield about 6400 bit/s of true entropy. It may be better to use this
> > > interface to hook up to the Linux HWRNG framework.
> >
> > OK, I'll take a look into that and send out a v2 with results.
>
> I've backed out the patch-set for now but if we can clarify the
> prediction resistance implementation details then I'm happy to
> put it back in.

Even if prediction resistance is an acceptable approach, would it be
better to expose underlying TRNG and downgrade current CAAM hwrng code
to crypto rng API? If that's the best path forward, I am more than
happy to go that way in v2.

Thanks,
Andrey Smirnov

Re: [PATCH 0/3] enable CAAM's HWRNG as default

[Herbert Xu]

On Tue, Nov 12, 2019 at 07:13:02AM -0800, Andrey Smirnov wrote:
>
> If I am reading the datasheet right reseeding should be done every
> time CAAM is asked to generated random data.

If you can guarantee that everytime the driver reads n bytes from
the hardware, that the hardware is then reseeded with nbytes prior
to that read, then it should be good enough.

If the hardware only reseeds afterwards or reseeds with less than
n bytes then it is not sufficient.
 
> Even if prediction resistance is an acceptable approach, would it be
> better to expose underlying TRNG and downgrade current CAAM hwrng code
> to crypto rng API? If that's the best path forward, I am more than
> happy to go that way in v2.

If it offers true prediction resistance it should be good enough
to use the drivers/char/hw_random interface.  Otherwise please
switch to the Crypto API RNG interface.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/3] enable CAAM's HWRNG as default

[Herbert Xu]

On Tue, Oct 29, 2019 at 09:29:13AM -0700, Andrey Smirnov wrote:
> Everyone:
> 
> This series is a continuation of original [discussion]. I don't know
> if what's in the series is enough to use CAAMs HWRNG system wide, but
> I am hoping that with enough iterations and feedback it will be.
> 
> Feedback is welcome!
> 
> Thanks,
> Andrey Smirnov
> 
> [discussion] https://patchwork.kernel.org/patch/9850669/
> 
> Andrey Smirnov (3):
>   crypto: caam - RNG4 TRNG errata
>   crypto: caam - enable prediction resistance in HRWNG
>   crypto: caam - set hwrng quality level
> 
>  drivers/crypto/caam/caamrng.c |  4 +++-
>  drivers/crypto/caam/ctrl.c    | 19 +++++++++++++------
>  drivers/crypto/caam/desc.h    |  2 ++
>  drivers/crypto/caam/regs.h    |  7 +++++--
>  4 files changed, 23 insertions(+), 9 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt