[BUG] crypto: shash – crypto_shash_export_core() fails with -ENOSYS after libcrypto updates merge

[BUG] crypto: shash – crypto_shash_export_core() fails with -ENOSYS after libcrypto updates merge

[Giovanni Cabiddu]

After commit 13150742b09e ("Merge tag 'libcrypto-updates-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux"),
crypto_shash_export_core() fails with -ENOSYS for all SHA algorithms
registered via shash.

The failure originates from shash_default_export_core(), which is now
being used as the default export function. However, this function is not
implemented, resulting in -ENOSYS.

Before the merge, SHA shash implementations were setting the
CRYPTO_AHASH_ALG_BLOCK_ONLY flag. This caused alg->export_core to be
assigned to alg->export, enabling proper state export. It seems the
removal of CRYPTO_AHASH_ALG_BLOCK_ONLY from the SHA implementations was
intentional, is this correct?

This issue breaks all aead implementations in the QAT driver, which
since commit ccafe2821cfa ("crypto: qat – Use crypto_shash_export_core")
rely on crypto_shash_export_core() to retrieve the initial state for
HMAC (i.e., H(K' xor opad) and H(K' xor ipad)).

It’s likely that the Chelsio driver is also affected, as it uses the
same API.

What is the recommended way to move forward?  Should the SHA
implementations reintroduce CRYPTO_AHASH_ALG_BLOCK_ONLY?  Should
shash_default_export_core() be properly implemented?  Should drivers
like QAT switch to using the software library directly to export the SHA
state?  Or is there another preferred approach?

Thanks,

-- 
Giovanni

Re: [BUG] crypto: shash – crypto_shash_export_core() fails with -ENOSYS after libcrypto updates merge

[Eric Biggers]

On Sun, Aug 31, 2025 at 08:48:25PM +0100, Giovanni Cabiddu wrote:
> Should drivers like QAT switch to using the software library directly
> to export the SHA state?

Yes, that's the correct solution.  I'll send patches for the qat and
chelsio drivers.

- Eric

Re: [BUG] crypto: shash – crypto_shash_export_core() fails with -ENOSYS after libcrypto updates merge

[Ovidiu Panait]

Hi,

On 8/31/25 10:48 PM, Giovanni Cabiddu wrote:
> After commit 13150742b09e ("Merge tag 'libcrypto-updates-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux"),
> crypto_shash_export_core() fails with -ENOSYS for all SHA algorithms
> registered via shash.
> 
> The failure originates from shash_default_export_core(), which is now
> being used as the default export function. However, this function is not
> implemented, resulting in -ENOSYS.
> 
> Before the merge, SHA shash implementations were setting the
> CRYPTO_AHASH_ALG_BLOCK_ONLY flag. This caused alg->export_core to be
> assigned to alg->export, enabling proper state export. It seems the
> removal of CRYPTO_AHASH_ALG_BLOCK_ONLY from the SHA implementations was
> intentional, is this correct?
> 
> This issue breaks all aead implementations in the QAT driver, which
> since commit ccafe2821cfa ("crypto: qat – Use crypto_shash_export_core")
> rely on crypto_shash_export_core() to retrieve the initial state for
> HMAC (i.e., H(K' xor opad) and H(K' xor ipad)).
> 
> It’s likely that the Chelsio driver is also affected, as it uses the
> same API.
> 

It seems that all legacy ahash drivers that set the
CRYPTO_ALG_NEED_FALLBACK flag are also affected.

I tested sha256 with the sun8i-ce driver and since commit e0cd37169103
("crypto: sha256 - Wrap library and add HMAC support"),
crypto_alloc_ahash("sha256-sun8i-ce", 0, 0) calls fail with -ENOSYS.

The issue seems to be that drivers that set the CRYPTO_ALG_NEED_FALLBACK
flag fail to allocate a fallback because now the sha256-lib shash
wrappers are marked as CRYPTO_AHASH_ALG_NO_EXPORT_CORE (because they
lack an import_core()/export_core() implementation), so they can no
longer be used as fallback.

