Marvell CESA in kernel 4.4 [solved]

Hi again,

I'm truing to use Marvell cesa engine. Unfortunately I get the following errors:

While loading mv_cesa:
[ 855.515205] MV-CESA:Could not register sha1 driver
[ 855.520135] MV-CESA:Could not register hmac-sha1 driver

While loading marvell_cesa (after removing mv_cesa):
[ 1701.535309] marvell-cesa: probe of f1030000.crypto failed with error -524

Did anyone found a fix-up??
Note:
- I'm using self-compiled linux-4.4.3 kernel patched with the patch from linux-4.4.0-kirkwood-tld-1-bodhi.tar.bz2.
- I do have the "third" version of NSA310 - with red usb led and LM85 monitoring chip.

btw: Do you know if the hardware engine will be used to encrypt SSH sessions?



Edited 2 time(s). Last edit at 03/09/2016 04:45PM by pld.

Hi again,

Some tricks and tips

1. There is no need to generate separate u-boot images for the kernel and initrd. Using following command:

mkimage -A arm -O linux -T multi -C none -a 0x00008000 -e 0x00008000 -n "Linux kernel" -d zImage:initrd.img uImage

I obtain single u-boot image containing both zImage and initrd. This way you do not have to bother with adjusting separate address for loading initrd. Works perfectly on NSA310 with stock u-boot.

2. Someone wrote that he has an rootfs on md RAID1 but loads the kernel from USB connected non-raid disk. If you set metadata to 0.90 then md-raid will store the extra information at the end of the device. Thanks to it you can read the files directly from single RAID1 member, without the use of md-raid. This allows boot loaders such as Lilo to boot from RAID1. You may do the same with u-boot but remember: --metadata=0.90. If you use any higher metadata version, then the extra information are stored in several places of a physical device and the results are unpredictable.

pld,

Thanks for sharing! indeed, the modern new u-boot versions have made this possible and it is a pretty convenient feature. I've not tried to switch to this booting method because some users still boot with stock u-boot and they only want a newer kernel.

> mkimage -A arm -O linux -T multi -C none -a
> 0x00008000 -e 0x00008000 -n "Linux kernel" -d
> zImage:initrd.img uImage
>
> I obtain single u-boot image containing both
> zImage and initrd. This way you do not have to
> bother with adjusting separate address for loading
> initrd. Works perfectly on NSA310 with stock
> u-boot.

BTW, when you need to regenerate Initrd after apt-get upgrade, you will have to remember repack it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
> Thanks for sharing! indeed, the modern new u-boot
> versions have made this possible and it is a
> pretty convenient feature. I've not tried to
> switch to this booting method because some users
> still boot with stock u-boot and they only want a
> newer kernel.

I'm using:
U-Boot 1.1.4 (Jun 8 2011 - 18:48:37) Marvell version: 3.4.19
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFEE0
the stock one.

> BTW, when you need to regenerate Initrd after
> apt-get upgrade, you will have to remember repack
> it.
True. If I'm not wrong then, in case of separate images, you still need to upgrade uInitrd.

PS. Thanks bodhi for cleaning my mess.

pld,

> True. If I'm not wrong then, in case of separate
> images, you still need to upgrade uInitrd.

True, either cases will need to regenerate something.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> While loading mv_cesa:
> [ 855.515205] MV-CESA:Could not register sha1
> driver
> [ 855.520135] MV-CESA:Could not register
> hmac-sha1 driver
>
> While loading marvell_cesa (after removing
> mv_cesa):
> [ 1701.535309] marvell-cesa: probe of
> f1030000.crypto failed with error -524

The same result with linux-4.4.0-kirkwood-tld-1-bodhi.tar.bz2.
Can someone provide me a (possibly recent) kernel version with working marvell cesa modules?

With linux-4.2.0-kirkwood-tld-1-bodhi.tar.bz2 still no luck.

But, I did test the ArchLinux. Both, marvell_cesa and crypotodev load cleanly and marvell_cesa shows in /proc/crypto. Kernel version 4.4.1-1-ARCH. Maybe we should steal some patches from there?

pld,

> But, I did test the ArchLinux. Both, marvell_cesa
> and crypotodev load cleanly and marvell_cesa shows
> in /proc/crypto. Kernel version 4.4.1-1-ARCH.
> Maybe we should steal some patches from there?

Sure, can you extract the patches? I'll take a look.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi

I kind of brute-force glued together some parts of ArchLinuxARM and stretch with jessie. Now I have working set-up. It's quite messy at the moment so I'll have to clean it up a bit.

bodhi Wrote:
> Sure, can you extract the patches? I'll take a

Sure, but I need few more days. Have to work - hard life.

btw: This forced me to set up jessie chroot (inside of PLD) and cross-compile.
Do you need a tutorial on installing chroot and cross-building kernel & packages (independent on host side distribution)?

