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

[Eric Biggers <ebiggers@kernel.org>]

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