Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

[Paul Louvel]

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.

Regards,
Paul.

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

Re: Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

[Paul Louvel]

Hello,

I forgot to include the maintainers in the initial e-mail.

Additional link to the source code :
https://elixir.bootlin.com/linux/v7.0-rc1/source/crypto/ahash.c#L467

Thank you,
Paul.

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.
>
> Regards,
> Paul.
>
-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

[Herbert Xu]

> 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,
-- 
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: Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

[Paul Louvel]

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

Re: Need some clarification about CRYPTO_AHASH_ALG_BLOCK_ONLY

[Herbert Xu]

On Thu, Mar 26, 2026 at 10:46:26AM +0100, Paul Louvel wrote:
>
> 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?

Yes it should be fairly easy to handle this if you use the BLOCK_ONLY
interface.  If you have a last partial block you could either feed
it to a software fallback, or manually generate the padding data
and feed it to the hardware with no finalisation.

The aspeed driver is an example using the second method to generate
the final block by hand.

Cheers,
-- 
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