Skip to contentSkip to conversation

ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

PATCH New Romain Perier 6 participants 15 messages Mar 18, 2016 – Mar 19, 2016

Subsystems (2)
Arm (32-bit) Arm/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SoC support
lore
Share & tools
lore

Romain Perier

author
#0 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

This enables the new driver for Marvell CESA crypto engines on all mvebu v7.

Signed-off-by Romain Perier <[email protected]>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/configs/mvebu_v7_defconfig +1 -0
index dc5797a..26a8919 100644
@@ -155,3 +155,4 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_TIMER_STATS=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_DEV_MARVELL_CESA=m
Signature · 1 line
2.7.3
maintainer
#1 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Quoted 1 line · Romain Perier

This enables the new driver for Marvell CESA crypto engines on all mvebu v7.

Hi Romain

Isn't this also applicable to mvebu v5?

And your change to multi_v7_defconfig could also be applied to multi_v5_defconfig.

Thanks
Andrew

Quoted 17 lines
Signed-off-by Romain Perier <[email protected]>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/configs/mvebu_v7_defconfig +1 -0
index dc5797a..26a8919 100644
@@ -155,3 +155,4 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_TIMER_STATS=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_DEV_MARVELL_CESA=m
Signature · 1 line
2.7.3
#2 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Hello,

Quoted 4 lines · Andrew Lunn

Isn't this also applicable to mvebu v5?

And your change to multi_v7_defconfig could also be applied to multi_v5_defconfig.

mvebu_v5 already enables a crypto driver, but it's the old one. So there's a decision to be taken here whether we move all the platforms to use the new driver or not.

The new driver has been tested on the Armada family, and I believe also on Kirkwood. However I'm pretty sure it hasn't been tested on Dove and Orion.

Dove is ARMv7 and enabled in mvebu_v7_defconfig, but since neither the old nor the new driver were enabled in mvebu_v7_defconfig, we are not going to disrupt any existing user here by adding the new driver in the defconfig.

Changing mvebu_v5_defconfig, multi_v5_defconfig, orion5x_defconfig and dove_defconfig however implies moving those defconfigs away from the old driver, and select the new one instead. A more serious change, IMO.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#3 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

(adding Jason Cooper in CC:)

Hi Thomas and Andrew

Quoted 22 lines · Thomas Petazzoni

Hello,

Quoted 4 lines · Andrew Lunn

Isn't this also applicable to mvebu v5?

And your change to multi_v7_defconfig could also be applied to multi_v5_defconfig.

mvebu_v5 already enables a crypto driver, but it's the old one. So there's a decision to be taken here whether we move all the platforms to use the new driver or not.

The new driver has been tested on the Armada family, and I believe also on Kirkwood. However I'm pretty sure it hasn't been tested on Dove and Orion.

Dove is ARMv7 and enabled in mvebu_v7_defconfig, but since neither the old nor the new driver were enabled in mvebu_v7_defconfig, we are not going to disrupt any existing user here by adding the new driver in the defconfig.

Quoted 4 lines

Changing mvebu_v5_defconfig, multi_v5_defconfig, orion5x_defconfig and dove_defconfig however implies moving those defconfigs away from the old driver, and select the new one instead. A more serious change, IMO.

For Dove I don't know if there are users for this module, but for Orion and Kirkwood as they are used in NAS product, I am pretty sure that people use it. I would like to have some feedback about users which have switched to the new driver. I think Jason did it on kirkwood.

Gregory

Quoted 8 lines

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Signature · 4 lines
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#4 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Quoted 4 lines · Gregory CLEMENT

For Dove I don't know if there are users for this module, but for Orion and Kirkwood as they are used in NAS product, I am pretty sure that people use it. I would like to have some feedback about users which have switched to the new driver. I think Jason did it on kirkwood.

I've tested it (and sent patches to fix issues found) with Dove. As it works on Dove, there's no reason not to have it enabled on Dove.

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#5 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Russell, Romain,

Quoted 8 lines · Russell King - ARM Linux
Quoted 4 lines · Gregory CLEMENT

For Dove I don't know if there are users for this module, but for Orion and Kirkwood as they are used in NAS product, I am pretty sure that people use it. I would like to have some feedback about users which have switched to the new driver. I think Jason did it on kirkwood.

I've tested it (and sent patches to fix issues found) with Dove. As it works on Dove, there's no reason not to have it enabled on Dove.

Great! So it means that it's fine to update mvebu_v7_defconfig, multi_v7_defconfig and dove_defconfig to use the new driver.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#6 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Quoted 9 lines · Thomas Petazzoni

