LX2160 SEC engine return error when using DPDK cryptodev library

[Sean_Yuan]

Dear NXP Team,

Our application are using DPDK cryptodev library to do ciphering & auth on LS2160A and found the following issue.

When calling the dpdk rte_cryptodev_enqueue_burst function with some specific length of mbuf data (eg.  data_len=88,data_len=152,data_len=168,data_len=342) and specific algorithm, the SEC engine report "SEC returned Error . 4000221C".

Do you have any similiar issues like this?

Is there any advice to solve this issue?

The configure for call rte_security_session_create as blow:

1.auth_xform.auth.algo is RTE_CRYPTO_AUTH_AES_CMAC，

2.cipher_xform.cipher.algo is RTE_CRYPTO_CIPHER_AES_CTR，

3.{.pdcp = {

                                 .bearer =4,

                                 .domain = RTE_SECURITY_PDCP_MODE_DATA,

                                 .pkt_dir = RTE_SECURITY_PDCP_UPLINK,

                                 .sn_size = 18,

                                 .hfn = 0,

                                 .hfn_ovrd = 1,

                                 .hfn_threshold = 16383,

                                 .sdap_enabled = 1,   

                             } },

4. cipher_xform.next = &dpdk_ctx_p->auth_xform chain  ciphering&auth enable

We did a lot test with different algorithms and different data lengths and only found this issue with this algorithm and these data_len(88/152/68/342). Other algorithm can work well with these data lentgh too.

We also modify the dpdk cryptodev_dpaa2_sec_testsuite test data to simulate the scenario. The cryptodev_dpaa2_sec_testsuite also report the same error.

Regards,

Sean

[yipingwang]

Please refer to the following update from the AE team.

I see this is pdcp packet flow, right?
1. Can customer confirm which dpaa2_sec* function is called? is this one dpaa2_sec_aead_chain_init() --> dpaa2_sec_aead_chain_init()?
If they can share us their dpaa2 sec session create flow, this is helpful to analyze the issue.
2. Can customer dump their sec descriptor under problematic case and share to us?

[Sean_Yuan]

@yipingwang 

Yes, this is 5GNR pdcp packet flow.

1. Can customer confirm which dpaa2_sec* function is called? is this one dpaa2_sec_aead_chain_init() --> dpaa2_sec_aead_chain_init()?

       ---- Yes, accoding to our configuration, dpaa2_sec_aead_chain_init should be called.

If they can share us their dpaa2 sec session create flow, this is helpful to analyze the issue.

       --- We can reproduce the issue with the DPDK test example(cryptodev_dpaa2_sec_testsuite) by constructing similar data length condition.  Please see the attachment file dpdk_pdcp_sdap_testcase_diff.patch. We are using LSDK 20.04 and dpdk version (LSDK20.04-isc-09 patch), MC binary version(10.30.0). 
2. Can customer dump their sec descriptor under problematic case and share to us?

       --- Can you provide the method or information on how to dump the sec descriptor? 

[yipingwang]

You can dump descriptor inside dpaa2_sec_aead_chain_init(), after cnstr_shdsc_authenc().
Dump priv->flc_desc[0].desc with bufsize * 4 bytes length.

[Sean_Yuan]

After checking the call trace, i found the dpaa2_sec_aead_chain_init was not called. Here is the call trace i got with the cryptodev_dpaa2_sec_autotest testsuite.

rte_security_session_create --> dpaa2_sec_security_session_create --> dpaa2_sec_set_pdcp_session

I dumped the descriptor inside the dpaa2_sec_set_pdcp_session function. Here is the log i got.

dpaa2_sec: DESC[0]:0xb885012d
dpaa2_sec: DESC[1]:0x6
dpaa2_sec: DESC[2]:0x0
dpaa2_sec: DESC[3]:0x20000000
dpaa2_sec: DESC[4]:0x95600000
dpaa2_sec: DESC[5]:0xac574f08
dpaa2_sec: DESC[6]:0x80000000
dpaa2_sec: DESC[7]:0xa0000404
dpaa2_sec: DESC[8]:0xe8770124
dpaa2_sec: DESC[9]:0xa8900008
dpaa2_sec: DESC[10]:0x78430804
dpaa2_sec: DESC[11]:0x1e080404
dpaa2_sec: DESC[12]:0xa1001001
dpaa2_sec: DESC[13]:0xe8701088
dpaa2_sec: DESC[14]:0xac514108
dpaa2_sec: DESC[15]:0xffff0300
dpaa2_sec: DESC[16]:0xa8911108
dpaa2_sec: DESC[17]:0x39360808
dpaa2_sec: DESC[18]:0xa8412208
dpaa2_sec: DESC[19]:0x5e080404
dpaa2_sec: DESC[20]:0x38601008
dpaa2_sec: DESC[21]:0x38610008
dpaa2_sec: DESC[22]:0xa828fa04
dpaa2_sec: DESC[23]:0xa8284b04
dpaa2_sec: DESC[24]:0x4
dpaa2_sec: DESC[25]:0x2000010
dpaa2_sec: DESC[26]:0x742d0200
dpaa2_sec: DESC[27]:0x1
dpaa2_sec: DESC[28]:0x69b00000
dpaa2_sec: DESC[29]:0x8210000c
dpaa2_sec: DESC[30]:0x2b130000
dpaa2_sec: DESC[31]:0x38270004
dpaa2_sec: DESC[32]:0x10880004
dpaa2_sec: DESC[33]:0x2000006d
dpaa2_sec: DESC[34]:0x2000010
dpaa2_sec: DESC[35]:0x742d0140
dpaa2_sec: DESC[36]:0x1
dpaa2_sec: DESC[37]:0xf0080000
dpaa2_sec: DESC[38]:0x8210060e
dpaa2_sec: DESC[39]:0xa828fa04
dpaa2_sec: DESC[40]:0x78180008
dpaa2_sec: DESC[41]:0x2b130000
dpaa2_sec: DESC[42]:0x10f00004
dpaa2_sec: DESC[43]:0x54a04004
dpaa2_sec: DESC[44]:0x387f0004
PMD: SEC returned Error - 4000221c
TestCase test_pdcp_proto()-18 line 9505 failed failed to process sym crypto op: 19) [bad case] PDCP-SDAP Uplane: 12b SN, AES-CTR_ENC and AES-CMAC_AUTH Uplink: Decapsulation failed

[yipingwang · Accepted solution]

The issue has been resolved in latest LSDK20.04-isc-18.
https://github.com/NXP/dpdk/commit/4b1fe45fa135613854c318a76871ec1a8c5f03a8

I attach patch for both PDCP with/without SDAP.

[Sean_Yuan]

Thanks for your information.

I tried with the dpdk LSDK20.04-isc-18 version. The issue have been fixed.