[PATCH] crypto: caam - enable prediction resistance conditionally

[PATCH] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

From: Fabio Estevam <festevam@denx.de>

Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance
in HRWNG") the following CAAM errors can be seen on i.MX6:

caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
hwrng: no data available
caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
hwrng: no data available
caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
hwrng: no data available
caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
hwrng: no data available

OP_ALG_PR_ON is enabled unconditionally, which may cause the problem
on i.MX devices.

Fix the problem by only enabling OP_ALG_PR_ON on platforms that have
Management Complex support.

Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG")
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
 drivers/crypto/caam/caamrng.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index 77d048dfe5d0..3514fe5de2a5 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -63,12 +63,19 @@ static void caam_rng_done(struct device *jrdev, u32 *desc, u32 err,
 	complete(jctx->done);
 }
 
-static u32 *caam_init_desc(u32 *desc, dma_addr_t dst_dma)
+static u32 *caam_init_desc(struct device *jrdev, u32 *desc, dma_addr_t dst_dma)
 {
+	struct caam_drv_private *priv = dev_get_drvdata(jrdev->parent);
+
 	init_job_desc(desc, 0);	/* + 1 cmd_sz */
 	/* Generate random bytes: + 1 cmd_sz */
-	append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
-			 OP_ALG_PR_ON);
+
+	if (priv->mc_en)
+		append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
+				  OP_ALG_PR_ON);
+	else
+		append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG);
+
 	/* Store bytes: + 1 cmd_sz + caam_ptr_sz  */
 	append_fifo_store(desc, dst_dma,
 			  CAAM_RNG_MAX_FIFO_STORE_SIZE, FIFOST_TYPE_RNGSTORE);
@@ -101,7 +108,7 @@ static int caam_rng_read_one(struct device *jrdev,
 
 	init_completion(done);
 	err = caam_jr_enqueue(jrdev,
-			      caam_init_desc(desc, dst_dma),
+			      caam_init_desc(jrdev, desc, dst_dma),
 			      caam_rng_done, &jctx);
 	if (err == -EINPROGRESS) {
 		wait_for_completion(done);
-- 
2.25.1

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Andrey Smirnov]

On Tue, Jan 11, 2022 at 4:41 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> From: Fabio Estevam <festevam@denx.de>
>
> Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance
> in HRWNG") the following CAAM errors can be seen on i.MX6:
>
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
>
> OP_ALG_PR_ON is enabled unconditionally, which may cause the problem
> on i.MX devices.

Is this true for every i.MX device? I haven't worked with the
i.MX6Q/i.MX8 hardware I was enabling this feature for in a while, so
I'm not 100% up to date on all of the problems we've seen with those,
but last time enabling prediction resistance didn't seem to cause any
issues besides a noticeable slowdown of random data generation.

Can this be a Kconfig option or maybe a runtime flag so that it'd
still be possible for some i.MX users to keep PR enabled?

>
> Fix the problem by only enabling OP_ALG_PR_ON on platforms that have
> Management Complex support.
>
> Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG")
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
>  drivers/crypto/caam/caamrng.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
> index 77d048dfe5d0..3514fe5de2a5 100644
> --- a/drivers/crypto/caam/caamrng.c
> +++ b/drivers/crypto/caam/caamrng.c
> @@ -63,12 +63,19 @@ static void caam_rng_done(struct device *jrdev, u32 *desc, u32 err,
>         complete(jctx->done);
>  }
>
> -static u32 *caam_init_desc(u32 *desc, dma_addr_t dst_dma)
> +static u32 *caam_init_desc(struct device *jrdev, u32 *desc, dma_addr_t dst_dma)
>  {
> +       struct caam_drv_private *priv = dev_get_drvdata(jrdev->parent);
> +
>         init_job_desc(desc, 0); /* + 1 cmd_sz */
>         /* Generate random bytes: + 1 cmd_sz */
> -       append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
> -                        OP_ALG_PR_ON);
> +
> +       if (priv->mc_en)
> +               append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
> +                                 OP_ALG_PR_ON);
> +       else
> +               append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG);
> +
>         /* Store bytes: + 1 cmd_sz + caam_ptr_sz  */
>         append_fifo_store(desc, dst_dma,
>                           CAAM_RNG_MAX_FIFO_STORE_SIZE, FIFOST_TYPE_RNGSTORE);
> @@ -101,7 +108,7 @@ static int caam_rng_read_one(struct device *jrdev,
>
>         init_completion(done);
>         err = caam_jr_enqueue(jrdev,
> -                             caam_init_desc(desc, dst_dma),
> +                             caam_init_desc(jrdev, desc, dst_dma),
>                               caam_rng_done, &jctx);
>         if (err == -EINPROGRESS) {
>                 wait_for_completion(done);
> --
> 2.25.1
>

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

Hi Andrey,

On Tue, Jan 11, 2022 at 3:21 PM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:

> Is this true for every i.MX device? I haven't worked with the

I do see the problem on i.MX6SX.

This thread reports the same problem on i.MX6D:
https://www.spinics.net/lists/linux-crypto/msg52319.html

> i.MX6Q/i.MX8 hardware I was enabling this feature for in a while, so
> I'm not 100% up to date on all of the problems we've seen with those,
> but last time enabling prediction resistance didn't seem to cause any
> issues besides a noticeable slowdown of random data generation.
>
> Can this be a Kconfig option or maybe a runtime flag so that it'd
> still be possible for some i.MX users to keep PR enabled?

The problem is that I don't know when it is safe or not to enable PR.

What about introducing a boolean devicetree property that when
present, disables prediction resistance?

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Andrey Smirnov]

On Tue, Jan 11, 2022 at 10:35 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Tue, Jan 11, 2022 at 3:21 PM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
>
> > Is this true for every i.MX device? I haven't worked with the
>
> I do see the problem on i.MX6SX.
>
> This thread reports the same problem on i.MX6D:
> https://www.spinics.net/lists/linux-crypto/msg52319.html
>
> > i.MX6Q/i.MX8 hardware I was enabling this feature for in a while, so
> > I'm not 100% up to date on all of the problems we've seen with those,
> > but last time enabling prediction resistance didn't seem to cause any
> > issues besides a noticeable slowdown of random data generation.
> >
> > Can this be a Kconfig option or maybe a runtime flag so that it'd
> > still be possible for some i.MX users to keep PR enabled?
>
> The problem is that I don't know when it is safe or not to enable PR.
>

Yeah, I hear you. It sounds like long term, we'll need some advice
from HW folks on this. I don't have any FAE contacts anymore, but
maybe you or Horia do have a venue to pursue this?

> What about introducing a boolean devicetree property that when
> present, disables prediction resistance?

That sounds fair.

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Herbert Xu]