Hi there,

It's not about sources or patches. It's about the kernel configuration. I did compile linux-4.4.3 patched with the patch taken from linux-4.4.0-kirkwood-tld-1-bodhi.tar.bz2 and the config from:
https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-kirkwood-dt

CESA works as expected. Here are some test results:

Before loaging cryptodev:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      12331.86k    15878.74k    17204.83k    17495.72k    17649.79k
aes-192-cbc      11076.69k    13816.96k    14815.46k    15021.74k    15140.13k
aes-256-cbc      10000.54k    12224.81k    13008.74k    13161.81k    13257.89k
des-ede3-cbc      2969.78k     3158.53k     3225.43k     3227.65k     3241.18k
des-cbc           7381.10k     8720.21k     9149.99k     9231.70k     9296.14k

After loading cryptodev:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       6287.57k    30569.07k   124076.80k   230286.82k  4336435.20k
aes-192-cbc       6278.51k    15105.60k    92550.40k   330176.98k  2291507.20k
aes-256-cbc       7884.93k    22981.60k   114282.67k   465783.47k  2792379.73k
des-ede3-cbc      4090.99k    28279.14k    83346.77k   341666.13k  1294609.07k
des-cbc           4395.20k    16005.84k   105173.94k   312586.24k         infk

Although these are the only ciphers which openssl seem to accelerate by marvel_cesa, in /proc/crypto I have:

# egrep '^module|^name' /proc/crypto 
name         : hmac(sha1)
module       : marvell_cesa
name         : hmac(md5)
module       : marvell_cesa
name         : sha1
module       : marvell_cesa
name         : md5
module       : marvell_cesa
name         : cbc(aes)
module       : marvell_cesa
name         : ecb(aes)
module       : marvell_cesa
name         : cbc(des3_ede)
module       : marvell_cesa
name         : ecb(des3_ede)
module       : marvell_cesa
name         : cbc(des)
module       : marvell_cesa
name         : ecb(des)
module       : marvell_cesa
....

--

Regards
PLD = Polish(ed) Linux Distribution, www.pld-linux.org

Hi pld,

> It's not about sources or patches. It's about the
> kernel configuration. I did compile linux-4.4.3
> patched with the patch taken from
> linux-4.4.0-kirkwood-tld-1-bodhi.tar.bz2 and the
> config from:
> https://github.com/archlinuxarm/PKGBUILDs/tree/mas
> ter/core/linux-kirkwood-dt
>
> CESA works as expected.

Cool! thanks for figuring this out. I don't recall seeing config changes as part of the mainline change, I must have missed it somehow.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Somewhere here:

diff .config*
5035c5035,5036
< # CONFIG_MAGIC_SYSRQ is not set
---
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
5235c5236
< CONFIG_CRYPTO_AEAD=m
---
> CONFIG_CRYPTO_AEAD=y
5243c5244
< CONFIG_CRYPTO_RNG_DEFAULT=m
---
> CONFIG_CRYPTO_RNG_DEFAULT=y
5253,5254c5254,5255
< CONFIG_CRYPTO_GF128MUL=m
< CONFIG_CRYPTO_NULL=m
---
> CONFIG_CRYPTO_GF128MUL=y
> CONFIG_CRYPTO_NULL=y
5268c5269
< CONFIG_CRYPTO_SEQIV=m
---
> CONFIG_CRYPTO_SEQIV=y
5275,5277c5276,5278
< CONFIG_CRYPTO_CTR=m
< CONFIG_CRYPTO_CTS=m
< CONFIG_CRYPTO_ECB=m
---
> CONFIG_CRYPTO_CTR=y
> CONFIG_CRYPTO_CTS=y
> CONFIG_CRYPTO_ECB=y
5280c5281
< CONFIG_CRYPTO_XTS=m
---
> CONFIG_CRYPTO_XTS=y
5300c5301
< CONFIG_CRYPTO_MD5=m
---
> CONFIG_CRYPTO_MD5=y
5306c5307
< CONFIG_CRYPTO_SHA1=m
---
> CONFIG_CRYPTO_SHA1=y
5317c5318
< CONFIG_CRYPTO_ARC4=m
---
> CONFIG_CRYPTO_ARC4=y
5324c5325
< CONFIG_CRYPTO_DES=m
---
> CONFIG_CRYPTO_DES=y
5338c5339
< CONFIG_CRYPTO_DEFLATE=m
---
> CONFIG_CRYPTO_DEFLATE=y
5340c5341
< CONFIG_CRYPTO_LZO=m
---
> CONFIG_CRYPTO_LZO=y
5349c5350
< CONFIG_CRYPTO_DRBG_MENU=m
---
> CONFIG_CRYPTO_DRBG_MENU=y
5353,5354c5354,5355
< CONFIG_CRYPTO_DRBG=m
< CONFIG_CRYPTO_JITTERENTROPY=m
---
> CONFIG_CRYPTO_DRBG=y
> CONFIG_CRYPTO_JITTERENTROPY=y
5361c5362
< CONFIG_CRYPTO_DEV_MV_CESA=m
---
> # CONFIG_CRYPTO_DEV_MV_CESA is not set
5371,5374c5372,5375
< CONFIG_CRYPTO_SHA1_ARM=m
< CONFIG_CRYPTO_SHA256_ARM=m
< CONFIG_CRYPTO_SHA512_ARM=m
< CONFIG_CRYPTO_AES_ARM=m
---
> CONFIG_CRYPTO_SHA1_ARM=y
> CONFIG_CRYPTO_SHA256_ARM=y
> CONFIG_CRYPTO_SHA512_ARM=y
> CONFIG_CRYPTO_AES_ARM=y
5408c5409
< CONFIG_ZLIB_DEFLATE=m
---
> CONFIG_ZLIB_DEFLATE=y

