CMAC fallback failures from SPAcc driver

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

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