Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: Data size error interrupt with Talitos driver on 4.9.82 kernel
To:     Mukul Joshi <mukuljoshi2011@gmail.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
References: <CANaw-r4i6qHXYNDFu5dZ4DsHedyPonk5N+-F9Mu4JvLRrD50sQ@mail.gmail.com>
From:   Christophe Leroy <christophe.leroy@c-s.fr>
Cc:     Kim Phillips <kim.phillips@arm.com>
Message-ID: <d20ab826-5a7a-e0e4-6591-4c7d4bdae5d8@c-s.fr>
Date:   Mon, 26 Aug 2019 08:57:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CANaw-r4i6qHXYNDFu5dZ4DsHedyPonk5N+-F9Mu4JvLRrD50sQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

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