On Tue, Apr 2, 2024 at 9:03 AM Gaurav Jain <gaurav.jain@xxxxxxx> wrote: > > 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. How does your application invoke AF_ALG exactly? The libkcapi test program invokes it in various different ways (to try to discover bugs) and only some of them fail. In this case the key seems to be to send the AAD and plaintext separately. This is what an strace of the failing invocation looks like: socket(AF_ALG, SOCK_SEQPACKET, 0) = 3 bind(3, {sa_family=AF_ALG, salg_type="aead", salg_feat=0, salg_mask=0, salg_name="gcm(aes)"}, 88) = 0 pipe2([4, 5], 0) = 0 fcntl(4, F_SETPIPE_SZ, 69632) = 131072 fcntl(5, F_SETPIPE_SZ, 69632) = 131072 setsockopt(3, SOL_ALG, ALG_SET_AEAD_AUTHSIZE, NULL, 4) = 0 setsockopt(3, SOL_ALG, ALG_SET_KEY, "\207\311\32\213c\366i4\3357\3A[%8F\37\277\357U\316z\234\251\273\224%I\237L\321\326", 32) = 0 accept(3, NULL, NULL) = 6 sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x3, cmsg_data="\x01\x00\x00\x00"}, {cmsg_len=32, cmsg_level=SOL_ALG, cmsg_type=0x2, cmsg_data="\x0c\x00\x00\x00\x16\xc4\xb4\xbd\x11\x98\xf3\x9f\x4a\xe8\x17\xb7"}, {cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x4, cmsg_data="\x1f\x00\x00\x00"}], msg_controllen=80, msg_flags=0}, MSG_MORE) = 0 vmsplice(5, [{iov_base="0;\265~E4\260\212M_\0\32\204\263\5,\235\rX\356\3\355\245!\32T\tP\350\31\334", iov_len=31}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 31 splice(4, NULL, 6, NULL, 31, SPLICE_F_MORE) = 31 vmsplice(5, [{iov_base="\260_\275@</\244\32\214\307\2\247GN\331\272lP\374\306\301\2272\247\323\0\361\218b\274", iov_len=31}], 1, SPLICE_F_GIFT) = 31 splice(4, NULL, 6, NULL, 31, 0) = 31 recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0", iov_len=1}, {iov_base=";", iov_len=1}, {iov_base="\265", iov_len=1}, {iov_base="~", iov_len=1}, {iov_base="E", iov_len=1}, {iov_base="4", iov_len=1}, {iov_base="\260", iov_len=1}, {iov_base="\212", iov_len=1}, {iov_base="M", iov_len=1}, {iov_base="_", iov_len=1}, {iov_base="\0", iov_len=1}, {iov_base="\32", iov_len=1}, {iov_base="\204", iov_len=1}, {iov_base="\263", iov_len=1}, {iov_base="\5,\235\rX\356\3\355\245!\32T\tP\350\31\334\233\352Rc\347\263e\325\240l\263\314\253\rC"..., iov_len=48}, {iov_base="m'V\326", iov_len=4}], msg_iovlen=16, msg_controllen=0, msg_flags=0}, 0) = 66 newfstatat(1, "", {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x12), ...}, AT_EMPTY_PATH) = 0 write(1, "9bea5263e7b365d5a06cb3ccab0d43cb"..., 71) = 71 close(6) = 0 close(4) = 0 close(5) = 0 close(3) = 0 (This is from a non-caam run on my machine, but the invocation should be the same, only the results differ.) -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
