On 04/04/25 15:53, Herbert Xu wrote: > Yes that's a common problem with crypto hash drivers that can't > deal with a zero-length final update. The best solution is to > use a fallback for the final update if it turns out to be zero-length > rather than retaining an extra block. Hashing a single block for > finalisation is simply not worth the overhead of setting up DMA and > what not. > > The other option is to use the fallback to hash the extra block in > the export function. > > Cheers, Although yes the hardware cannot process zero length input, the actual reason for doing this is to support the linux framework's init-update-final flow on the hardware. Our hardware can accept data as multiple packets, each of which can be of any length. The only restriction it has is that only the last packet can have arbitrary length, rest have to be a multiple of BLOCK_SIZE. The hardware needs a bit to be set to indicate that the packet to be submitted is the last data packet. Now, in the crypto framework, there is no way to know if a particular update call is the last update or if another update call will happen after that. Therefore I am unable to set that bit in any invocation of the update function. So I am retaining one block of data which is sent to hardware in the final function, a place where we know for sure that there is no more input coming now. Regards T Pratham <t-pratham@xxxxxx>
