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

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

[Romain Perier]

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

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index dc5797a..26a8919 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -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
-- 
2.7.3

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

[Andrew Lunn]

On Fri, Mar 18, 2016 at 09:12:09AM +0100, Romain Perier wrote:
> 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
 
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>  arch/arm/configs/mvebu_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
> index dc5797a..26a8919 100644
> --- a/arch/arm/configs/mvebu_v7_defconfig
> +++ b/arch/arm/configs/mvebu_v7_defconfig
> @@ -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
> -- 
> 2.7.3
> 

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

[Thomas Petazzoni]

Hello,

On Fri, 18 Mar 2016 14:14:32 +0100, Andrew Lunn wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Gregory CLEMENT]

Hi Romain,
 
 On ven., mars 18 2016, Romain Perier <romain.perier@free-electrons.com> wrote:

> 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

> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>  arch/arm/configs/mvebu_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
> index dc5797a..26a8919 100644
> --- a/arch/arm/configs/mvebu_v7_defconfig
> +++ b/arch/arm/configs/mvebu_v7_defconfig
> @@ -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
> -- 
> 2.7.3
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

[Gregory CLEMENT]

(adding Jason Cooper in CC:)

Hi Thomas and Andrew
 
 On ven., mars 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> On Fri, 18 Mar 2016 14:14:32 +0100, Andrew Lunn wrote:
>
>> 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.


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


>
> Best regards,
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

[Andrew Lunn]

On Fri, Mar 18, 2016 at 02:51:31PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 18 Mar 2016 14:14:32 +0100, Andrew Lunn wrote:
> 
> > 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.

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

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

[Russell King - ARM Linux]

On Fri, Mar 18, 2016 at 03:26:48PM +0100, Gregory CLEMENT wrote:
> 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.

-- 
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.

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

[Romain Perier]

Hi Andrew,

Le 18/03/2016 15:30, Andrew Lunn a ?crit :
> 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

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

[Russell King - ARM Linux]

On Fri, Mar 18, 2016 at 03:30:59PM +0100, Andrew Lunn wrote:
> On Fri, Mar 18, 2016 at 02:51:31PM +0100, Thomas Petazzoni wrote:
> > Hello,
> > 
> > On Fri, 18 Mar 2016 14:14:32 +0100, Andrew Lunn wrote:
> > 
> > > 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.
> 
> 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.)

-- 
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.

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

[Thomas Petazzoni]

Russell, Romain,

On Fri, 18 Mar 2016 14:46:39 +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 18, 2016 at 03:26:48PM +0100, Gregory CLEMENT wrote:
> > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Thomas Petazzoni]

Russell,

On Fri, 18 Mar 2016 15:18:26 +0000, Russell King - ARM Linux wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Russell King - ARM Linux]

On Fri, Mar 18, 2016 at 04:35:18PM +0100, Thomas Petazzoni wrote:
> Russell, Romain,
> 
> On Fri, 18 Mar 2016 14:46:39 +0000, Russell King - ARM Linux wrote:
> > On Fri, Mar 18, 2016 at 03:26:48PM +0100, Gregory CLEMENT wrote:
> > > 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.

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.

-- 
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.

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

[Thomas Petazzoni]

Hello,

On Fri, 18 Mar 2016 15:45:00 +0000, Russell King - ARM Linux wrote:

> 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.

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Russell King - ARM Linux]

On Fri, Mar 18, 2016 at 04:52:03PM +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 18 Mar 2016 15:45:00 +0000, Russell King - ARM Linux wrote:
> 
> > 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.
> 
> 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.

-- 
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.

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

[Jason Cooper]

Hey all,

On Fri, Mar 18, 2016 at 03:26:48PM +0100, Gregory CLEMENT wrote:
> 
> (adding Jason Cooper in CC:)
> 
> Hi Thomas and Andrew
>  
>  On ven., mars 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> 
> > Hello,
> >
> > On Fri, 18 Mar 2016 14:14:32 +0100, Andrew Lunn wrote:
> >
> >> 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.
> 
> 
> 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.