--

Regards
PLD = Polish(ed) Linux Distribution, www.pld-linux.org

Found it!!

# diff .config*
5361c5361
< CONFIG_CRYPTO_DEV_MV_CESA=m
---
> # CONFIG_CRYPTO_DEV_MV_CESA is not set

mv_cesa has to be disabled (in the kernel configuration!) in order to marvell_cesa to work. Blacklisting is not enough.

--

Regards
PLD = Polish(ed) Linux Distribution, www.pld-linux.org

pld Wrote:
-------------------------------------------------------
> Found it!!
>
>

> # diff .config*
> 5361c5361
> < CONFIG_CRYPTO_DEV_MV_CESA=m
> ---
> > # CONFIG_CRYPTO_DEV_MV_CESA is not set
>

> mv_cesa has to be disabled (in the kernel
> configuration!) in order to marvell_cesa to work.
> Blacklisting is not enough.

Nice :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

FYI,

This fix will be incorporated when I release kernel 4.5.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

pld Wrote:
-------------------------------------------------------
> Do you need a tutorial on installing chroot and
> cross-building kernel & packages (independent on
> host side distribution)?

Yes please!!

Tutorials and write ups are always welcome to us the mere mortals

Hi Pld / Bodhi,

you write
>> After loaging cryptodev:
I don't find module cryptodev in the new kernel 4.5.

Am I overlooking something or does it need to get from somewhere else?
Where did you get it from, Pld?

CV,

Yes, you need to install cryptodev separately.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

pld,

Can you describe your setup?
I'm stuck on magic Oops while "make check" and lack of openssl cryptodev engine.

[ 2663.467035] cryptodev: driver 1.8 loaded.
[ 2692.909009] Unable to handle kernel NULL pointer dereference at virtual addre                                                                              ss 00000004
[ 2692.918148] pgd = de860000
[ 2692.921122] [00000004] *pgd=1e857831, *pte=00000000, *ppte=00000000
[ 2692.928371] Internal error: Oops - BUG: 17 [#1] PREEMPT ARM
[ 2692.934481] Modules linked in: ghash_generic gf128mul gcm ctr sha256_generic                                                                               hmac drbg ansi_cprng cryptodev(O) bnep bluetooth nfsd auth_rpcgss oid_registry n                                                                              fs_acl nfs lockd grace sunrpc mousedev evdev usbkbd usbmouse snd_soc_alc5623 reg                                                                              map_i2c usbhid snd_soc_kirkwood snd_soc_core snd_pcm snd soundcore i2c_mv64xxx i                                                                              2c_core ehci_orion ehci_hcd usbcore usb_common
[ 2692.970098] CPU: 0 PID: 2498 Comm: cipher-gcm Tainted: G           O    4.5.2                                                                              -tld-1 #20
[ 2692.978870] Hardware name: Marvell Kirkwood (Flattened Device Tree)
[ 2692.985741] task: de86a000 ti: de858000 task.ti: de858000
[ 2692.991657] pc : [<c019d654>]    lr : [<c019d650>]    psr: 20000013
[ 2692.991657] sp : de859bd0  ip : de859bd0  fp : de859bec
[ 2693.004230] r10: 00000008  r9 : de859c88  r8 : 00000000
[ 2693.009954] r7 : de8749d8  r6 : de858000  r5 : 00000008  r4 : de859c88
[ 2693.017109] r3 : dfe2af62  r2 : 00000250  r1 : 00000228  r0 : 00000000
[ 2693.024260] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[ 2693.032079] Control: 0005397f  Table: 1e860000  DAC: 00000051
[ 2693.038375] Process cipher-gcm (pid: 2498, stack limit = 0xde858190)
[ 2693.045338] Stack: (0xde859bd0 to 0xde85a000)
...