Is Crypto Engine enabled in witi firmware?

[stas2z]

@nitroshift
i'm not sure it will be accepted, ported drivers are not under GPL, it's a proprietary closed source driver and mediatek guys will be angry

[freespirit]

angry

Ok, they won't be able to be merged into OpenWRT trunk, but at least I hope that MQMaker can release them as binary modules for their Witi firmware, even though as far as stas2z told us the module in its current form is just an IPSec accelerator (aes_engine probably won't work on MT7621). If you look at the EIP-93 packet engine documentation (http://www.design-reuse.com/sip/inside-secure-safexcel-ip-93-security-packet-engine-ip-17526/ and http://www.insidesecure.com/content/download/2376/16899/version/1/file/SafeXcel%2BIP%2BLow%2BGate%2BCount%2BInline%2BPacket%2BEngine%2B%28EIP-93%29-2.pdf) it's an advanced crypto engine which does not only speed up basic operation like encryption and hashing, but is also able of speeding up network protocols like IPSec & SSL by feeding directly into it unencrypted/encrypted data. This is the general way it works:

The Packet Engine supports an autonomous ring mode
operation that minimizes the security processing load on
the host system, thereby maximizing system performance.
In this mode, the Packet Engine reads and writes data
and control information (packet data, packet descriptors,
security association information) from host memory
through DMA, without intervention by the host processor.
The information is stored in entries of ring data structures,
which are processed by the Packet Engine and the host
system independently (asynchronously). Status bits in the
ring buffer entries ensure proper interaction between the
Packet Engine and the host processor. The built-in 32-bit
DMA controller supports four DMA channels, and bytealigned
addressing. Packet data is buffered in dual-port
input and output FIFOs, enabling simultaneous reading,
writing, and processing of packets.

I have given a quick look at the code and it seems that the driver just intercepts IPSec esp packet and redirects it to the crypto engine, but there seems not to be present any support for /dev/crypto device which as far as I know is the standard way used by linux applications to interact with hw crypto engines. Unluckily there is no documentation about how to tell the packet engine to encrypt/sign some data and build a /dev/crypto wrapper (maybe by faking an esp payload), so for now it seems to be only useful to speedup IPSec (not even SSL)

[build000]

Exactly the same observation as in the previous speaker - how to use in practice of the allegedly added functionality (no /dev/crypto) ?

[freespirit]

Well three possibilities:
1) Get EIP93 Programmer's manual and implement it
2) Ask Mediatek to implement it in their SDK (they should have the manual at point 1)
3) Reverse engineer existing driver source code in order to understand how the ring data structures works and implement it, but probably you won't go anywhere.

[freespirit]

Hi any update ?

[freespirit]

Just make a new build, load the new driver cryptodriver with insmod and it will automatically speedup all ipsec traffic. Obviously you need to connect to an ipsec vpn to perform some testing....however we are still waiting for a working build to test

[Sugar]

I just get the mt7628 linux-2.6 source code, and update cryptodev directory to our
linux repo.

But, I found it have many different. And it is fail to compile

@freespirit

[freespirit]

different

I have downloaded the sources from github, but I can't find anywhere in menuconfig neither aesengine nor cryptoengine. As stas2z replied probably some OpenWRT scripts needs to be changed in order to make these two new modules appear in menuconfig

[maurer]

you'll find it in "make kernel_menuconfig"

[freespirit]

Ok, can you release a working firmware for us to test ?

[freespirit]

An update...Crypto Engine module has been rebuilt for latest openwrt 4.3 kernel, however it is still unusable for the previous explained reasons...ipsec integration has been obviously removed, it just loads the module and does nothing, there is an irq issue to investigate, module unload crashes...however I have been able to dump at least its capabilities, it supports also SSL/TLS so it could even speed up OpenVPN, but probably we'll never have it without any official documentation if you want to try ( https://file.io/iGhYrw ) remember to update your witi to latest openwrt firmware ( https://downloads.openwrt.org/snapshots/trunk/ramips/mt7621/openwrt-ramips-mt7621-witi-squashfs-sysupgrade.bin )

