[SOLVED] crypto-eip driver (not crypto-safexcel) crashed the kernel on MT7988A / BPI-R4

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

(Break out from the crypto-safexcel issue thread for better visibility)

To MediaTek and folks:

I compiled in crypto-eip driver for the EIP197 crypto engine in MT7988A / BPI-R4 on OpenWrt master branch (kernel 6.12).

Setup strongSwan for IKEv2 IPsec VPN. IKE crypto aes256-sha256-modp3072. ESP crypto aes128-sha1.

Kernal crashed with the error below when a remote client initiated a connection:

[  192.279376] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000604
[  192.568030] Call trace:
[  192.570470]  mtk_pce_netsys_rmw+0x10/0x40 [pce]
[  192.574997]  mtk_pce_cdrt_desc_write+0x50/0xbc [pce]
[  192.579957]  mtk_pce_cdrt_entry_write+0x14/0x24 [pce]
[  192.585004]  mtk_crypto_unregister_nf_hooks+0x118/0x1b0 [crypto_eip_inline]
[  192.591965]  mtk_xfrm_offload_state_add+0x208/0x374 [crypto_eip_inline]
[  192.598572]  xfrm_dev_state_add+0x13c/0x3b8
[  192.602754]  xfrm_add_sa+0x870/0x135c
[  192.606414]  xfrm_user_rcv_msg+0x108/0x23c
[  192.610506]  netlink_rcv_skb+0x5c/0x128
[  192.614337]  xfrm_netlink_rcv+0x34/0x48
[  192.618167]  netlink_unicast+0x22c/0x330
[  192.622084]  netlink_sendmsg+0x170/0x380
[  192.626001]  __sys_sendto+0xd8/0x140
[  192.629574]  __arm64_sys_sendto+0x24/0x30
[  192.633578]  invoke_syscall.constprop.0+0x4c/0xd0
[  192.638279]  do_el0_svc+0x3c/0xd0
[  192.641589]  el0_svc+0x18/0x60
[  192.644642]  el0t_64_sync_handler+0x118/0x124
[  192.648996]  el0t_64_sync+0x150/0x154
[  192.652658] Code: f0fff224 2a0003e0 f9406483 8b000063 (b9400063)

Let’s work out and fix the issue. Your patch commit comment stated that crypto-eip inline mode works for IPsec.

Cheers

2

Hi there,

Regarding your reported issue - here is a test of two BPI-R4s connected via sfp. Both BPIs are running the release from my GH https://github.com/woziwrt/bpi-r4-6.12.git

swanctl.conf

swanctl.conf

initialization

initialization
initialization1293Ă—281 125 KB

connection

connection

throughput

throughput

Cheers :beers: :raising_hand_man:

3

Hi wozi

Glad to get some feedback from folks.

However, I suspect your IPsec tunnel is using CPU acceleration.

On your “server side”, in children > net-1, for the “esp-proposal”, I think there should be a clause “hw_offload = packet” to offload the encryption/decryption to crypto-eip driver.

Cheers

4

Hi kvic,

In current relase is supported EIP197 look-aside mode acceleration, which does not require the XFRM framework. Therefore, there is no need to enable hw_offload=yes. Acceleration will already be enabled when hw_offload=no.

image011

Regards

5

Hi Wozi

Then your experiment and finding is not addressing the topic of this thread.

I’m interested in getting “inline mode” of crypto-eip driver to work but got the kernel panic.

Also “look-aside mode” of crypto-eip driver is not stable and disabled as per MediaTek.

Cheers

6

as far as i know cryptodev & /dev/crypto are out-of-tree & one needs to rely on AF_ALG

one will need to add the below GitHub - cryptodev-linux/cryptodev-linux: Cryptodev-linux is a Linux-kernel device that allows user-space access to hardware cryptographic accelerators.

7

I only compiled the safexcel driver after patching as module and had /dev/crypto. So far no out-of-tree driver is needed

8

let me know how you managed to have it showing up …

9

As i said before i only used the patches i mentiones above, changed to module and loaded it

10

I figured the problem of the kernel panic and got it fixed. Then while marching forward, run into a few other kerne panics. My original project goal was way too ambitious. I realised it’ll depend on

  • PCE driver
  • TOPS driver (which available codes are two years out of date; and MTK closed the source since)
  • unknown (mayabe) dependency on MTKHAT instead of mtk_ppe

So while was happy to figure out a fix, the project is put on back burner for now until situation improves.

1 Like