Hi > -----Original Message----- > From: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > Sent: Thursday, January 4, 2024 2:07 PM > To: Gaurav Jain <gaurav.jain@xxxxxxx> > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Horia Geanta > <horia.geanta@xxxxxxx>; Pankaj Gupta <pankaj.gupta@xxxxxxx>; Linux Crypto > Mailing List <linux-crypto@xxxxxxxxxxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx> > 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@xxxxxxx> wrote: > > > > > > > > > -----Original Message----- > > > From: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > > > Sent: Saturday, December 23, 2023 7:29 PM > > > To: Gaurav Jain <gaurav.jain@xxxxxxx> > > > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Horia Geanta > > > <horia.geanta@xxxxxxx>; Pankaj Gupta <pankaj.gupta@xxxxxxx>; Linux > > > Crypto Mailing List <linux-crypto@xxxxxxxxxxxxxxx> > > > 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@xxxxxxx> 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.