root@OpenWrt:/# insmod mtk-crypto-eng.ko
[ 107.310000] mtk_crypto_eng: module license 'Proprietary' taints kernel.
[ 107.330000] Disabling lock debugging due to kernel taint
[ 107.340000] HWPAL_Device_Find: Returned 8e9647ac for device eip93
[ 107.350000] MTKHWCrypto: before write32
[ 107.360000] MTKHWCrypto: after write32
[ 107.370000] Setting interrupt handler irq 19
[ 107.380000] Adapter_Interrupts_Init: request_irq fails, returned -89
[ 107.390000] Adapter_EIP93_Init: CmdRing_Handle=8f29dffc
[ 107.400000] Adapter_EIP93_Init: ResRing_Handle=8f29dff8
[ 107.410000] Adapter: Successfully initialized EIP93v2 in ARM mode
[ 107.420000] PEC_Init: Dumping Capabilities
DES 1
ARC4 1
AES 1
AES128 1
AES192 1
AES256 1
Kasumi 0
CFB1-64 0
CFB1-128 0
MD5 1
SHA1 1
SHA2-224 1
SHA2-256 1
SHA2-384 0
SHA2-512 0
Kasumi 0
AES-XCBC 0
GCM 0
GMAC 0
AESCBCMAC 0
AESCBCMAC-128 0
AESCBCMAC-192 0
AESCBCMAC-256 0
IntFace 1
64bit 0
ExtInt 0
PRng 1
SARev1 1
SARev2 0
Dynamics 0
ESN 0
IPSEC ESP 1
IPSEC AH 0
SSL 1
TLS 1
DTLS 1
SRTP 1
MACSec 0
EipNumber 93
CEipNumber 162
HWPatch 1
MinRev 0
MaxRev 3
[EIP93_ARM_Level0_WriteDescriptor]
[ 107.510000] ControlWord:0x00000041
[ 107.520000] 0-byte Src packet from 0x (null):
[ 107.530000]
[ 107.530000] Dst packet Addr:0x00000000
[ 107.540000]
[ 107.540000] 128-byte SA Content from 0xae860000:
[ 107.550000] 0x00001307 0x02000000 0xe0fc631d 0xcbb9fb9a 0x869285cb
[ 107.560000] 0xcbb9fb9a 0x00000000 0x00000000 0x00000000 0x00000000
[ 107.580000] 0x758bac03 0xf20ab39e 0xa569f104 0x95dfaea6 0x00000000
[ 107.590000] 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
[ 107.600000] 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
[ 107.610000] 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
[ 107.630000] 0x00000000 0x00000000
[ 107.630000] 56-byte SAState Content from 0xa0000000:
[ 107.640000] 0x00000000 0x00ff0000 0xff000000 0xf7ff0800 0x00000800
[ 107.660000] 0x00ff0000 0xff200020 0xffff0020 0x00000000 0x00ff0000
[ 107.670000] 0xef000000 0xefff1000 0x00000000 0x00bf0000
[ 107.680000] SAARC4 Content from 0xa0000000:
[ 107.690000]
[ 107.690000]
[ 107.690000] PE_userID:0x00000000
[ 107.700000]
[ 107.700000] PE_length:0x00400000
[ 107.710000]
[ 107.710000] [EIP93_WriteCB], CD_BASE:0xae968000 (B4 kcik PE):
[ 107.720000] CD_Control:0x00000041
[ 107.730000] CD_SrcPktAddr:0x00000000
[ 107.740000] CD_DstPktAddr:0x00000000
[ 107.740000] CD_SADataAddr:0x0e860000
[ 107.750000] CD_SAStateAddr:0x00000000
[ 107.760000] CD_SAStateAddr:0x00000000
[ 107.770000] CD_UserIdAddr:0x00000000
[ 107.770000] CD_Length:0x00400000
[ 107.780000]
[ 107.780000] PEC_Init: PRNG is initialized

[maurer]

could the "[ 107.410000] Adapter: Successfully initialized EIP93v2 in ARM mode" be the reason why the driver does nothing?
The MT7621 is MIPS not ARM like MT7623

[freespirit]

No, however nice observation. The driver does not do anything because the mediatek driver is monolithic with Linux kernel (it patches the source net/esp4.c of linux ipsec driver intercepting the two functions ipsec_esp_input and ipsec_esp_output, forwarding all incoming/outgoing packets to two new functions inside the crypto engine) so I had to remove the integration with Linux Kernel because official OpenWRT firmware does not allow such integration (no module can intercept any ipsec packets with original OpenWRT firmware) and therefore, even though the driver exists, ipsec packets are never forwarded to it. In any case I was able to test if insmod works and with a small additional code I was able to get its capabilities I'd like to release the cryptoDriver as a pluggable module consisting at the end of two modules: one for crypto engine, one for ipsec acceleration plus obviously a minor patch to the linux kernel in order to forward ipsec packets to the new ipsec acceleration module and all this will be pluggable at runtime (not statically during compilation as it is now). As it regards to your clever observation it seems that the crypto engine is capable of working in a so called arm mode and the driver source code itself forces the engine to get into this mode to work (look for arm inside this file https://github.com/mqmaker/linux/blob/cc6cfb8993b88335878c116bc259fad44f737dfb/drivers/net/cryptoDriver/source/mtk_eip93Init.c), however I do not why (probably it refers to memory endianess) and without documentation is almost impossible to tell; in any case the driver seems to initialize correctly. There is the interrupt problem to solve and some code cleansing/separation is needed (the code is not very well written, the 2 patched kernel linux functions call directly the crypto driver whereas it would be far better if the crypto driver asks "ipsec driver" to forward it the packets when it is installed in the system through insmod) , but I think that major part of work is done. Let's hope that at the end everything will work, but for now the results are promising.

[e97]

Was the code you used for the crypto drivers from the 2.6 kernel or the latest 3.x / 4.x kernel (in the MediaTek 5.x SDK)?

[freespirit]

I do not have MTK SDK 5 only 4.3.2.0 so it was code for kernel 2.6, yet I was able to compile it on 4.3 and make it "work" (the driver is far from being usable). If you can share MTK 5.0.0.0 SDK I'll gladly accept it

[anderson]

I want MTK 5.0.0.0 SDK,too.If you dont mind.

[e97]

I dont have it, someone else mentioned it on the forums.. I can't seem to find the post.

[freespirit]

I am into the IRQ issue, it seems that the driver is not able to register the irq 19...I have also tried to change the driver init code like

static void mtk_interruptHandler_done(void)
{
printk("Mtk-Crypto-Engine: interrupt received");
}

int _init VDriverInit(void)
{
int status=-1;
status=request_irq(19,&mtk_interruptHandler_done,0,"MTKIRQ", NULL);
printk("request_irq ireq 19 result %d",status);
}

yet it always fails with error code -89 which is quite unusual error code for irqs (I would expect it for socket)..has anybody an idea why this is happening ?!? I tried also to use an already taken irq and I was given the correct error code (-16 (EBUSY))

#define EDESTADDRREQ 89 /* Destination address required */

The driver could be used without interrupt in polling mode, but it would be a nonsense. Can anybody help me ?

[Demetris]

Try updating from v1.5 to 1.8 and you will be fine

[freespirit]

?!? What shall I have to update from 1.5 to 1.8 ? Don't start to drink too early there are still two days to new year's eve