CMAC fallback failures from SPAcc driver

CMAC fallback failures from SPAcc driver

[Pavitrakumar Managutte]

Hi Eric,
   While bringing up the SPAcc async ahash hardware driver against
7.3-rc1, cmac(aes) and xcbc(aes) fail their self-tests during TFM
allocation.

I did some digging and it looks like this is due to the missing
export_core/import_core functions in the cmac software
implementations. I see that all other hash algos have
export_core/import_core functions except cmacs. Is it intentional?

For cmac(aes)/xcbc(aes) it fails. In crypto/ahash.c,
crypto_ahash_init_tfm() allocates the fallback with:

    fb = crypto_alloc_ahash(name, CRYPTO_ALG_REQ_VIRT,
                       CRYPTO_ALG_ASYNC | CRYPTO_ALG_REQ_VIRT |
                       CRYPTO_AHASH_ALG_NO_EXPORT_CORE);

i.e. it requires a fallback that is synchronous, virtual-address
capable, and has NO_EXPORT_CORE clear.

On our tree no cmac(aes)/xcbc(aes) provider satisfies that: with both
CONFIG_CRYPTO_CMAC/XCBC=y and CONFIG_CRYPTO_LIB_AES_CBC_MACS=y,
neither the classic crypto/cmac.c template nor the new AES-CMAC
library shash implements export_core/import_core, so both report
NO_EXPORT_CORE. The allocation finds no fallback candidate and returns
-EINVAL:

  alg: hash: failed to allocate transform for spacc-cmac(aes): -22

BTW for SPAcc incremental(init/update/final) path, we always use the
software fallbacks since SPAcc hardware cannot export or import the
intermediate MAC state. Herbert suggested this.

Warm regards,
PK

Re: CMAC fallback failures from SPAcc driver

[Eric Biggers]

On Wed, Oct 07, 2026 at 02:51:00PM +0530, Pavitrakumar Managutte wrote:
> Hi Eric,
>    While bringing up the SPAcc async ahash hardware driver against
> 7.3-rc1, cmac(aes) and xcbc(aes) fail their self-tests during TFM
> allocation.
> 
> I did some digging and it looks like this is due to the missing
> export_core/import_core functions in the cmac software
> implementations. I see that all other hash algos have
> export_core/import_core functions except cmacs. Is it intentional?
> 
> For cmac(aes)/xcbc(aes) it fails. In crypto/ahash.c,
> crypto_ahash_init_tfm() allocates the fallback with:
> 
>     fb = crypto_alloc_ahash(name, CRYPTO_ALG_REQ_VIRT,
>                        CRYPTO_ALG_ASYNC | CRYPTO_ALG_REQ_VIRT |
>                        CRYPTO_AHASH_ALG_NO_EXPORT_CORE);
> 
> i.e. it requires a fallback that is synchronous, virtual-address
> capable, and has NO_EXPORT_CORE clear.
> 
> On our tree no cmac(aes)/xcbc(aes) provider satisfies that: with both
> CONFIG_CRYPTO_CMAC/XCBC=y and CONFIG_CRYPTO_LIB_AES_CBC_MACS=y,
> neither the classic crypto/cmac.c template nor the new AES-CMAC
> library shash implements export_core/import_core, so both report
> NO_EXPORT_CORE. The allocation finds no fallback candidate and returns
> -EINVAL:
> 
>   alg: hash: failed to allocate transform for spacc-cmac(aes): -22
> 
> BTW for SPAcc incremental(init/update/final) path, we always use the
> software fallbacks since SPAcc hardware cannot export or import the
> intermediate MAC state. Herbert suggested this.

In hash algorithms like "cmac-aes-lib" that XOR pending data into the
state, there's no meaningful concept of the "core" state.  So I do not
think cmac-aes-lib needs to be, or should, be changed.

crypto/cmac.c does buffer data separately from the state for some
reason.  So sure, you could update it to support exporting and importing
the "core" state.

But the whole concept of drivers calling into crypto_ahash recursively
is broken anyway, as is the "core" state thing.  A better way to
implement the fallback would be to just use the library functions.

Or just do not support this algorithm in the driver, as the CPU-based
implementation is almost always better than drivers like these anyway.

- Eric