[PATCH] crypto/fsl: fsl_hash: Fix dcache issue in caam_hash_finish

[Horia Geantă]

On 5/11/2022 4:55 PM, Rasmus Villemoes wrote:
> On 11/05/2022 10.53, Gaurav Jain wrote:
>> HW accelerated hash operations are giving incorrect hash output.
>> so add flush and invalidate for input/output hash buffers.
>>
>> Fixes: 94e3c8c4fd (crypto/fsl - Add progressive hashing support using hardware acceleration.)
> 
> AFAICT, it takes somewhat more to fix that commit; the progressive
> hashing is entirely broken.
> 
> It doesn't actually do anything progressive, it just stashes the
> address/length pairs it is given, but doesn't feed the contents of those
> buffers to the hardware, folding it into the hash state. So the caller
Correct.

> must not touch the buffers it passes until the finalization. I.e. I
> think this won't work:
> 
>   char buf[SOMETHING];
> 
>   update_buffer(buf);
>   hash_update(buf, len);
>   update_buffer_again(buf);
>   hash_update(buf, len);
> 
Indeed, this won't work.

> And this pattern can be found in e.g. drivers/dfu/dfu.c which seems to
> repeatedly pass the same address (dfu->i_buf_start) to ->hash_update.
> 
At first glance, dfu asks for crc32 algorithm, so it won't use this backend.
But the concept is correct: user is not forced to keep a buffer unmodified
(or even allocated) after .hash_update returns.

Thanks,
Horia