Gaurav Jain <gaurav.jain@xxxxxxx> writes: > Hi Eric > >> -----Original Message----- >> From: Eric Biggers <ebiggers@xxxxxxxxxx> >> Sent: Friday, September 22, 2023 8:11 AM >> To: Gaurav Jain <gaurav.jain@xxxxxxx> >> Cc: Horia Geanta <horia.geanta@xxxxxxx>; Pankaj Gupta >> <pankaj.gupta@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>; Meenakshi >> Aggarwal <meenakshi.aggarwal@xxxxxxx>; Herbert Xu >> <herbert@xxxxxxxxxxxxxxxxxxx>; David S . Miller <davem@xxxxxxxxxxxxx>; >> Aisheng Dong <aisheng.dong@xxxxxxx>; Silvano Di Ninno >> <silvano.dininno@xxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx; linux- >> kernel@xxxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx> >> Subject: [EXT] Re: [PATCH] crypto: caam/jr - fix Chacha20 + Poly1305 self test >> failure >> >> Caution: This is an external email. Please take care when clicking links or >> opening attachments. When in doubt, report the message using the 'Report this >> email' button >> >> >> On Thu, Sep 21, 2023 at 06:12:37PM +0530, Gaurav Jain wrote: >> > key buffer is not copied in chachapoly_setkey function, results in >> > wrong output for encryption/decryption operation. >> > >> > fix this by memcpy the key in caam_ctx key arrary Not sure, but do you mean array*? >> > >> > Fixes: d6bbd4eea243 ("crypto: caam/jr - add support for Chacha20 + >> > Poly1305") >> > Signed-off-by: Gaurav Jain <gaurav.jain@xxxxxxx> >> > --- >> > drivers/crypto/caam/caamalg.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/crypto/caam/caamalg.c >> > b/drivers/crypto/caam/caamalg.c index eba2d750c3b0..066f08a3a040 >> > 100644 >> > --- a/drivers/crypto/caam/caamalg.c >> > +++ b/drivers/crypto/caam/caamalg.c >> > @@ -575,7 +575,8 @@ static int chachapoly_setkey(struct crypto_aead *aead, >> const u8 *key, >> > if (keylen != CHACHA_KEY_SIZE + saltlen) >> > return -EINVAL; >> > >> > - ctx->cdata.key_virt = key; >> > + memcpy(ctx->key, key, keylen); >> > + ctx->cdata.key_virt = ctx->key; >> > ctx->cdata.keylen = keylen - saltlen; >> > >> >> Huh, so this driver just ignored the key? Is anyone using the ChaCha20Poly1305 >> support in this driver? Based on this bug existing, that seems unlikely. If that's >> the case, wouldn't it be better just to remove the ChaCha20Poly1305 support >> from this driver so that the code doesn't need to be maintained? > > This algorithm is used in IPSEC and we are also going to use ChaCha20Poly1305 support for Kernel TLS. > Gaurav Does this mean IPSEC doesn't call setkey() or the key value was such that it didn't affect even after failing to actually set the key? -Kamlesh