On Tue, Jan 11, 2022 at 09:41:04AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance
> in HRWNG") the following CAAM errors can be seen on i.MX6:
> 
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> 
> OP_ALG_PR_ON is enabled unconditionally, which may cause the problem
> on i.MX devices.
> 
> Fix the problem by only enabling OP_ALG_PR_ON on platforms that have
> Management Complex support.
> 
> Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG")
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
>  drivers/crypto/caam/caamrng.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)

Patch 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

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Horia Geantă]

On 1/28/2022 8:23 AM, Herbert Xu wrote:
> On Tue, Jan 11, 2022 at 09:41:04AM -0300, Fabio Estevam wrote:
>> From: Fabio Estevam <festevam@denx.de>
>>
>> Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance
>> in HRWNG") the following CAAM errors can be seen on i.MX6:
>>
>> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
>> hwrng: no data available
>> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
>> hwrng: no data available
>> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
>> hwrng: no data available
>> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
>> hwrng: no data available
>>
>> OP_ALG_PR_ON is enabled unconditionally, which may cause the problem
>> on i.MX devices.
>>
What parts exactly?
Anything besides i.MX6 SX, S/DL?

>> Fix the problem by only enabling OP_ALG_PR_ON on platforms that have
>> Management Complex support.
>>
This limitation doesn't make any sense, it's too general.
Only a handful of Layerscape devices have MC, so all i.MX devices and
most LS devices will no longer have prediction resistance enabled.

>> Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG")
>> Signed-off-by: Fabio Estevam <festevam@denx.de>
>> ---
>>  drivers/crypto/caam/caamrng.c | 15 +++++++++++----
>>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> Patch applied.  Thanks.
We've been in contact with Fabio and we're working on a solution.
Now I realize the list hasn't been Cc-ed - sorry for the confusion
and for not providing an explicit Nack.

Herbert, could you please revert this patch?

It's doing more harm than good, since it's making the internal CAAM RNG
work like a DRBG / PRNG (instead of TRNG) while the driver registers
to hwrng as an entropy source.

Thanks,
Horia

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

Hi Horia,

On Fri, Jan 28, 2022 at 4:44 AM Horia Geantă <horia.geanta@nxp.com> wrote:

> What parts exactly?
> Anything besides i.MX6 SX, S/DL?

I see it on i.MX6SX, but in this report, it is mentioned i.MX6D:
https://www.spinics.net/lists/linux-crypto/msg52319.html