In crypto/ahash.c, crypto_ahash_init_tfm() specifically asks for
fallbacks that do not have the CRYPTO_AHASH_ALG_NO_EXPORT_CORE flag set:

    if (crypto_ahash_need_fallback(hash)) {
        fb = crypto_alloc_ahash(crypto_ahash_alg_name(hash),
                                CRYPTO_ALG_REQ_VIRT,
                                CRYPTO_ALG_ASYNC |
                                CRYPTO_ALG_REQ_VIRT |
                                CRYPTO_AHASH_ALG_NO_EXPORT_CORE);
    ...

The import_core()/export_core() functionality seems to be used by the
ahash Crypto API to support CRYPTO_AHASH_ALG_BLOCK_ONLY drivers (such as
padlock and aspeed drivers, that make use of use
crypto_ahash_import_core()/crypto_ahash_export_core()). Unless it can be
reimplemented to use the software library directly, I think the shash
sha library wrappers need to implement import_core() and export_core()
hooks so that shaX-lib can be used again as fallback.

Thanks,
Ovidiu

> What is the recommended way to move forward?  Should the SHA
> implementations reintroduce CRYPTO_AHASH_ALG_BLOCK_ONLY?  Should
> shash_default_export_core() be properly implemented?  Should drivers
> like QAT switch to using the software library directly to export the SHA
> state?  Or is there another preferred approach?
> 
> Thanks,
> 

Re: [BUG] crypto: shash – crypto_shash_export_core() fails with -ENOSYS after libcrypto updates merge

[Eric Biggers]

On Mon, Sep 01, 2025 at 09:20:20AM +0300, Ovidiu Panait wrote:
> Hi,
> 
> On 8/31/25 10:48 PM, Giovanni Cabiddu wrote:
> > After commit 13150742b09e ("Merge tag 'libcrypto-updates-for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux"),
> > crypto_shash_export_core() fails with -ENOSYS for all SHA algorithms
> > registered via shash.
> > 
> > The failure originates from shash_default_export_core(), which is now
> > being used as the default export function. However, this function is not
> > implemented, resulting in -ENOSYS.
> > 
> > Before the merge, SHA shash implementations were setting the
> > CRYPTO_AHASH_ALG_BLOCK_ONLY flag. This caused alg->export_core to be
> > assigned to alg->export, enabling proper state export. It seems the
> > removal of CRYPTO_AHASH_ALG_BLOCK_ONLY from the SHA implementations was
> > intentional, is this correct?
> > 
> > This issue breaks all aead implementations in the QAT driver, which
> > since commit ccafe2821cfa ("crypto: qat – Use crypto_shash_export_core")
> > rely on crypto_shash_export_core() to retrieve the initial state for
> > HMAC (i.e., H(K' xor opad) and H(K' xor ipad)).
> > 
> > It’s likely that the Chelsio driver is also affected, as it uses the
> > same API.
> > 
> 
> It seems that all legacy ahash drivers that set the
> CRYPTO_ALG_NEED_FALLBACK flag are also affected.
> 
> I tested sha256 with the sun8i-ce driver and since commit e0cd37169103
> ("crypto: sha256 - Wrap library and add HMAC support"),
> crypto_alloc_ahash("sha256-sun8i-ce", 0, 0) calls fail with -ENOSYS.
> 
> The issue seems to be that drivers that set the CRYPTO_ALG_NEED_FALLBACK
> flag fail to allocate a fallback because now the sha256-lib shash
> wrappers are marked as CRYPTO_AHASH_ALG_NO_EXPORT_CORE (because they
> lack an import_core()/export_core() implementation), so they can no
> longer be used as fallback.
> 
> In crypto/ahash.c, crypto_ahash_init_tfm() specifically asks for
> fallbacks that do not have the CRYPTO_AHASH_ALG_NO_EXPORT_CORE flag set:
> 
>     if (crypto_ahash_need_fallback(hash)) {
>         fb = crypto_alloc_ahash(crypto_ahash_alg_name(hash),
>                                 CRYPTO_ALG_REQ_VIRT,
>                                 CRYPTO_ALG_ASYNC |
>                                 CRYPTO_ALG_REQ_VIRT |
>                                 CRYPTO_AHASH_ALG_NO_EXPORT_CORE);
>     ...
> 
> The import_core()/export_core() functionality seems to be used by the
> ahash Crypto API to support CRYPTO_AHASH_ALG_BLOCK_ONLY drivers (such as
> padlock and aspeed drivers, that make use of use
> crypto_ahash_import_core()/crypto_ahash_export_core()). Unless it can be
> reimplemented to use the software library directly, I think the shash
> sha library wrappers need to implement import_core() and export_core()
> hooks so that shaX-lib can be used again as fallback.
> 
> Thanks,
> Ovidiu

Hmm, that is annoying.  So the export_core and import_core methods
(which were added in 6.16) seems to have been fairly deeply baked into
the old-school crypto API already, even though they have no tests and
only four drivers actually call them.

For 6.17, maybe we should just go with a series that adds export_core
and import_core support to crypto/sha*.c for now?  I've sent that out.

For later, we should fix these legacy drivers to just use the library
APIs instead, then remove export_core and import_core.  I already sent
patches for qat and chelsio.  But it looks like the padlock and aspeed
drivers will need an update too.

- Eric