[PATCH 09/15] crypto: zynqmp-aes-gcm: Fix setkey operation to select HW keys

[Jain, Harsh (AECG-SSW)]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Herbert Xu <herbert at gondor.apana.org.au>
> Sent: Thursday, November 6, 2025 10:03 AM
> To: Jain, Harsh (AECG-SSW) <h.jain at amd.com>
> Cc: davem at davemloft.net; linux-crypto at vger.kernel.org;
> devicetree at vger.kernel.org; robh at kernel.org; krzk+dt at kernel.org;
> conor+dt at kernel.org; Botcha, Mounika <Mounika.Botcha at amd.com>; Savitala,
> Sarat Chand <sarat.chand.savitala at amd.com>; Simek, Michal
> <michal.simek at amd.com>; linux-arm-kernel at lists.infradead.org; Buddhabhatti, Jay
> <jay.buddhabhatti at amd.com>
> Subject: Re: [PATCH 09/15] crypto: zynqmp-aes-gcm: Fix setkey operation to select
> HW keys
>
>
>
> On Wed, Oct 29, 2025 at 03:51:52PM +0530, Harsh Jain wrote:
> > Currently keylen 1 is used to select hw key. There are -ve self test
> > which can fail for setkey length 1. Update driver to use 4 bytes
> > with magic number to select H/W key type.
> >
> > Signed-off-by: Harsh Jain <h.jain at amd.com>
> > ---
> >  drivers/crypto/xilinx/zynqmp-aes-gcm.c | 94 ++++++++++++++++----------
> >  1 file changed, 60 insertions(+), 34 deletions(-)
>
> The hardware key support should be registered under the name paes
> instead of aes.  Grep for paes in drivers/crypto for examples.

Sure, Will check and update the driver accordingly.

>
> > @@ -218,32 +220,42 @@ static int zynqmp_aes_aead_setkey(struct
> crypto_aead *aead, const u8 *key,
> >                                 unsigned int keylen)
> >  {
> >       struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> > -     struct zynqmp_aead_tfm_ctx *tfm_ctx =
> > -                     (struct zynqmp_aead_tfm_ctx *)crypto_tfm_ctx(tfm);
> > +     struct zynqmp_aead_tfm_ctx *tfm_ctx = crypto_tfm_ctx(tfm);
> > +     struct xilinx_hwkey_info hwkey;
> >       unsigned char keysrc;
> > +     int err;
> >
> > -     if (keylen == ZYNQMP_KEY_SRC_SEL_KEY_LEN) {
> > -             keysrc = *key;
> > +     if (keylen == sizeof(struct xilinx_hwkey_info)) {
> > +             memcpy(&hwkey, key, sizeof(struct xilinx_hwkey_info));
> > +             if (hwkey.magic != XILINX_KEY_MAGIC)
> > +                     return -EINVAL;
> > +             keysrc = hwkey.type;
> >               if (keysrc == ZYNQMP_AES_KUP_KEY ||
> >                   keysrc == ZYNQMP_AES_DEV_KEY ||
> >                   keysrc == ZYNQMP_AES_PUF_KEY) {
> > -                     tfm_ctx->keysrc = (enum zynqmp_aead_keysrc)keysrc;
> > -             } else {
> > -                     tfm_ctx->keylen = keylen;
> > +                     tfm_ctx->keysrc = keysrc;
> > +                     tfm_ctx->keylen = sizeof(struct xilinx_hwkey_info);
> > +                     return 0;
> >               }
> > -     } else {
> > +             return -EINVAL;
> > +     }
> > +
> > +     if (keylen == ZYNQMP_AES_KEY_SIZE && tfm_ctx->keysrc ==
> ZYNQMP_AES_KUP_KEY) {
> >               tfm_ctx->keylen = keylen;
> > -             if (keylen == ZYNQMP_AES_KEY_SIZE) {
> > -                     tfm_ctx->keysrc = ZYNQMP_AES_KUP_KEY;
> > -                     memcpy(tfm_ctx->key, key, keylen);
> > -             }
> > +             memcpy(tfm_ctx->key, key, keylen);
> > +     } else if (tfm_ctx->keysrc != ZYNQMP_AES_KUP_KEY) {
> > +             return -EINVAL;
> >       }
> >
> >       tfm_ctx->fbk_cipher->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> >       tfm_ctx->fbk_cipher->base.crt_flags |= (aead->base.crt_flags &
> >                                       CRYPTO_TFM_REQ_MASK);
> >
> > -     return crypto_aead_setkey(tfm_ctx->fbk_cipher, key, keylen);
> > +     err = crypto_aead_setkey(tfm_ctx->fbk_cipher, key, keylen);
> > +     if (!err)
> > +             tfm_ctx->keylen = keylen;
>
> You can't have a fallback when there is a hardware key.  How did
> the fallback not return an error here?

We have two types of key registers
1) Registers to save user supplied keys like ZYNQMP_AES_KUP_KEY
2) Register Where H/W internally generates the keys like ZYNQMP_AES_DEV_KEY and ZYNQMP_AES_PUF_KEY

Fallback is for 1), because driver has saved key in private ctx and can be fallback to S/W.

>
> Cheers,
> --
> Email: Herbert Xu <herbert at gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt