On 02-01-2019 18:21, Herbert Xu wrote: > On Wed, Dec 26, 2018 at 03:16:29PM +0530, Harsh Jain wrote: >> +linux-crypto >> >> On 26-12-2018 14:54, Harsh Jain wrote: >>> Hi All, >>> >>> Kernel version on both machines: 4.19.7. >>> >>> Packet drops with EBADMSG is observed on receive end of connection. It seems that sometimes crypto driver receives packet with wrong "seq_hi" value in AAD. See below the dump of assoc data for 1 such instance. >>> >>> [ 380.823454] assoclen 8th byte 1 clen 1464 op 1 ==> High byte of ESN >>> [ 380.828398] authsize 12 cryptlen 1464 >>> [ 380.832637] dt00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 ==> Decrypted data seems correct,last byte is proto(06 TCP) >>> [ 380.840215] dt00000010: bf ee 4f 80 a4 7f 2a 50 6a 5a 0b 10 >>> [ 380.846636] ass00000000: 0a bc d3 31 <00 00 00 01> 00 1c e5 ec 0e af 04 69 ==> ESN-Hi = 1 >>> [ 380.854316] ass00000010: a4 fc 08 ad >>> >>> Note: If I decrypt the same packet with ESN - Hi = 0. It Decrypt successfully means peer machine has used ESN-HI = 0 while encrypting. >>> >>> To debug further we added trace in "xfrm_replay_seqhi". Following was the output: >>> >>> <idle>-0 [003] ..s. 380.967766: xfrm_replay_seqhi: seq_hi 0x 1 seq 0x 1ce5ec bottom 0x 1ce5ee replay seq 0x 1ce62d replay window 0x 40 >>> >>> 1) Is this an expected variable with ESN enables connection?. >>> >>> 2) If packets are supposed to be dropped can't we avoid decryption overhead. >>> >>> Following logs are attached >>> >>> 1) dmesg log >>> >>> 2) debug patch used to reproduce the issue. >>> >>> 3) ftace log file >>> >>> 4) ip xfrm state list > Does this occur if you use software crypto on the receiving end > while keeping the sending end unchanged? I tried with "authencesn(hmac(sha1-ssse3),cbc(aes-asm))" on both sides. Server : iperf -s -w 512k -p 20002 Client : iperf -t 60 -w 512k -l 2048 -c 1.0.0.96 -P 32 -p 20002 > > If not then I would start debugging this within your driver. ESP Packet whose's sequence No. is out of window gets dropped with EBADMSG. It seems that "xfrm_replay_seqhi" intentionally increments the "seq_hi" to fail verification for Out of seq packet. > > Thanks,