Russell, Romain,

Quoted 6 lines · Russell King - ARM Linux
Quoted 4 lines · Gregory CLEMENT

For Dove I don't know if there are users for this module, but for Orion and Kirkwood as they are used in NAS product, I am pretty sure that people use it. I would like to have some feedback about users which have switched to the new driver. I think Jason did it on kirkwood.

Quoted 5 lines
Quoted 2 lines

I've tested it (and sent patches to fix issues found) with Dove. As it works on Dove, there's no reason not to have it enabled on Dove.

Great! So it means that it's fine to update mvebu_v7_defconfig, multi_v7_defconfig and dove_defconfig to use the new driver.

I do seem to be carrying some patches for some time for CESA:

crypto: marvell: rearrange handling for sw padded hashes
crypto: marvell: rearrange handling for hw finished hashes
crypto: marvell: rearrange last request handling
crypto: marvell: avoid adding final operation within loop
crypto: marvell: ensure iter.base.op_len is the full op length
crypto: marvell: use presence of scatterlist to determine data load
crypto: marvell: move mv_cesa_dma_add_frag() calls
crypto: marvell: always ensure mid-fragments after first-fragment
crypto: marvell: factor out adding an operation and launching it
crypto: marvell: factor out first fragment decisions to helper
crypto: marvell: const-ify argument to mv_cesa_get_op_cfg()
crypto: marvell: ensure template operation is initialised
crypto: marvell: fix the bit length endianness
crypto: marvell: add flag to determine algorithm endianness
crypto: marvell: keep creq->state in CPU endian format at all times
crypto: marvell: easier way to get the transform

and the last time I seem to have any comments on them was back in October last year. I don't remember what status these are, and as I've been concentrating on other areas. I'll try to remember to send them out after rc1.

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#7 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Hello,

Quoted 19 lines · Russell King - ARM Linux

I do seem to be carrying some patches for some time for CESA:

crypto: marvell: rearrange handling for sw padded hashes
crypto: marvell: rearrange handling for hw finished hashes
crypto: marvell: rearrange last request handling
crypto: marvell: avoid adding final operation within loop
crypto: marvell: ensure iter.base.op_len is the full op length
crypto: marvell: use presence of scatterlist to determine data load
crypto: marvell: move mv_cesa_dma_add_frag() calls
crypto: marvell: always ensure mid-fragments after first-fragment
crypto: marvell: factor out adding an operation and launching it
crypto: marvell: factor out first fragment decisions to helper
crypto: marvell: const-ify argument to mv_cesa_get_op_cfg()
crypto: marvell: ensure template operation is initialised
crypto: marvell: fix the bit length endianness
crypto: marvell: add flag to determine algorithm endianness
crypto: marvell: keep creq->state in CPU endian format at all times
crypto: marvell: easier way to get the transform

Quoted 4 lines

and the last time I seem to have any comments on them was back in October last year. I don't remember what status these are, and as I've been concentrating on other areas. I'll try to remember to send them out after rc1.

All (or most) of these patches seem to be in mainline already:

ab270e7055e0aa9d4dc3bf419cdfdde340174978 crypto: marvell/cesa - rearrange handling for sw padded hashes aee84a7e6ed515f0f217317ff261a15db4bff0bb crypto: marvell/cesa - rearrange handling for hw finished hashes 58953e15ef015ba9136b7234a7098cf827428999 crypto: marvell/cesa - rearrange last request handling e41bbebddec44f7c06585f42686b2a529513fc6a crypto: marvell/cesa - avoid adding final operation within loop bd274b10856b91f702fa767114aa7e6ac45b933d crypto: marvell/cesa - ensure iter.base.op_len is the full op length d9bba4c3ebbc65b9113624eb1690bed776fb6106 crypto: marvell/cesa - use presence of scatterlist to determine data load 0971d09a8566abd6640acdbe3fd304e67e257bd3 crypto: marvell/cesa - move mv_cesa_dma_add_frag() calls 2f396a91d1d01a423fd87b7c6ff71600d06b9c05 crypto: marvell/cesa - always ensure mid-fragments after first-fragment 9621288673cb2a1805eadf29b92e5bcec6a0e2e5 crypto: marvell/cesa - factor out adding an operation and launching it 8651791e5403a0e0634b76dee91b102dc4f40385 crypto: marvell/cesa - factor out first fragment decisions to helper c439e4eec73373c6d5b7129ece69d67978ada307 crypto: marvell/cesa - const-ify argument to mv_cesa_get_op_cfg() d30cb2fa34829161cfa1f847049b3fcfcfeebc93 crypto: marvell/cesa - ensure template operation is initialised 51954a968bbedcabf2b42fec2ec51386f0dee0c4 crypto: marvell/cesa - fix the bit length endianness a9eb678f8addc1bfb80bacc45f6df1108fd1c0d9 crypto: marvell/cesa - add flag to determine algorithm endianness 4c2b130c8ae79af734e5e57f3662e25ef4d20e8d crypto: marvell/cesa - keep creq->state in CPU endian format at all times 80754539ec936b0afe8a3c406b7d67612977cc71 crypto: marvell/cesa - easier way to get the transform

