[dpdk-dev] Behavior inconsistency in QAT PMD code

Trahe, Fiona fiona.trahe at intel.com
Wed Mar 10 18:47:10 CET 2021


Including Declan and Arek.

Hi Linfeng,

Thanks for raising this. I passed it on yesterday to the team, they are investigating.

Regards,
Fiona

From: Linfeng Li <linfli at qti.qualcomm.com>
Sent: Wednesday, March 10, 2021 5:38 PM
To: dev at dpdk.org
Cc: Griffin, John <john.griffin at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>; Jain, Deepak K <deepak.k.jain at intel.com>; Steve Rizor <srizor at qti.qualcomm.com>; Emil Meng <emeng at qti.qualcomm.com>
Subject: Behavior inconsistency in QAT PMD code


Hi,



We believe we found a behavior inconsistency based of different source mbuf layout in the QAT PMD code.



file link: https://github.com/DPDK/dpdk/blob/main/drivers/crypto/qat/qat_sym.c


The inconsistent behavior happens when:
*        symmetric operation
*        out-of-place operation
*        encryption
*        do cipher + not do hash
*        cipher offset is non-zero




inconsistent behavior:
*        scenario 1: When SGL is disabled; or when SGL is enabled, cipher offset is smaller than the length of the first segment of the src mbuf chain
o   behavior: In dst mbuf, characters loacted in cipher offset is not copied over from the src mbuf.



|||    data_len:2    ||| ---chained--->  |||    data_len:66    |||
src mbuf SGL:
seg 1: 2 bytes(cipher_offset)
seg 2:  payload

|||    data_len:2    ||| ---chained--->  |||    data_len:66    |||
dst mbuf SGL:
seg 1: 2 bytes copied over
seg 2:  ciphered payload


*        scenario 2: when SGL is enabled, cipher offset is larger than or equal to the length of the first segment of the src mbuf chain
o   behavior: In dst mbuf, characters loacted in cipher offset is copied over from the src mbuf.

|||    data_len:68    |||
src mbuf LB:
src: 2 bytes(cipher_offset) + payload in single mbuf


|||    data_len:2    ||| ---chained--->  |||    data_len:66    |||
dst mbuf SGL:
seg 1: 2 bytes untouched
seg 2:  ciphered payload

Actual packet data:
Src mbuf
0xcc 0x33,
0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11
0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d  0x1e 0x1f 0x20 0x21
0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31
0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41

dst mbuf: in LB, out SGL (scenario 1)
0x00 0x00
0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 0x76
0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb 0xbb
0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49  0xde 0x25
0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e 0x08

dst mbuf: in SGL, out SGL (scenario 2)
0xcc 0x33
0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 0x76
0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb 0xbb
0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49  0xde 0x25
0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e 0x08


For the actual use case, we have header information preceding the payload and the header should remain unencrypted in the dst mbuf. Therefore, we strongly believe that the second scenario is the desired behavior. There are cases where we do need to execute cipher only (which we can do today via a NULL hash).



To attest to that claim, we tested this scenario where we enable the authentication operation with everything else being the same:
*        symmetric operation
*        out-of-place operation
*        encryption
*        do cipher +  do hash
*        cipher offset is non-zero
*        auth offset is zero



The content in dst mbuf located in the cipher offset is copied over from src mbuf for both src mbuf layout.


Actual packet data:
Src mbuf

0xcc 0x33,

0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11

0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d  0x1e 0x1f 0x20 0x21

0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31

0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41



dst mbuf: Both in SGL, out SGL and in SGL, out SGL (both scenario 1 & 2)

0xcc 0x33

0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 0x76

0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb 0xbb

0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49  0xde 0x25

0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e 0x08

0x50 0xa0 0x9f 0x15



Please let us know what your thoughts are about this issue and feel free to contact us if there are any questions.

Linfeng



More information about the dev mailing list