Re: Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

[Paul Louvel <paul.louvel@bootlin.com>]

Hi,

> This flag is meant to be temporary in nature.
What does that mean ? The flag will be subject to changes in the near future ?

> Historically, crypto API hash drivers processed partial blocks at the
> end directly and the API played no role in it.
>
> This has resulted in complexities in the drivers and associated bugs.
I agree. I am currently working on the talitos crypto driver, which includes 
code to handle partial blocks. The SEC1 (currently supported by the talitos 
driver) is older hardware that only accepts data with a length that is a 
multiple of the underlying hashing algorithm's block size. Would it make sense 
for the crypto API to have a flag to handle such limitations automatically?

> The API is now able to handle partial blocks for the drivers and
> the flag is an indication of the driver's preference for it.
Understood.

> For a reference, see the aspeed driver which has been converted
> to the new way of handling partial block data.
Ok.

Thank you,

On 3/26/26 9:27 AM, Herbert Xu wrote:
>> On 3/20/26 10:42 AM, Paul Louvel wrote:
>>> Hello,
>>>
>>> I have stumbled across a flag defined in include/crypto/internal/hash.h
>>> : CRYPTO_AHASH_ALG_BLOCK_ONLY.
>>> To get more information about what exact behavior this flag do, I read
>>> the crypto_ahash_update function.
>>>  From the looks of it, it seems that the API will call the tfm update if
>>> there is enough bytes (and by enough I mean at least a block size), from
>>> the internal buffer and the incoming ahash_request.
>>> In this case, I find the BLOCK_ONLY naming a bit of a misnomer, since it
>>> only guarantee you than req->nbytes will be at least a block size.
>>> I initially though that the API would only give a request that are a
>>> multiple of the block size.
>>>
>>> This flag, among others, are relatively recent.
>>> I think adding documentation about these flags would be a great idea.
> This flag is meant to be temporary in nature.
>
> Historically, crypto API hash drivers processed partial blocks at the
> end directly and the API played no role in it.
>
> This has resulted in complexities in the drivers and associated bugs.
>
> The API is now able to handle partial blocks for the drivers and
> the flag is an indication of the driver's preference for it.
>
> For a reference, see the aspeed driver which has been converted
> to the new way of handling partial block data.
>
> Cheers,

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