Crypto-enabled Bluefield 2 but aes_gcm is unsupported

Infrastructure & Networking BlueField
1

Hi all,

We’re using MBF2H516A-EEEOT (linked specification below). However, when I checked the NIC capabilities using ./opt/mellanox/doca/tools/doca_caps, the output indicated that aes_gcm task_encrypt is unsupported.

Please let me know if I missed any configuration. Thank you!

https://docs.nvidia.com/networking/display/bluefield2dpuvpi/specifications#src-39258050_safe-id-U3BlY2lmaWNhdGlvbnMtTUJGMkg1MTZBLUVFTk9UL01CRjJINTE2QS1FRUVPVFNwZWNpZmljYXRpb25z

Screenshot 2024-05-20 at 10.40.47 PM
Screenshot 2024-05-20 at 10.40.47 PM866×732 20.7 KB

2

hi tmatuan96

Your card should support aes_gcm, could you please retry with last DOCA 2.7.0
As such feature still in alpha level, if 2.7.0 still have such issue, please contact us with networking-support@nvidia.com to get offical support

Thank you
Meng, Shi

3

Hi Meng Shi,

Well, I tried 3 versions of DOCA, and none works.

DOCA_1.5.2_BSP_3.9.6_Ubuntu_20.04-5.2306-LTS.prod.bfb
DOCA_2.6.0_BSP_4.6.0_Ubuntu_22.04-5.24-01.prod.bfb
bf-bundle-2.7.0-33_24.04_ubuntu-22.04_prod.bfb

Do I need to configure anything?
I’ll reach out to networking-support@nvidia.com.

Thanks for the help!

4

I literally have the identical issue with MBF2H332A-AECOT model

$ sudo mlxconfig -d /dev/mst/mt41686_pciconf0 q

Device #1:
----------

Device type:        BlueField2
Name:               MBF2H332A-AECO_Ax_Bx
Description:        BlueField-2 P-Series DPU 25GbE Dual-Port SFP56; PCIe Gen4 x8; Crypto and Secure Boot Enabled; 16GB on-board DDR; 1GbE OOB management; HHHL
Device:             /dev/mst/mt41686_pciconf0

The model is written as crypto and secure boot enabled, however when i query doca_caps it shows AES_GCM is not supported.

$ doca_caps
PCI: 0000:03:00.0
...
    aes_gcm
        task_encrypt                                  unsupported
        task_encrypt_get_max_iv_len                   0
        task_encrypt_tag_96                           unsupported
        task_encrypt_tag_128                          unsupported
        task_encrypt_128b_key                         unsupported
        task_encrypt_256b_key                         unsupported
        task_encrypt_max_buf_size                     0
        task_encrypt_max_list_buf_num_elem            0
        task_decrypt                                  unsupported
        task_decrypt_get_max_iv_len                   0
        task_decrypt_tag_96                           unsupported
        task_decrypt_tag_128                          unsupported
        task_decrypt_128b_key                         unsupported
        task_decrypt_256b_key                         unsupported
        task_decrypt_max_buf_size                     0
        task_decrypt_max_list_buf_num_elem            0
        max_num_tasks                                 65536

I also tried using https://doc.dpdk.org/guides-25.07/cryptodevs/mlx5.html this document to setup mlxreg value CRYPTO_OPERATIONAL, however it appears that it fails to get or set

$ sudo mlxreg -d /dev/mst/mt41686_pciconf0 --reg_name CRYPTO_OPERATIONAL --get
Sending access register...

-E- Failed to send access register: ME_ICMD_OPERATIONAL_ERROR

Any help or suggested method to try it out? I have tried 2.0.2, 2.9.2, and 3.1.0 all bfb images and doca version, however it results the same doca_caps problem.

Thanks in advance for your help.

5

The BF2 specs is misleading, the AES-GCM crypto hardware only supports IPsec. I believe the module is on NIC ASIC not ARM core.
Thus, DPDK/DOCA has no way to access it.

I tried the BF-3 and it actually works. They added a second crypto hardware module which is accessible to ARM cores, however, the API is designed in a bad way which makes it ill-suited for latency-critical networking (you can read more on DOCA AES-GCM page). For example, when you need to decrypt/encrypt packets with different keys.

It’s hard to understand why they didn’t add the crypto module on the die itself.

6

Thank you for your detailed clarification.

As you mentioned, I checked the BlueField-2 datasheet and confirmed that its “security” capabilities are limited to IPsec/TLS data-in-motion encryption, meaning it does not expose a general-purpose AES-GCM hardware module for arbitrary symmetric encryption.

In contrast, the BlueField-3 datasheet explicitly lists AES-GCM 128/256-bit key support, indicating that it includes a dedicated hardware module for AES-GCM operations.

Therefore, my goal of encrypting packets using a symmetric key (e.g., “abcd”) would not be feasible on BF2, but should be achievable on BF3.

Thanks again for the helpful explanation and confirmation, and this makes sense now (why DPDK could not access it in a separated manner)