Hardware impacted:
- imx6qsabresd BSP Board (MCIMX6Q-SDB)
- imx6 Solo custom board
Linux kernel versions:
- imx_4.1.15_1.0.0_ga,
- imx_3.10.17_1.0.0_ga
- and probably all others
Description of the Problem:
Encryption of IPSEC ESP-packets coming from eth0 ("fec" driver) fails with CAAM when encryption algorithm is AES or AES256 on Linux platforms.
The sample test setup is as follow:
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
For different (good) reasons non of these workarounds are acceptable for us: we have a customer that needs to perform IPSEC AES encryption from eth0 to eth1. This issue seems to be present on all i.MX6 platforms.
Are there any workarounds other than the ones listed above for this issue ?
We can provide additional logging/configuration files/images if needed.
Attached is a short description of the IPSEC test-setup on the i.MX6 test board.
Original Attachment has been moved to: ipsec.sh
Original Attachment has been moved to: racoon.setkey.zip
Original Attachment has been moved to: racoon.conf.aes.zip
Original Attachment has been moved to: run-logs.tgz
Original Attachment has been moved to: setup.log.zip
Added as attachment ipsec.sh, racoon.setkey and racoon.conf.aes :
Additionaly, all files of the i.MX6 device are available on the sd-card bootable image referenced above.
Hi Hubert,
I have come close to replicating this issue. Please forward any configuration files you have and also the log of issues that you faced with accessing aes encryption using caam.
Thanks,
Utkarsh
root@imx6qsabresd:~# cat /etc/network/interfaces
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
auto lo
iface lo inet loopback
# Wired or wireless interfaces
auto eth0
iface eth0 inet static
address 10.1.1.1
netmask 255.255.255.0
network 10.1.1.0
auto eth1
iface eth1 inet static
address 192.168.3.77
netmask 255.255.255.0
network 192.168.3.0
gateway 192.168.3.1
https://extranet.garderos.com/files/?v=share/2B0D4DC9632B442A902AA1A482E34099
This URL is protected with a password: nxp-freescale
Hello,
Please try to check CAAM, using section 9 (Security) in "i.MX_Linux_User's_Guide.pdf".
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Yuri,
Thanks for your post. Unfortunately it does not help:
Chapter 9 of the "i.MX_Linux_User's_Guide.pdf" is related to the use of caam over cryptodev. cryptodev is the user-space interface to the Linux-Kernel cryptographic layers. In Linux, ESP-IPSEC encryption does not happen in user-space but only in kernel-mode. So cryptodev is not involved here.
Hubert
Hi Yuri,
Thanks for the link. You are right that the Scatter-API is involved here.
The Linux CAAM driver is actually intensively using the Linux scatter-list API.
The Linux CAAM driver is delivered by NXP/Freescale.
The problem is that this Linux CAAM driver that you deliver fails under some conditions.
I am not the programmer of the CAAM driver, I though Freescale/NXP was. If I could fix this driver I would do it, but without deep knowledge of the CAAM hardware and debugging facilities, it is just impossible. That 's why I did report this issue, with the hope that I can get help on this.
I am addressing a very specific issue that happens only under certain conditions. Let me rephrase it briefly.
In Linux with the CAAM driver, when an unencrypted packet gets switched from eth0 (FEC) to eth1 and it matches an outgoing IPSEC policy involving AES encryption, it then gets wrongly encrypted.
So this issue involves IPSEC with AES (i.e. CAAM Hardware/CAAM driver) _AND_ packet switching (i.e. FEC ethernet controller/FEC driver) simultaneously. If you just test IPSEC (with AES encryption) without packet switching over eth0, you will no be able to reproduce the problem.
As for cryptodev, I will underline once more that these test-conditions can _NOT_ be reproduced with any cryptodev stuff because, in Linux, ipsec is always processed in kernel-mode and cryptodev is not involved. The Linux IPSEC implementation forwards the buffers to encrypt directly to the CAAM driver.
I don't know any Linux ipsec implementation based on cryptodev. Therefore, I don't understand what you expect me to do with cryptodev and user-space APIs ?
Regards,
Hubert