Jump to content

Recommended Posts

Posted

It would be nice to be able to use hardware crypto for VPNs.   The rockchip's hardware crypto acceleration has apparently been supported since Kernel 4.5.  

 

I noticed that the CONFIG_CRYPTO_DEV_ROCKCHIP option hadn't been compiled into the standard Armbian builds, so I built a custom kernel.  

 

Having the rk_crypto module loaded gives me additional ciphers in /proc/crypto as expected.  

 

Without the module loaded (either blacklisted with my build, or with the normal Armbian kernel), my tunnel (IKEv2/IPSEC w Strongswan) works fine.  But with the module installed, no traffic passes.  Sometimes I see kernel errors in syslog.  A couple of times the box has locked up.  

 

I tried a -next build and a -dev build.  I tried applying the 2 patches (https://patchwork.kernel.org/patch/9858691/ etc) from July onto the -dev build.  No joy.  

 

Unfortunately, I'm used to working on PC hardware where AES-NI pretty much "just works," so I'm not really sure where to go from here.  Am I missing something?  Was the kernel module excluded due to a known issue?  

 

As a total aside, when I did the -next build, I enabled XZ for squashfs.  This allows Ubuntu's snapd stuff to run.  Works really very well on Armbian/Tinker.  Worth including in the standard Armbian builds?

 

Posted

Welcome to the forum! 

 

3 hours ago, BeauSlim said:

 Was the kernel module excluded due to a known issue?  

Not on my part, do you have the logged errors you were speaking of?

 

 

3 hours ago, BeauSlim said:

As a total aside, when I did the -next build, I enabled XZ for squashfs.  This allows Ubuntu's snapd stuff to run.  Works really very well on Armbian/Tinker.  Worth including in the standard Armbian builds?

 

I was unaware of that entire system, looks interesting enough.  Is there a specific benefit over normal package management, ease of publication/etc?  Also, how on earth do you snap boot files and kernels?  Ok, off-topic...  Perhaps simply pull request with changes and explanation.

 

@Igor, any harm?  Or maybe a feature we'd want?

Posted
1 hour ago, TonyMac32 said:

Igor, any harm?  Or maybe a feature we'd want?


IMHO if there is some need for snapd kernel wise, just add. Package/service install can be left for user to install.

Posted

I've added XZ for squashfs to dev and enabled crypto, I confirm it's loading and new ciphers reflected in /proc/crypto.  I'm not sure what would be causing issue, trying to get some more background on it.

Posted
On 2017/8/21 at 8:50 AM, BeauSlim said:

It would be nice to be able to use hardware crypto for VPNs.   The rockchip's hardware crypto acceleration has apparently been supported since Kernel 4.5.  

 

I noticed that the CONFIG_CRYPTO_DEV_ROCKCHIP option hadn't been compiled into the standard Armbian builds, so I built a custom kernel.  

 

Having the rk_crypto module loaded gives me additional ciphers in /proc/crypto as expected.  

 

Without the module loaded (either blacklisted with my build, or with the normal Armbian kernel), my tunnel (IKEv2/IPSEC w Strongswan) works fine.  But with the module installed, no traffic passes.  Sometimes I see kernel errors in syslog.  A couple of times the box has locked up.  

 

I tried a -next build and a -dev build.  I tried applying the 2 patches (https://patchwork.kernel.org/patch/9858691/ etc) from July onto the -dev build.  No joy.  

 

Unfortunately, I'm used to working on PC hardware where AES-NI pretty much "just works," so I'm not really sure where to go from here.  Am I missing something?  Was the kernel module excluded due to a known issue?  

 

As a total aside, when I did the -next build, I enabled XZ for squashfs.  This allows Ubuntu's snapd stuff to run.  Works really very well on Armbian/Tinker.  Worth including in the standard Armbian builds?

 

 

As I know the kernel version which rockchip release is kernel 4.4.  Where can I get the Kernel 4.5 to do some test ?

Posted

You'll have to go to Github and clone the repo, look over the documentation (it's pretty straightforward) and build the "Rockchip Dev" image.  Then you'll have an image for SD card to run tests with.  Pre-built images don't currently have hardware crypto turned on.

Posted (edited)

Reviving a old thread, I was looking to enable the 3288 RNG that supposedly lies in the processor and I stumbled upon this thread.

 

I was able to backport the aforementioned patchset (see in https://pastebin.com/fauem89j

and I found zero changes in /proc/crypto :-P

 

# Original kernel, no backport

[root@tinkerboard shm]# uname -r
4.4.120-beleza9-rockchip

[root@tinkerboard ~]# modinfo rk_crypto
modinfo: ERROR: Module rk_crypto not found.

[root@tinkerboard ~]# cat /proc/crypto  >  build9

[root@tinkerboard ~]# ll
total 10968
-rw-r--r-- 1 root root    7502 Apr  9 03:00 build9  <-- here
-rw-r--r-- 1 root root   28207 Apr  7 20:10 dmesg.txt
-rw-r--r-- 1 root root   37713 Apr  8 14:34 dmesg.txt1
-rw-r--r-- 1 root root   38222 Apr  8 14:54 dmesg.txt2

===========

[root@tinkerboard ~]# uname -a
Linux tinkerboard 4.4.120-beleza-10-rockchip #25 SMP Mon Apr 9 03:59:22 UTC 2018 armv7l GNU/Linux

[root@tinkerboard ~]# cat /proc/crypto  >  build10-pre

[root@tinkerboard ~]# ll
total 11000
-rw-r--r-- 1 root root    7502 Apr  9 03:00 build9
-rw-r--r-- 1 root root    7502 Apr  9 04:03 build10-pre  <==== here, prior to load module
-rw-r--r-- 1 root root   28207 Apr  7 20:10 dmesg.txt
-rw-r--r-- 1 root root   37713 Apr  8 14:34 dmesg.txt1
-rw-r--r-- 1 root root   38222 Apr  8 14:54 dmesg.txt2

[root@tinkerboard ~]# modinfo rk_crypto
filename:       /lib/modules/4.4.120-beleza-10-rockchip/kernel/drivers/crypto/rockchip/rk_crypto.ko
license:        GPL
description:    Support for Rockchip's cryptographic engine
author:         Zain Wang <zain.wang@rock-chips.com>
alias:          of:N*T*Crockchip,rk3288-crypto*
depends:        
intree:         Y
vermagic:       4.4.120-beleza-10-rockchip SMP mod_unload ARMv7 p2v8 


[root@tinkerboard 4.4.120-beleza-10-rockchip]# modprobe rk_crypto
[root@tinkerboard 4.4.120-beleza-10-rockchip]# 
[root@tinkerboard /]# cat /proc/crypto  >  build10-after
[root@tinkerboard /]# lsmod
Module                  Size  Used by
rk_crypto              24576  0 
uas                    20480  0 

[root@tinkerboard ~]# ll
total 11000
-rw-r--r-- 1 root root    7502 Apr  9 03:00 build9
-rw-r--r-- 1 root root    7502 Apr  9 04:04 build10-after <==== HERE
-rw-r--r-- 1 root root    7502 Apr  9 04:03 build10-pre
-rw-r--r-- 1 root root   28207 Apr  7 20:10 dmesg.txt
-rw-r--r-- 1 root root   37713 Apr  8 14:34 dmesg.txt1
-rw-r--r-- 1 root root   38222 Apr  8 14:54 dmesg.txt2

Well, pretty much the same ¯\_(ツ)_/¯

 

And no sign of HWRNG too:

 

[root@tinkerboard ~]# strace -fxvvt -e trace=file rngd
[...]
04:21:36 open("/dev/hwrng", O_RDONLY|O_LARGEFILE) = 3
[...]
04:21:36 read(3, 0xbeb555ec, 4)         = -1 ENODEV (No such device)
04:21:36 write(2, "error reading from entropy sourc"..., 50error reading from entropy source:: No such device) = 50
04:21:36 write(2, "\n", 1
)              = 1
04:21:36 exit_group(1)                  = ?
04:21:36 +++ exited with 1 +++

/dev/hwrng is there because it does exist in kconfig.

 

oh well. FYI.

 

UPDATE: I have asked Rockchip in https://github.com/rockchip-linux/u-boot/issues/21 .

Edited by Rfreire
Added Rockchip Question issue
Posted

Some more test results here while in the Uber on my way to work. I wrote the Developer, let's see what comes up.

 

I have built a kernel backporting your 3288 Crypto acceleartor (using a TinkerBoard) and I'm puzzled about how do I take advantage of the Crypto Engine.

I have done some OpenSSL tests and both shows no deviation from both with and without the module. See:

===> TESTING WITH THE ENGINE
[root@tinkerboard cron.d]# modprobe rk_crypto
[root@tinkerboard cron.d]# openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 7134953 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 64 size blocks: 2990888 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 778812 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 195865 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 8192 size blocks: 24452 aes-256 cbc's in 3.00s
OpenSSL 1.0.1t  3 May 2016
built on: Thu Mar 29 12:42:31 2018
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      38180.35k    63805.61k    66458.62k    66855.25k    66770.26k

===> REMOVING THE ENGINE
[root@tinkerboard cron.d]# modprobe -r rk_crypto
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]# openssl speed aes-256-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 7014728 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 64 size blocks: 2975590 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 773596 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 195292 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 8192 size blocks: 24386 aes-256 cbc's in 2.99s
OpenSSL 1.0.1t  3 May 2016
built on: Thu Mar 29 12:42:31 2018
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      37662.97k    63479.25k    66013.53k    66659.67k    66812.75k

===> NOW TRYING A DIFFERENT OPENSSL TEST. STILL WITHOUT ENGINE
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]# openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 6525393 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 2932580 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 770173 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 195867 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 24496 aes-256-cbc's in 3.00s
OpenSSL 1.0.1t  3 May 2016
built on: Thu Mar 29 12:42:31 2018
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      34802.10k    62561.71k    65721.43k    66855.94k    66890.41k
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]#