They are in mainline since v4.4.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#8 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Quoted 23 lines · Thomas Petazzoni

Hello,

Quoted 19 lines · Russell King - ARM Linux

I do seem to be carrying some patches for some time for CESA:

crypto: marvell: rearrange handling for sw padded hashes
crypto: marvell: rearrange handling for hw finished hashes
crypto: marvell: rearrange last request handling
crypto: marvell: avoid adding final operation within loop
crypto: marvell: ensure iter.base.op_len is the full op length
crypto: marvell: use presence of scatterlist to determine data load
crypto: marvell: move mv_cesa_dma_add_frag() calls
crypto: marvell: always ensure mid-fragments after first-fragment
crypto: marvell: factor out adding an operation and launching it
crypto: marvell: factor out first fragment decisions to helper
crypto: marvell: const-ify argument to mv_cesa_get_op_cfg()
crypto: marvell: ensure template operation is initialised
crypto: marvell: fix the bit length endianness
crypto: marvell: add flag to determine algorithm endianness
crypto: marvell: keep creq->state in CPU endian format at all times
crypto: marvell: easier way to get the transform

Quoted 6 lines
Quoted 4 lines

and the last time I seem to have any comments on them was back in October last year. I don't remember what status these are, and as I've been concentrating on other areas. I'll try to remember to send them out after rc1.

All (or most) of these patches seem to be in mainline already:

Thanks for confirming... in which case it's not the marvell cesa patches but the fsl/nxp caam patches that are still pending... those definitely aren't part of 4.5.

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#9 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

In reply to Gregory CLEMENT

Hey all,

Quoted 35 lines · Gregory CLEMENT

(adding Jason Cooper in CC:)

Hi Thomas and Andrew

Quoted 22 lines · Thomas Petazzoni

Hello,

Quoted 4 lines · Andrew Lunn

Isn't this also applicable to mvebu v5?

And your change to multi_v7_defconfig could also be applied to multi_v5_defconfig.

mvebu_v5 already enables a crypto driver, but it's the old one. So there's a decision to be taken here whether we move all the platforms to use the new driver or not.

The new driver has been tested on the Armada family, and I believe also on Kirkwood. However I'm pretty sure it hasn't been tested on Dove and Orion.

Dove is ARMv7 and enabled in mvebu_v7_defconfig, but since neither the old nor the new driver were enabled in mvebu_v7_defconfig, we are not going to disrupt any existing user here by adding the new driver in the defconfig.

Quoted 4 lines

Changing mvebu_v5_defconfig, multi_v5_defconfig, orion5x_defconfig and dove_defconfig however implies moving those defconfigs away from the old driver, and select the new one instead. A more serious change, IMO.

Quoted 4 lines

For Dove I don't know if there are users for this module, but for Orion and Kirkwood as they are used in NAS product, I am pretty sure that people use it. I would like to have some feedback about users which have switched to the new driver. I think Jason did it on kirkwood.

As long as the old driver is still in the tree for fallback, let's go ahead and switch the relevant kernel configs over to the new driver.

Then, we can deprecate the old driver after a few cycles.

thx,

Jason.

maintainer
#10 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

In reply to Thomas Petazzoni
Quoted 9 lines · Thomas Petazzoni

Hello,

Quoted 4 lines · Andrew Lunn

Isn't this also applicable to mvebu v5?

And your change to multi_v7_defconfig could also be applied to multi_v5_defconfig.

Quoted 7 lines

mvebu_v5 already enables a crypto driver, but it's the old one. So there's a decision to be taken here whether we move all the platforms to use the new driver or not.

The new driver has been tested on the Armada family, and I believe also on Kirkwood. However I'm pretty sure it hasn't been tested on Dove and Orion.

I don't know crypto to well. Is there a good test case? Something simple to setup and run. I can test on kirkwood and Dove using the hardware i have.

Andrew

author
#11 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Hi Andrew,

Le 18/03/2016 15:30, Andrew Lunn a ?crit :

