| Message ID | 20220111124104.2379295-1-festevam@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: caam - enable prediction resistance conditionally | expand |
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 >
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?
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.
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.
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
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
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,
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
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
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
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
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?
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);