===> RE-INSERTING THE ENGINE
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]# modprobe rk_crypto
[root@tinkerboard cron.d]#
[root@tinkerboard cron.d]# openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 6918935 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 2939849 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 771348 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 195315 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 24436 aes-256-cbc's in 3.00s
OpenSSL 1.0.1t  3 May 2016
built on: Thu Mar 29 12:42:31 2018
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      36900.99k    62716.78k    65821.70k    66667.52k    66726.57k

===> The test results are pretty much in line with both with and without the module.

Module information:

[root@tinkerboard cron.d]# modinfo rk_crypto
filename:       /lib/modules/4.4.120-beleza-10-rockchip/kernel/drivers/crypto/rockchip/rk_crypto.ko
license:        GPL
description:    Support for Rockchip's cryptographic engine
author:         Zain Wang <zain.wang@rock-chips.com>
alias:          of:N*T*Crockchip,rk3288-crypto*
depends:        
intree:         Y
vermagic:       4.4.120-beleza-10-rockchip SMP mod_unload ARMv7 p2v8

 

Posted

OpenSSL is user-space, so you need to use AF_ALG (or Cryptodev but that's kind of old-school) to bridge to kernel-space and access the rk_crypto driver.   I looked at this (referring to some Marvell pogo-plug era documentation) but never bothered to sort out all the pieces needed.  

 

My application was a VPN, and I went the easy way and used IPSec, which lives in kernel-space.  A good kernel module, StrongSwan, and the related NetworkManager plugin and you *should* be good to go.  But, like I mentioned in my post above:  with no module loaded, traffic flows fine.  With the module loaded, I got no traffic and usually  had a whole-board lockup.  

 

AFAIK, many of the v8 chips out now support ARM crypto acceleration so there's little point in mucking with something proprietary except out of curiosity.  

 

 

 

Posted

Hi Beau!!

 

Thanks for clarifying! I appreciate your post.

 

I have just migrated my rpi stuffs into the Tinkerboard and I happen to have a ipsec tunnel between home and a US endpoint.

 

I have the rk_crypto module active and the ipsec tunnel is doing just fine.. Go figure :-)

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines