[EXT] [PATCH] crypto: fsl - Fix RNG generation for lengths greater than 16 bytes

[Paweł Kochanowski]

Hi,

> From: Horia Geanta <horia.geanta at nxp.com>
> Sent: Friday, April 11, 2025 2:29 PM
> 
> On 4/9/2025 7:46 PM, Horia Geanta wrote:
> > On 4/9/2025 9:19 AM, Gaurav Jain wrote:
> >> Hi Pawel
> >>
> >>> From: Paweł Kochanowski <pkochanowski at sii.pl>
> >>>
> >> 5. The loop in
> >>> caam_rng_read is called second time, this time the `priv->desc`
> >>> contain swapped data.
> >>>
> >>> Interesting thing is that the job still succeeds and that some data
> >>> are present in the buffers, but maybe swapped descriptor can also be a
> valid one?
> >> I agree that the descriptor should be reinitialized for each RNG job.
> > I would advise against this, considering what I said above.
> > Handling endianness should be done only once.
> >
> Btw, looks like there's another issue.
> 
> jr_enqueue() (drivers/crypto/fsl/jr.c) is touching the descriptor:
> 
>         for (i = 0; i < length; i++) {
>                 desc_word = desc_addr[i];
>                 sec_out32((uint32_t *)&desc_addr[i], desc_word);
>         }
> 
> however there's no cache flush after that.
> 
> This would affect platforms where CAAM is not HW-coherent.
> LS1046A has a coherent CAAM, so we're not hitting the bug in this case.
> 

I have sent a new patch with a hotfix for that: "[PATCH] crypto: fsl - Add cache flush after job descriptor swap".
I could only test on LS1046A though, please review if I missed something.

BR,
Pawel.

> Regards,
> Horia