* Re: Data size error interrupt with Talitos driver on 4.9.82 kernel
[not found] <CANaw-r4i6qHXYNDFu5dZ4DsHedyPonk5N+-F9Mu4JvLRrD50sQ@mail.gmail.com>
@ 2019-08-26 6:57 ` Christophe Leroy
[not found] ` <CANaw-r59BwhwvHOLqtOjBJdrOzMbgENCG1a6QKKbwMOCLKVF2A@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Christophe Leroy @ 2019-08-26 6:57 UTC (permalink / raw)
To: Mukul Joshi, linux-crypto; +Cc: Kim Phillips
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Fwd: Data size error interrupt with Talitos driver on 4.9.82 kernel
[not found] ` <CANaw-r59BwhwvHOLqtOjBJdrOzMbgENCG1a6QKKbwMOCLKVF2A@mail.gmail.com>
@ 2019-08-27 14:05 ` Mukul Joshi
[not found] ` <CANaw-r6+H3+SsQ0pM4w0yqq7mL1mx2ef+gSMX=mFMatk6y7CSw@mail.gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Mukul Joshi @ 2019-08-27 14:05 UTC (permalink / raw)
To: linux-crypto
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@c-s.fr> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Fwd: Data size error interrupt with Talitos driver on 4.9.82 kernel
[not found] ` <CANaw-r6+H3+SsQ0pM4w0yqq7mL1mx2ef+gSMX=mFMatk6y7CSw@mail.gmail.com>
@ 2019-08-27 14:06 ` Mukul Joshi
0 siblings, 0 replies; 3+ messages in thread
From: Mukul Joshi @ 2019-08-27 14:06 UTC (permalink / raw)
To: linux-crypto
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@gmail.com> 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@c-s.fr> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-08-27 14:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CANaw-r4i6qHXYNDFu5dZ4DsHedyPonk5N+-F9Mu4JvLRrD50sQ@mail.gmail.com>
2019-08-26 6:57 ` Data size error interrupt with Talitos driver on 4.9.82 kernel Christophe Leroy
[not found] ` <CANaw-r59BwhwvHOLqtOjBJdrOzMbgENCG1a6QKKbwMOCLKVF2A@mail.gmail.com>
2019-08-27 14:05 ` Fwd: " Mukul Joshi
[not found] ` <CANaw-r6+H3+SsQ0pM4w0yqq7mL1mx2ef+gSMX=mFMatk6y7CSw@mail.gmail.com>
2019-08-27 14:06 ` Mukul Joshi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).