Re: [PATCH v4 00/19] crypto: talitos - Driver cleanup

Re: [PATCH v4 00/19] crypto: talitos - Driver cleanup

[Herbert Xu]

On Wed, Jul 22, 2026 at 10:53:44AM +0200, Paul Louvel wrote:
>
> Changes in v4:
> - The modification I did in v3 in PATCH 1 was incomplete. message_size
>   was not initialized in ahash_init(), and not incremented in
>   ahash_process_req().
> - Link to v3: https://patch.msgid.link/20260721-7-1-rc1_talitos_cleanup-v3-0-7c71a2b77c83@bootlin.com

Please check the Sashiko comments:

https://sashiko.dev/#/patchset/20260722-7-1-rc1_talitos_cleanup-v4-0-81d1ed2ad911%40bootlin.com

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v4 00/19] crypto: talitos - Driver cleanup

[Paul Louvel]

Hi Herbert,

On Thu Jul 30, 2026 at 9:18 AM CEST, Herbert Xu wrote:
> On Wed, Jul 22, 2026 at 10:53:44AM +0200, Paul Louvel wrote:
>>
>> Changes in v4:
>> - The modification I did in v3 in PATCH 1 was incomplete. message_size
>>   was not initialized in ahash_init(), and not incremented in
>>   ahash_process_req().
>> - Link to v3: https://patch.msgid.link/20260721-7-1-rc1_talitos_cleanup-v3-0-7c71a2b77c83@bootlin.com
>
> Please check the Sashiko comments:
>
> https://sashiko.dev/#/patchset/20260722-7-1-rc1_talitos_cleanup-v4-0-81d1ed2ad911%40bootlin.com
>
> Thanks,

Thanks for notifying, I tend to forget to check it if they are not automatically
send in my mailbox.

On the following remarks:

> Also regarding -EAGAIN, if talitos_submit() returns -EAGAIN to the generic 
> core, does the core handle it safely?
> Since we are now relying on CRYPTO_AHASH_ALG_BLOCK_ONLY, the generic core
> handles negative errors in ahash_update_finish(). If it sees an error like
> -EAGAIN, it clears the internal buffer length.
> Will this erase previously buffered partial blocks and silently corrupt the
> hash stream under high load?

This is a non-issue, because such error make the core abandon the current
request, right ?

> MD5 mandates little-endian padding length, and HMAC also requires the inner
> iPad length to be handled. Will this cause incorrect hash digests for 
> messages whose length is an exact multiple of the block size?

Agreeing on MD5, and indeed with MD5 hash digests for message whose length is an
exact multiple of the block size, the hash is wrong.

The comment on HMAC seems wrong to me. The hardware performs IPAD and OPAD
operations automatically on the key data when required.
After some testing, I also don't found any obvious issue.

-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com