Lucas always saw it on i.MX6D:
https://linuxlists.cc/l/4/linux-crypto/t/3843436/caam_rng_trouble

> We've been in contact with Fabio and we're working on a solution.
> Now I realize the list hasn't been Cc-ed - sorry for the confusion
> and for not providing an explicit Nack.

Varun on Cc said he would work on a proper solution as he was able to
reproduce it.

Any progress, Varun?

Thanks

Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Herbert Xu]

On Fri, Jan 28, 2022 at 09:44:09AM +0200, Horia Geantă wrote:
>
> Herbert, could you please revert this patch?

OK I will revert this.

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] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

Hi Horia and Varun,

On Fri, Jan 28, 2022 at 4:44 AM Horia Geantă <horia.geanta@nxp.com> wrote:

> We've been in contact with Fabio and we're working on a solution.
> Now I realize the list hasn't been Cc-ed - sorry for the confusion
> and for not providing an explicit Nack.
>
> Herbert, could you please revert this patch?
>
> It's doing more harm than good, since it's making the internal CAAM RNG
> work like a DRBG / PRNG (instead of TRNG) while the driver registers
> to hwrng as an entropy source.

Any progress on the proper fix for this issue?

Thanks

RE: [EXT] Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Varun Sethi]

Hi Fabio,

> -----Original Message-----
> From: Fabio Estevam <festevam@gmail.com>
> Sent: Tuesday, March 22, 2022 6:50 PM
> To: Horia Geanta <horia.geanta@nxp.com>; Varun Sethi <V.Sethi@nxp.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>; Andrei Botila
> <andrei.botila@nxp.com>; andrew.smirnov@gmail.com;
> fredrik.yhlen@endian.se; hs@denx.de; linux-crypto@vger.kernel.org; Fabio
> Estevam <festevam@denx.de>
> Subject: [EXT] Re: [PATCH] crypto: caam - enable prediction resistance
> conditionally
> 
> Caution: EXT Email
> 
> Hi Horia and Varun,
> 
> On Fri, Jan 28, 2022 at 4:44 AM Horia Geantă <horia.geanta@nxp.com> wrote:
> 
> > We've been in contact with Fabio and we're working on a solution.
> > Now I realize the list hasn't been Cc-ed - sorry for the confusion and
> > for not providing an explicit Nack.
> >
> > Herbert, could you please revert this patch?
> >
> > It's doing more harm than good, since it's making the internal CAAM
> > RNG work like a DRBG / PRNG (instead of TRNG) while the driver
> > registers to hwrng as an entropy source.
> 
> Any progress on the proper fix for this issue?
> 
[Varun] Yes, we have made progress on the fix. Currently we are testing the fix and should be able to post the patch upstream pretty soon.
> Thanks

Regards
Varun

Re: [EXT] Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

Hi Varun,

On Tue, Mar 22, 2022 at 10:56 AM Varun Sethi <V.Sethi@nxp.com> wrote:

> [Varun] Yes, we have made progress on the fix. Currently we are testing the fix and should be able to post the patch upstream pretty soon.

Any progress on the fix?

Thanks

Re: [EXT] Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

Hi Varun,

On Thu, Apr 14, 2022 at 11:56 AM Varun Sethi <V.Sethi@nxp.com> wrote:
>
> Yes Fabio, we will be posting patch by next week.

Is the kernel patch that you plan to send along the lines of the
following U-Boot patch?
https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-gaurav.jain@nxp.com/

Thanks

Re: [EXT] Re: [PATCH] crypto: caam - enable prediction resistance conditionally

[Fabio Estevam]

Hi Varun,

On Sat, Apr 16, 2022 at 9:24 AM Fabio Estevam <festevam@gmail.com> wrote:

> Is the kernel patch that you plan to send along the lines of the
> following U-Boot patch?
> https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-gaurav.jain@nxp.com/

Following the U-Boot fix, the kernel patch would look like this:

--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -648,6 +648,8 @@ static int caam_probe(struct platform_device *pdev)
                        return ret;
        }

+       if (of_machine_is_compatible("fsl,imx6sx"))
+               ent_delay = 12000;

        /* Get configuration properties from device tree */
        /* First, get register page */
@@ -871,6 +873,8 @@ static int caam_probe(struct platform_device *pdev)
                         */
                        ret = instantiate_rng(dev, inst_handles,
                                              gen_sk);
+                       if (of_machine_is_compatible("fsl,imx6sx"))
+                               break;
                        if (ret == -EAGAIN)
                                /*
                                 * if here, the loop will rerun,

What do you think?