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
