RE: [EXT] caam test failures with libkcapi

[Gaurav Jain <gaurav.jain@nxp.com>]

Hi

> -----Original Message-----
> From: Ondrej Mosnacek <omosnace@redhat.com>
> Sent: Thursday, January 4, 2024 2:07 PM
> To: Gaurav Jain <gaurav.jain@nxp.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>; Horia Geanta
> <horia.geanta@nxp.com>; Pankaj Gupta <pankaj.gupta@nxp.com>; Linux Crypto
> Mailing List <linux-crypto@vger.kernel.org>; Varun Sethi <V.Sethi@nxp.com>
> Subject: Re: [EXT] caam test failures with libkcapi
> 
> 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 Wed, Jan 3, 2024 at 12:50 PM Gaurav Jain <gaurav.jain@nxp.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Ondrej Mosnacek <omosnace@redhat.com>
> > > Sent: Saturday, December 23, 2023 7:29 PM
> > > To: Gaurav Jain <gaurav.jain@nxp.com>
> > > Cc: Herbert Xu <herbert@gondor.apana.org.au>; Horia Geanta
> > > <horia.geanta@nxp.com>; Pankaj Gupta <pankaj.gupta@nxp.com>; Linux
> > > Crypto Mailing List <linux-crypto@vger.kernel.org>
> > > Subject: Re: [EXT] caam test failures with libkcapi
> > >
> > > 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 Fri, Dec 22, 2023 at 11:50 AM Gaurav Jain <gaurav.jain@nxp.com> wrote:
> [...]
> > > > Can you please share the logs for libkcapi test failures.
> > >
> > > A log from our kernel CI testing is available here (it is from
> > > CentOS Stream 9, but it fails in the same way on the Fedora's
> > > 6.6.6-based
> > > kernel):
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs3
> > > .amaz%2F&data=05%7C02%7Cgaurav.jain%40nxp.com%7Cb05dbbf9c0d848a
> f5bef
> > >
> 08dc0d006b59%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638399
> 5426
> > >
> 48069426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzI
> > >
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ykpF%2BM%
> 2BDWj
> > > w6GHN6165kLe7c8WFRJSSLTfWd%2FqLxI9w%3D&reserved=0
> > > onaws.com%2Farr-cki-prod-trusted-artifacts%2Ftrusted-
> > >
> artifacts%2F1109180874%2Ftest_aarch64%2F5766414724%2Fartifacts%2Frun
> > > .d
> > >
> one.03%2Fjob.01%2Frecipes%2F15194733%2Ftasks%2F31%2Flogs%2Ftaskout.l
> > >
> og&data=05%7C02%7Cgaurav.jain%40nxp.com%7C3b52a83449bf4b3fffe208dc
> > >
> 03bf4b66%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6383893673
> > >
> 38072709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > >
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9SCFiT
> > > 1nNsTZg4bh6n75CeicDC51Jw3wacQCaL7w4vQ%3D&reserved=0
> >
> > In this log I cannot see CAAM failures. can you tell which CAAM tfm failed?
> 
> The test exercises the kernel crypto API via the AF_ALG interface. The failures
> basically detect that for certain inputs the crypto API returns different results
> than expected when the CAAM driver is used (the machine in question has the
> relevant hardware, so the caam_jr crypto drivers are registered for certain
> algorithms and they take priority).
> 
> For example, when you install libkcapi-tools and run:
> 
> kcapi -x 2 -s  -e -c "gcm(aes)" -i 16c4b4bd1198f39f4ae817b7 \
>     -k 87c91a8b63f66934dd3703415b2538461fbfef55ce7a9ca9bb9425499f4cd1d6
> \
>     -a
> "303bb57e4534b08a4d5f001a84b3052c9d0d58ee03eda5211a540950e819dc" \
>     -p "b05fbd403c2fa41a8cc702a7474ed9ba6c50fcc6c19732a7d300f1113862bc"
> -l 4
> 
> ...the caam_jr implementation results in
> b05fbd403c2fa41a8cc702a7474ed9ba6c50fcc6c19732a7d300f1113862bc6d275
> 6d6,
> while the expected output is
> 9bea5263e7b365d5a06cb3ccab0d43cb9a1ca967dfb7b1a6955b3c493018af6d275
> 6d6.
> You can search the test log for "FAILED" to find the other failing commands (note
> that in some cases you need to escape the -c argument as it contains
> parentheses).

We have developed an application to run the gcm(aes) algorithm which is offloaded to caam_jr driver via AF_ALG interface.
we have used the below test vector
Plaintext is "b05fbd403c2fa41a8cc702a7474ed9ba6c50fcc6c19732a7d300f1113862bc" -> 31 byte
Key is "87c91a8b63f66934dd3703415b2538461fbfef55ce7a9ca9bb9425499f4cd1d6" -> 32 byte
Iv is "16c4b4bd1198f39f4ae817b7" -> 12 byte
Aad is "303bb57e4534b08a4d5f001a84b3052c9d0d58ee03eda5211a540950e819dc" -> 31 byte

Our application results matches the expected ciphertext which is "9bea5263e7b365d5a06cb3ccab0d43cb9a1ca967dfb7b1a6955b3c493018af6d2756d6".
I can see the expected output at your end is basically the plaintext appended by authentication tag of 4 bytes "6d2756d6".
caam_jr driver aes-gcm implementation is providing the correct output.

Regards
Gaurav Jain
> 
> --
> Ondrej Mosnacek
> Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.