Quoted 4 lines

I don't know crypto to well. Is there a good test case? Something simple to setup and run. I can test on kirkwood and Dove using the hardware i have.

You can test it by using the crypto test manager:
CONFIG_CRYPTO_DEV_MARVELL_CESA=y and CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n

It will enable some cryptographics tests when the driver will be loaded, if everything works as expected, you should not have errors.

You can also test it by using the tcrypt driver :

$ modprobe tcrypt mode=<code>

You mode 402,403 and 404 for hash and mode 500,501,502 for cipher.

Note: some tests might fail for cipher because not all mode of operations are supported (like ofb or cfb).

Regards,
Romain

#12 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

In reply to Andrew Lunn
Quoted 14 lines · Andrew Lunn
Quoted 13 lines · Thomas Petazzoni

Hello,

Quoted 4 lines · Andrew Lunn

Isn't this also applicable to mvebu v5?

And your change to multi_v7_defconfig could also be applied to multi_v5_defconfig.

mvebu_v5 already enables a crypto driver, but it's the old one. So there's a decision to be taken here whether we move all the platforms to use the new driver or not.

Quoted 7 lines
Quoted 3 lines

The new driver has been tested on the Armada family, and I believe also on Kirkwood. However I'm pretty sure it hasn't been tested on Dove and Orion.

I don't know crypto to well. Is there a good test case? Something simple to setup and run. I can test on kirkwood and Dove using the hardware i have.

That's kind of the sticking point for userspace. As I understand the situation, there's been two userspace APIs for crypto - the current one, which is network based (af-alg-rr), but performs badly, and another (I forget what it's called but it needs kernel patches, but is more popular amongst openwrt folk) which I've no experience of.

There's an openssl plugin to talk to the kernel crypto drivers via this AF_ALG interface, but you have to hunt around for it and build it. Once built and installed, it needs a bit of configuration:

Towards the top of openssl.cnf:

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

and further down:

[engine_section]
af_alg = af_alg_engine

[af_alg_engine]
# Armada 388:

#  cbc(des):des-cbc
#  ecb(aes):des-ecb*
#  cbc(des3_ede):des-ede3-cbc
#  ecb(des3_ede):des-ede3-ecb
#  cbc(des):aes-128-cbc aes-192-cbc aes-256-cbc
#  ecb(des):aes-128-ecb aes-192-ecb aes-256-ecb

#CIPHERS=aes-128-cbc aes-192-cbc aes-256-cbc des-cbc des-ede3-cbc

# Armada 388 and Dove can only do md5, sha1 and sha256 in hardware DIGESTS=md5 sha256 sha1

# Putting this last means we register the above as the default algorithms
#default_algorithms = ALL

I'd suggest for testing purposes, not to put this into the system openssl.cnf, but create a copy of that and add the above to that copy. Then, run openssl using:

OPENSSL_CONF=/path/to/my/openssl.cnf openssl dgst -md5 FILE

and compare the output with md5sum etc. strace will confirm whether openssl is using the AF_ALG interface (you shoudl see it send()ing the data to an accept()'d AF_ALG socket.)

Signature · 3 lines
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
#13 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

Russell,

Quoted 5 lines · Russell King - ARM Linux

That's kind of the sticking point for userspace. As I understand the situation, there's been two userspace APIs for crypto - the current one, which is network based (af-alg-rr), but performs badly, and another (I forget what it's called but it needs kernel patches, but is more popular amongst openwrt folk) which I've no experience of.

You have the choice between cryptodev-linux
(http://cryptodev-linux.org/) or OCF-Linux
(http://ocf-linux.sourceforge.net/).

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#14 lore raw

PATCH 1/1 ARM: configs: Enabling the new Marvell's cryptographic engine driver for mvebu_v7_defconfig

In reply to Romain Perier

Hi Romain,

Quoted 2 lines · Romain Perier

This enables the new driver for Marvell CESA crypto engines on all mvebu v7.

Thanks for this patch. Could you select the driver as built-in instead of module?

For me the main benefit to enable this driver in mvebu_v7_defconfig is for finding regression during boot tests. It is done by kernelci but as far as I know they don't load modules. Moreover in my case, most of the time I use a simple kernel without any modules.

Thanks!

Gregory

Quoted 17 lines
Signed-off-by Romain Perier <[email protected]>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/configs/mvebu_v7_defconfig +1 -0
index dc5797a..26a8919 100644
@@ -155,3 +155,4 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_TIMER_STATS=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_DEV_MARVELL_CESA=m
Signature · 1 line
2.7.3
Signature · 4 lines
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com