Another thing I noticed is the difference in the cryptlen value between 4.9.82 kernel and 3.14.68 kernel. If I send a 500 byte ping, in aead_decrypt(), the value of req->cryptlen: 1. On the 4.9.82 kernel, value of req->cryptlen is 548 bytes. 2. However, on 3.14.68 kernel, it is 556 bytes. The same difference of 8 bytes is also seen with a normal 64 byte ping. Not sure if this points to something. I am still trying to figure out where is this filled and what could be causing this difference of 8 bytes. Thanks, Mukul On Mon, Aug 26, 2019 at 11:26 AM Mukul Joshi <mukuljoshi2011@xxxxxxxxx> wrote: > > Hi Christophe, > > Thanks for your email. > One thing I forgot to mention is that I am running a RT kernel, 4.9.82 with rt76 patches applied to it. > I am not sure if that can play any role in this issue. > > Yes, I have the crypto tests activated at boot time. All the ones that have their corresponding tests are passing. > There are a few for which I see "No test for ...." > [ 2.582100] alg: No test for authenc(hmac(sha224),cbc(aes)) (authenc-hmac-sha224-cbc-aes-talitos) > [ 2.584094] alg: No test for authenc(hmac(sha224),cbc(aes)) (authenc-hmac-sha224-cbc-aes-talitos) > [ 2.606097] alg: No test for authenc(hmac(md5),cbc(aes)) (authenc-hmac-md5-cbc-aes-talitos) > [ 2.608094] alg: No test for authenc(hmac(md5),cbc(aes)) (authenc-hmac-md5-cbc-aes-talitos) > [ 2.610077] alg: No test for authenc(hmac(md5),cbc(des3_ede)) (authenc-hmac-md5-cbc-3des-talitos) > [ 2.612076] alg: No test for authenc(hmac(md5),cbc(des3_ede)) (authenc-hmac-md5-cbc-3des-talitos) > [ 237.271903] alg: No test for echainiv(authenc(hmac(md5),cbc(des3_ede))) (echainiv(authenc-hmac-md5-cbc-3des-talitos)) > > I also dumped the CCPSR register and it indicates EU error: > [ 375.872689] talitos e0030000.crypto: Ch: 2, CCPSR 0x01000007_023c0104 > [ 375.872708] talitos e0030000.crypto: DEUISR 0x00000000_00000100 > [ 375.872719] talitos e0030000.crypto: DEUDSR 0x00000000_00000320 > [ 375.872730] talitos e0030000.crypto: DEURCR 0x00000000_00000000 > [ 375.872741] talitos e0030000.crypto: DEUSR 0x00000000_00000025 > [ 375.872752] talitos e0030000.crypto: DEUICR 0x00000000_00003000 > [ 375.872763] talitos e0030000.crypto: DEUMR 0x00000000_00000006 > [ 375.872775] talitos e0030000.crypto: DEUKSR 0x00000000_00000018 > [ 375.872786] talitos e0030000.crypto: MDEUISR 0x00000000_00000000 > [ 375.872797] talitos e0030000.crypto: DESCBUF 0x20635e0b_00000000 > [ 375.872808] talitos e0030000.crypto: DESCBUF 0x00100000_0cc74d3c > [ 375.872819] talitos e0030000.crypto: DESCBUF 0x00100000_1d0355a6 > [ 375.872831] talitos e0030000.crypto: DESCBUF 0x00080000_12a80b80 > [ 375.872842] talitos e0030000.crypto: DESCBUF 0x00180000_0cc74d4c > [ 375.872853] talitos e0030000.crypto: DESCBUF 0x00640000_1d0355b6 > [ 375.872864] talitos e0030000.crypto: DESCBUF 0x00580c00_1d0355b6 > [ 375.872875] talitos e0030000.crypto: DESCBUF 0x00080000_0cc74ddc > > I do not have FIPS enabled. > > The same hardware running 3.14.68 kernel does not have any issues with IPsec/talitos driver and I can see pings going through. > Obviously, the talitos driver has evolved after 3.14.68 version. > > I have plans to move to 4.9.190 but it will involve some effort since I would have to port a lot of other stuff which I have working on 4.9.82. > Sorry but I would prefer to stick to 4.9.82 for now and try and debug this issue unless I know a similar/same issue was fixed after 4.9.82. > If there are no clues to this issue, then I may have to try and move to 4.9.190 version. > > Are you aware of some changes that went in after 4.9.82 that could cause this issue to go away? > Who is responsible for writing the data size in the EU Data size register and what could cause it to be written with a value which is not a multiple of 64-bits? > > Any other pointers on debugging this while still remaining on 4.9.82 kernel? > > Thanks, > Mukul > > > > > > > On Mon, Aug 26, 2019 at 2:57 AM Christophe Leroy <christophe.leroy@xxxxxx> wrote: >> >> Hi Mukul >> >> Le 24/08/2019 à 18:40, Mukul Joshi a écrit : >> > Hi Christophe, >> >> [...] >> >> > >> > I am working with MPC8360E SoC and trying to setup IPSEC tunnel between >> > 2 hosts. >> > I am able to setup the tunnel but I am seeing issues with packet >> > decryption. The sender side doesn't seem to have a problem and the >> > packet is also being encrypted by the EU. >> > >> > Upon reception of packet, I am seeing Data size error interrupt go up in >> > the Interrupt status register of the EU. >> > I see the problem with both AES and 3DES algos. >> > >> > Here are the logs that I see in dmesg: >> > AES: >> > [ 832.041102] talitos e0030000.crypto: AESUISR *0x00000000_00000100* >> > [ 832.041120] talitos e0030000.crypto: MDEUISR 0x00000000_00000000 >> > [ 832.041131] talitos e0030000.crypto: DESCBUF 0x60235c0b_00000000 >> > [ 832.041142] talitos e0030000.crypto: DESCBUF 0x00140000_0c8d353c >> > [ 832.041154] talitos e0030000.crypto: DESCBUF 0x00180000_12f57920 >> > [ 832.041165] talitos e0030000.crypto: DESCBUF 0x00100000_144e3e40 >> > [ 832.041176] talitos e0030000.crypto: DESCBUF 0x00100000_0c8d3550 >> > [ 832.041188] talitos e0030000.crypto: DESCBUF 0x006c0000_12f57938 >> > [ 832.041199] talitos e0030000.crypto: DESCBUF 0x00600c00_12f57938 >> > [ 832.041210] talitos e0030000.crypto: DESCBUF 0x00100000_0c8d35dc >> > >> > 3DES: >> > [ 313.635521] talitos e0030000.crypto: DEUISR *0x00000000_00000100* >> > [ 313.635539] talitos e0030000.crypto: DEUDSR *0x00000000_00000320* >> > [ 313.635549] talitos e0030000.crypto: DEURCR 0x00000000_00000000 >> > [ 313.635560] talitos e0030000.crypto: DEUSR 0x00000000_00000025 >> > [ 313.635572] talitos e0030000.crypto: DEUICR 0x00000000_00003000 >> > [ 313.635583] talitos e0030000.crypto: MDEUISR 0x00000000_00000000 >> > [ 313.635594] talitos e0030000.crypto: DESCBUF 0x20635e0b_00000000 >> > [ 313.635605] talitos e0030000.crypto: DESCBUF 0x00100000_1abbc03c >> > [ 313.635617] talitos e0030000.crypto: DESCBUF 0x00100000_1ef2f226 >> > [ 313.635628] talitos e0030000.crypto: DESCBUF 0x00080000_1abbdc80 >> > [ 313.635639] talitos e0030000.crypto: DESCBUF 0x00180000_1abbc04c >> > [ 313.635650] talitos e0030000.crypto: DESCBUF 0x00640000_1ef2f236 >> > [ 313.635726] talitos e0030000.crypto: DESCBUF 0x00580c00_1ef2f236 >> > [ 313.635738] talitos e0030000.crypto: DESCBUF 0x00080000_1abbc0dc >> > >> > I was able to dump the data size register value for DES and it shows a >> > value of 0x320 in LO word. >> > This shows that the Data size for decryption is not 64-bit multiple >> > which causes the Data size error interrupt to go up but I don't know how >> > this value gets written and why is the value as 0x320 when the the >> > tcpdump on the receive side shows a packet size of 112 bytes of >> > encrypted packets received. >> >> Yes that's strange. The pointers in the descriptors dumped above all >> have valid size. The input data has size 0x64 ie 100 bytes, and the >> output data has size 88 + 12 bytes HMAC out. >> >> Have you activated crypto tests at boot time ? Do they all pass ? >> >> Can you have a look at CCPSR register ? >> >> > >> > Can you please give me a few pointers about what could be causing this >> > issue and where else can I look further. >> >> Can you try with kernel 4.9.190 ? >> >> Have you tried with a newer LTS kernel, for instance 4.14.x or 4.19.x ? >> >> Christophe
