Re: [PATCH v2] crypto/arm: accelerated SHA-512 using ARM generic ASM and NEON

2015-04-11 Thread Ard Biesheuvel 
On 11 April 2015 at 10:48, Arnd Bergmann a...@arndb.de wrote:
 On Saturday 11 April 2015 09:35:15 Ard Biesheuvel wrote:
 On 10 April 2015 at 22:23, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 
  On 10 apr. 2015, at 22:08, Arnd Bergmann a...@arndb.de wrote:
 
  On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
  +#if __ARM_MAX_ARCH__=7
  +.arch  armv7-a
  +.fpu   neon
  +
 
  This will cause a build failure on an ARMv7-M build, which is incompatible
  with .arch  armv7-a and .fpu   neon.
 
 
  The neon part depends on CONFIG_KERNEL_MODE_NEON, which would never be set 
  for that platform, I suppose

 On second thought, that is not entirely true, but I still don't think
 there is problem here:
 the .arch/.fpu declarations are understood perfectly fine by GAS when
 targeting ARMv7-M. Only, it will emit code that is incompatible with
 it. However, this code is invoked at runtime only if a NEON unit has
 been detected, so it will just be ignored on ARMv7-M

 Sorry, I should have collected my findings better when replying to your
 patch. What I remembered was that I saw a problem in this area in linux-next
 with randconfig builds, but I did not notice that it was for a different
 file, and I had not double-checked that patch yet in order to send it
 out.

 See below for the patch I'm currently using for my randconfig builder.
 Before you apply this, please check again which files are affected, as
 it's possible that there are other modules that suffer from the same
 problem.

 Arnd

 8---
 Subject: [PATCH] ARM: crypto: avoid sha256 code on ARMv7-M

 The sha256 assembly implementation can deal with all architecture levels
 from ARMv4 to ARMv7-A, but not with ARMv7-M. Enabling it in an
 ARMv7-M kernel results in this build failure:

 arm-linux-gnueabi-ld: error: arch/arm/crypto/sha256_glue.o: Conflicting 
 architecture profiles M/A
 arm-linux-gnueabi-ld: failed to merge target specific data of file 
 arch/arm/crypto/sha256_glue.o

 This adds a Kconfig dependency to prevent the code from being disabled

... enabled?

 for ARMv7-M.

 Signed-off-by: Arnd Bergmann a...@arndb.de

 diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
 index 458729d2ce22..76463da22f81 100644
 --- a/arch/arm/crypto/Kconfig
 +++ b/arch/arm/crypto/Kconfig
 @@ -49,6 +49,7 @@ config CRYPTO_SHA2_ARM_CE
  config CRYPTO_SHA256_ARM
 tristate SHA-224/256 digest algorithm (ARM-asm and NEON)
 select CRYPTO_HASH
 +   depends on !CPU_V7M
 help
   SHA-256 secure hash standard (DFIPS 180-2) implemented
   using optimized ARM assembler and NEON, when available.


@Herbert: could you please apply this onto cryptodev before sending
out your pull request for v4.1?
And please disregard $subject, I will post a v3 with a similar
'depends on' added (unless you're ok to add it yourself)

Thanks,
Ard.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto/arm: accelerated SHA-512 using ARM generic ASM and NEON

2015-04-11 Thread Arnd Bergmann 
On Saturday 11 April 2015 12:27:18 Ard Biesheuvel wrote:
 
 Ah i see it now. The new Sha256 module as well as the Sha512 i am proposing 
 here both use a single .o containing the !neon and neon implementations, and 
 only expose the latter if KERNEL_MODE_NEON. This way, we can use the exact 
 same .S file ad OpenSSL, which should mean less maintenance burden.
 
 So your fix seems the most appropriate, even if it means v7m won't be able to 
 use the !neon part either.
 
 

Ok, sounds good. If someone wants to change that code to work on ARMv7-M,
they probably want that fix in the openssl version as well, and then we
can update both.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: arm: workaround for building with old binutils

2015-04-11 Thread Arnd Bergmann 
On Saturday 11 April 2015 12:35:19 Ard Biesheuvel wrote:
 
 Yes, that should work. Could we also move the CE objs to ce-obj-$() and put
 
 ifneq ($(ce-obj-y)$(ce-obj-m),)
 if as check
 obj-y += $(ce-obj-y)
 obj-m += $(ce-obj-m)
 else
 $(warning ...)
 endif
 endif
 
 around it so you only get the warning if you have selected any of these 
 modules?

Sounds good, I had not thought of that.

 In any case, I strongly prefer to leave the .S files themselves alone if at 
 all possible

Yes, makes sense.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Counter Size in CTR mode for AES Driver

2015-04-11 Thread Stephan Mueller 
Am Samstag, 11. April 2015, 09:07:35 schrieb sri sowj:

Hi sri,

 Hi Stephen,
 
 Thanks a million for the information provided. I really appreciate
 your time and efforts.
 
 In CTR mode counter size is not fixed , it varies based on
 requirements like for rfc 3686 its size is 4 bytes, for other CTR
 Mode operations it is 8/16 bytes. So how does linux crypto HW drivers
 like nx-aes-ctr.c or omap-aes.c etc handles these variations?

Without having looked at those implementations, I guess that they simply 
implement ctr(aes). That means that they simply have a counter value of 128 
bit (to match the requirement that the IV must be block size). Then they 
simply increment them.

Now, the logic of the kernel crypto API kicks in: there is the rfc3686 
template in ctr.c. Thus, when you use rfc3686(ctr(aes)), you get that 
particular logic where the counter is interpreted in a special way and thus 
set up accordingly.

Now, the rfc3686 now provides a very particular interpretation of the IV -- 
i.e. this one initializes it as needed (in .fact, it uses seqiv as initialized 
in  crypto_rfc3686_alloc). After creating the IV based on a particular 
requirement, this template simply invokes ctr(aes) which simply increments the 
given IV/counter value. Then at some point, rfc3686 takes over again where the 
IV is again massaged as needed.

As we have segiv, the full power of rfc3686 can only be used by the caller 
when using the skcipher_givcrypt_* APi from include/crypto/skcipher.h. For an 
example, check the esp_output function that uses the AEAD version of the 
givcrypt API. I drew a picture in [1] that illustrates the structure a bit 
more.

[1] http://www.chronox.de/crypto-API/ch02s07.html

(the rfc3686 is logically very similar)

 
 In CTR mode nonce and counters plays a significant role while

Before continuing, you need to detach yourself from thinking of the counter 
value in form of 4/8/16 byte nonces or other values. The raw counter is 
blocksize, period. Now, some code may get an initial value of 4/8/16 bytes (or 
whatever size). Now, that implementation must do its magic to transform that 
input into block size before performing the CTR operation with the underlying 
block cipher.

 performing encryption or decryption? ,So I am trying to understand
 these aspect from linux kernel driver aspects where crypto H/W engine
 is present.

The crypto HW implementations may or may not implement the specialities 
mentioned above. That is the true power of the crypto API: every part 
inside/outside the parantheses can be implemented in independent components or 
in joint components. The kernel crypto API selects the right implementation 
based on the cra_priority.

For example, the rfc4106 template has the same issue for GCM as rfc3686 for 
the CTR mode. And rfc4106 is implemented in the HW implementation for AES-NI 
(see arch/x86/crypto/aesni_intel-glue.c) as well as in pure C (see gcm.c). 
Other HW implementations of AES or GCM may not implement rfc4106 -- they would 
use the C version as fallback (the API does that transparently based on the 
cra_priority and registered implementations). So, there is a full freedom 
available what HW can implement or wants to provide as usually there is always 
a software fallback present.
 
 from the user it might be possible to get request consisting the
 counter size of 4 or 8 or 16 bytes.There has to be a way to deal these

The user can never request sizes of a counter used for encryptions. All 
implementations will eventually align the initial counter values (which may be 
given by the caller) to a blocksize boundary. Otherwise, the math will not 
work. Thus a caller may provide some initial value (depending on the chosen 
implementation) which is then somehow padded/aligned/massaged to block size.

 variations from linux kernel crypto subsystem , but i am finding
 little hard time to understand this.
 
 Just to give a thought, is it possible  to find size of these fields
 like nonce or counter from IV size ?

Either I do not understand this remark, our based on the description above, 
you see that this question is not applicable.
 
 BR,
 Srisowj
 
 On Sat, Apr 11, 2015 at 2:21 AM, Stephan Mueller smuel...@chronox.de 
wrote:
  Am Samstag, 11. April 2015, 00:30:30 schrieb sri sowj:
  
  Hi sri,
  
  Hi All,
  
  I have seen multiple open source drivers for AES(CTR) mode for
  different Crypto Hardware Engines, I was not really sure on
  countersize,nonce etc.
  Please can any one provide some info on the following
  
  #1:How does AES driver identifies the counter size during the CTR mode
  of operation?
  
  I am not sure about the question, but the block chaining mode is
  orthogonal to the block cipher.
  
  Thus, the block cipher does not need to know of the counter size of CTR.
  That applies to any block chaining mode.
  
  looks like AES in CTR mode supports countersize of multiple lengths as
  
  below:
  1: First is a counter which is made up of a nonce and counter.

Re: [PATCH] crypto: arm: workaround for building with old binutils

2015-04-11 Thread Ard Biesheuvel 
On 10 April 2015 at 21:57, Arnd Bergmann a...@arndb.de wrote:
 Old versions of binutils (before 2.23) do not yet understand the
 crypto-neon-fp-armv8 fpu instructions, and an attempt to build these
 files results in a build failure:

 arch/arm/crypto/aes-ce-core.S:133: Error: selected processor does not support 
 ARM mode `vld1.8 {q10-q11},[ip]!'
 arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aese.8 q0,q8'
 arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aesmc.8 q0,q0'
 arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aese.8 q0,q9'
 arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aesmc.8 q0,q0'

 Since the affected versions are still in widespread use, and this breaks
 'allmodconfig' builds, we should try to at least get a successful kernel
 build. Unfortunately, I could not come up with a way to make the Kconfig
 symbol depend on the binutils version, which would be the nicest solution.

 This patch uses the 'as-option' Kbuild macro to find out whether the
 support is present in the assembler, and otherwise passes a macro
 definition to each affected file, which in turn disables that code
 entirely and results in empty modules.

 In order to help users figure out what to do, we also add a #warning
 state in place of the removed to that tells users which version to use.

 Signed-off-by: Arnd Bergmann a...@arndb.de
 Link: 
 http://storage.kernelci.org/next/next-20150410/arm-allmodconfig/build.log
 Fixes: 864cbeed4ab22d (crypto: arm - add support for SHA1 using ARMv8 Crypto 
 Instructions)

 diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
 index ef46e898f98b..60f2101e0586 100644
 --- a/arch/arm/crypto/Makefile
 +++ b/arch/arm/crypto/Makefile
 @@ -25,6 +25,10 @@ sha2-arm-ce-y:= sha2-ce-core.o sha2-ce-glue.o
  aes-arm-ce-y   := aes-ce-core.o aes-ce-glue.o
  ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o

 +armv8-ce-flags := $(call 
 as-option,-Wa$(comma)-mfpu=crypto-neon-fp-armv8,-DARMV8_CE_DISABLED)
 +asflags-y := $(armv8-ce-flags)
 +ccflags-y := $(armv8-ce-flags)
 +

Could you perhaps put the rules that build these modules inside a

ifneq ($(armv8-ce-flags),-DARMV8_CE_DISABLED)
...
endif

block?


  quiet_cmd_perl = PERL$@
cmd_perl = $(PERL) $()  $(@)

 diff --git a/arch/arm/crypto/aes-ce-core.S b/arch/arm/crypto/aes-ce-core.S
 index 8cfa468ee570..f2132ba91353 100644
 --- a/arch/arm/crypto/aes-ce-core.S
 +++ b/arch/arm/crypto/aes-ce-core.S
 @@ -8,11 +8,14 @@
   * published by the Free Software Foundation.
   */

 +#ifdef ARMV8_CE_DISABLED
 +#warning ARMv8 Crypto Extensions need binutils 2.23 or higher
 +#else
 +
  #include linux/linkage.h
  #include asm/assembler.h

 .text
 -   .fpucrypto-neon-fp-armv8
 .align  3

 .macro  enc_round, state, key
 @@ -516,3 +519,5 @@ ENTRY(ce_aes_invert)
 vst1.8  {q0}, [r0]
 bx  lr
  ENDPROC(ce_aes_invert)
 +
 +#endif
 diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
 index b445a5d56f43..4cba201a64a9 100644
 --- a/arch/arm/crypto/aes-ce-glue.c
 +++ b/arch/arm/crypto/aes-ce-glue.c
 @@ -510,13 +510,16 @@ static struct crypto_alg aes_algs[] = { {

  static int __init aes_init(void)
  {
 -   if (!(elf_hwcap2  HWCAP2_AES))
 +   if (IS_ENABLED(ARMV8_CE_DISABLED) || !(elf_hwcap2  HWCAP2_AES))
 return -ENODEV;
 return crypto_register_algs(aes_algs, ARRAY_SIZE(aes_algs));
  }

  static void __exit aes_exit(void)
  {
 +   if (IS_ENABLED(ARMV8_CE_DISABLED))
 +   return;
 +
 crypto_unregister_algs(aes_algs, ARRAY_SIZE(aes_algs));
  }

 diff --git a/arch/arm/crypto/ghash-ce-core.S b/arch/arm/crypto/ghash-ce-core.S
 index f6ab8bcc9efe..4fe75df41162 100644
 --- a/arch/arm/crypto/ghash-ce-core.S
 +++ b/arch/arm/crypto/ghash-ce-core.S
 @@ -8,6 +8,10 @@
   * by the Free Software Foundation.
   */

 +#ifdef ARMV8_CE_DISABLED
 +#warning ARMv8 Crypto Extensions need binutils 2.23 or higher
 +#else
 +
  #include linux/linkage.h
  #include asm/assembler.h

 @@ -33,8 +37,6 @@
 XH_L.reqd14

 .text
 -   .fpucrypto-neon-fp-armv8
 -
 /*
  * void pmull_ghash_update(int blocks, u64 dg[], const char *src,
  * struct ghash_key const *k, const char 
 *head)
 @@ -92,3 +94,5 @@ ENTRY(pmull_ghash_update)
 vst1.64 {XL}, [r1]
 bx  lr
  ENDPROC(pmull_ghash_update)
 +
 +#endif
 diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
 index 03a39fe29246..880afe904e5d 100644
 --- a/arch/arm/crypto/ghash-ce-glue.c
 +++ b/arch/arm/crypto/ghash-ce-glue.c
 @@ -293,7 +293,7 @@ static int __init ghash_ce_mod_init(void)
  {
 int err;

 -   if (!(elf_hwcap2  HWCAP2_PMULL))
 +   if (IS_ENABLED(ARMV8_CE_DISABLED) || !(elf_hwcap2  HWCAP2_AES))
 return -ENODEV;

 err =

Re: [PATCH v2] crypto/arm: accelerated SHA-512 using ARM generic ASM and NEON

2015-04-11 Thread Arnd Bergmann 
On Saturday 11 April 2015 09:35:15 Ard Biesheuvel wrote:
 On 10 April 2015 at 22:23, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 
  On 10 apr. 2015, at 22:08, Arnd Bergmann a...@arndb.de wrote:
 
  On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
  +#if __ARM_MAX_ARCH__=7
  +.arch  armv7-a
  +.fpu   neon
  +
 
  This will cause a build failure on an ARMv7-M build, which is incompatible
  with .arch  armv7-a and .fpu   neon.
 
 
  The neon part depends on CONFIG_KERNEL_MODE_NEON, which would never be set 
  for that platform, I suppose
 
 On second thought, that is not entirely true, but I still don't think
 there is problem here:
 the .arch/.fpu declarations are understood perfectly fine by GAS when
 targeting ARMv7-M. Only, it will emit code that is incompatible with
 it. However, this code is invoked at runtime only if a NEON unit has
 been detected, so it will just be ignored on ARMv7-M

Sorry, I should have collected my findings better when replying to your
patch. What I remembered was that I saw a problem in this area in linux-next
with randconfig builds, but I did not notice that it was for a different
file, and I had not double-checked that patch yet in order to send it
out.

See below for the patch I'm currently using for my randconfig builder.
Before you apply this, please check again which files are affected, as
it's possible that there are other modules that suffer from the same
problem.

Arnd

8---
Subject: [PATCH] ARM: crypto: avoid sha256 code on ARMv7-M

The sha256 assembly implementation can deal with all architecture levels
from ARMv4 to ARMv7-A, but not with ARMv7-M. Enabling it in an
ARMv7-M kernel results in this build failure:

arm-linux-gnueabi-ld: error: arch/arm/crypto/sha256_glue.o: Conflicting 
architecture profiles M/A
arm-linux-gnueabi-ld: failed to merge target specific data of file 
arch/arm/crypto/sha256_glue.o

This adds a Kconfig dependency to prevent the code from being disabled
for ARMv7-M.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 458729d2ce22..76463da22f81 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -49,6 +49,7 @@ config CRYPTO_SHA2_ARM_CE
 config CRYPTO_SHA256_ARM
tristate SHA-224/256 digest algorithm (ARM-asm and NEON)
select CRYPTO_HASH
+   depends on !CPU_V7M
help
  SHA-256 secure hash standard (DFIPS 180-2) implemented
  using optimized ARM assembler and NEON, when available.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: arm: workaround for building with old binutils

2015-04-11 Thread Arnd Bergmann 
On Saturday 11 April 2015 09:41:08 Ard Biesheuvel wrote:
 Could you perhaps put the rules that build these modules inside a
 
 ifneq ($(armv8-ce-flags),-DARMV8_CE_DISABLED)
 ...
 endif
 

How about something like this:

ifeq ($(call as-option,-Wa$(comma)-mfpu=crypto-neon-fp-armv8),)
$(warning ARMv8 Crypto Extensions need binutils 2.23 or higher)
else
...
endif

That would basically be a reimplementation of the missing as-option-yn
macro though, so we could also add that instead and do

ifeq ($(call as-option-yn,-Wa$(comma)-mfpu=crypto-neon-fp-armv8),y)
$(warning ARMv8 Crypto Extensions need binutils 2.23 or higher)
else
...
endif

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto/arm: accelerated SHA-512 using ARM generic ASM and NEON

2015-04-11 Thread Ard Biesheuvel 
On 10 April 2015 at 22:23, Ard Biesheuvel ard.biesheu...@linaro.org wrote:

 On 10 apr. 2015, at 22:08, Arnd Bergmann a...@arndb.de wrote:

 On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
 +#if __ARM_MAX_ARCH__=7
 +.arch  armv7-a
 +.fpu   neon
 +

 This will cause a build failure on an ARMv7-M build, which is incompatible
 with .arch  armv7-a and .fpu   neon.


 The neon part depends on CONFIG_KERNEL_MODE_NEON, which would never be set 
 for that platform, I suppose

On second thought, that is not entirely true, but I still don't think
there is problem here:
the .arch/.fpu declarations are understood perfectly fine by GAS when
targeting ARMv7-M. Only, it will emit code that is incompatible with
it. However, this code is invoked at runtime only if a NEON unit has
been detected, so it will just be ignored on ARMv7-M

-- 
Ard.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: arm: workaround for building with old binutils

2015-04-11 Thread Ard Biesheuvel 
From: Arnd Bergmann a...@arndb.de

How about something like this:

A warning will be emitted by make when descending into the arch/arm/crypto
directory, but only if any ARMv8 Crypto modules were in fact selected.

/home/ard/linux-2.6/arch/arm/crypto/Makefile:22: These ARMv8 Crypto Extensions 
modules need binutils 2.23 or higher
/home/ard/linux-2.6/arch/arm/crypto/Makefile:23: aes-arm-ce.o sha1-arm-ce.o 
sha2-arm-ce.o ghash-arm-ce.o


-8--
Old versions of binutils (before 2.23) do not yet understand the
crypto-neon-fp-armv8 fpu instructions, and an attempt to build these
files results in a build failure:

arch/arm/crypto/aes-ce-core.S:133: Error: selected processor does not support 
ARM mode `vld1.8 {q10-q11},[ip]!'
arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aese.8 q0,q8'
arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aesmc.8 q0,q0'
arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aese.8 q0,q9'
arch/arm/crypto/aes-ce-core.S:133: Error: bad instruction `aesmc.8 q0,q0'

Since the affected versions are still in widespread use, and this breaks
'allmodconfig' builds, we should try to at least get a successful kernel
build. Unfortunately, I could not come up with a way to make the Kconfig
symbol depend on the binutils version, which would be the nicest solution.

Instead, this patch uses the 'as-instr' Kbuild macro to find out whether
the support is present in the assembler, and otherwise emits a non-fatal
warning indicating which selected modules could not be built.

Signed-off-by: Arnd Bergmann a...@arndb.de
Link: http://storage.kernelci.org/next/next-20150410/arm-allmodconfig/build.log
Fixes: 864cbeed4ab22d (crypto: arm - add support for SHA1 using ARMv8 Crypto 
Instructions)
[ard.biesheuvel:
 - omit modules entirely instead of building empty ones if binutils is too old
 - update commit log accordingly]
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 arch/arm/crypto/Makefile | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index b37597ad979c..fc5150702b64 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -4,14 +4,25 @@
 
 obj-$(CONFIG_CRYPTO_AES_ARM) += aes-arm.o
 obj-$(CONFIG_CRYPTO_AES_ARM_BS) += aes-arm-bs.o
-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA256_ARM) += sha256-arm.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
-obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
-obj-$(CONFIG_CRYPTO_GHASH_ARM_CE) += ghash-arm-ce.o
+
+ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
+ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
+ce-obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
+ce-obj-$(CONFIG_CRYPTO_GHASH_ARM_CE) += ghash-arm-ce.o
+
+ifneq ($(ce-obj-y)$(ce-obj-m),)
+ifeq ($(call as-instr,.fpu crypto-neon-fp-armv8,y,n),y)
+obj-y += $(ce-obj-y)
+obj-m += $(ce-obj-m)
+else
+$(warning These ARMv8 Crypto Extensions modules need binutils 2.23 or higher)
+$(warning $(ce-obj-y) $(ce-obj-m))
+endif
+endif
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Counter Size in CTR mode for AES Driver

2015-04-11 Thread Sandy Harris 
sri sowj srisowj4li...@gmail.com wrote:

 I have seen multiple open source drivers for AES(CTR) mode for
 different Crypto Hardware Engines, I was not really sure on
 countersize,nonce etc.
 Please can any one provide some info on the following

Not what you asked for, but in case it is useful here is the counter
management code from a version of the random(4) driver that
I am working on:


/*
 * 128-bit counter to mix in when hashing
 /

static u32 iter_count = 0 ;
static spinlock_t counter_lock ;

/*
 * constants are from SHA-1
 * ones in counter[] are used only once, in initialisation
 * then random data is mixed in there
 */
#define COUNTER_DELTA 0x67452301

static u32 counter[] = {0xEFCDAB89, 0x98BADCFE, 0x10325476, 0xC3D2E1F0} ;

/*
 * Code is based on my own work in the Enchilada cipher:
 * https://aezoo.compute.dtu.dk/doku.php?id=enchilada
 *
 * Mix operations so Hamming weight changes more than for a simple
 * counter. This may not be strictly necessary, but a simple counter
 * can be considered safe only if you trust the crypto completely.
 * Low Hamming weight differences in inputs do allow some attacks on
 * block ciphers or hashes and the high bits of a large counter that
 * is only incremented do not change for aeons.
 *
 * The extra code here is cheap insurance.
 * Somewhat nonlinear since it uses +, XOR and rotation.
 *
 * For discussion, see mailing list thread starting at:
 * http://www.metzdowd.com/pipermail/cryptography/2014-May/021345.html
 */
static void count(void)
{
spin_lock( counter_lock ) ;

/*
* Limit the switch to  256 cases
* should work with any CPU  compiler
*
* Five constants used, all primes
* roughly evenly spaced, around 50, 100, 150, 200, 250
*/
switch( iter_count ){
/*
* mix three array elements
* each element is used twice
* once on left, once on right
* pattern is circular
*/
case 47:
counter[1] += counter[2] ;
break ;
case 101:
counter[2] += counter[3] ;
break ;
case 197:
counter[3] += counter[1] ;
break ;
/*
* inject counter[0] into that loop
* loop and counter[0] use +=
* so use ^= here
*/
case 149:
counter[1] ^= counter[0] ;
break ;
/*
* restart loop
* include a rotation for nonlinearity
*/
case 251:
counter[0] = ROTL( counter[0], 5) ;
iter_count = -1 ;
break ;
/*
* for 247 out of every 252 iterations
* the switch does nothing
*/
default:
break ;
}
/*
* counter[0] is almost purely a counter
* uses += instead of ++ to change Hamming weight more
* nothing above affects it, except the rotation
*/
counter[0] += COUNTER_DELTA ;
iter_count++ ;

spin_unlock( counter_lock ) ;
}
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto/arm: accelerated SHA-512 using ARM generic ASM and NEON

2015-04-11 Thread Ard Biesheuvel 

 On 11 apr. 2015, at 10:48, Arnd Bergmann a...@arndb.de wrote:
 
 On Saturday 11 April 2015 09:35:15 Ard Biesheuvel wrote:
 On 10 April 2015 at 22:23, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 
 On 10 apr. 2015, at 22:08, Arnd Bergmann a...@arndb.de wrote:
 
 On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
 +#if __ARM_MAX_ARCH__=7
 +.arch  armv7-a
 +.fpu   neon
 +
 
 This will cause a build failure on an ARMv7-M build, which is incompatible
 with .arch  armv7-a and .fpu   neon.
 
 The neon part depends on CONFIG_KERNEL_MODE_NEON, which would never be set 
 for that platform, I suppose
 
 On second thought, that is not entirely true, but I still don't think
 there is problem here:
 the .arch/.fpu declarations are understood perfectly fine by GAS when
 targeting ARMv7-M. Only, it will emit code that is incompatible with
 it. However, this code is invoked at runtime only if a NEON unit has
 been detected, so it will just be ignored on ARMv7-M
 
 Sorry, I should have collected my findings better when replying to your
 patch. What I remembered was that I saw a problem in this area in linux-next
 with randconfig builds, but I did not notice that it was for a different
 file, and I had not double-checked that patch yet in order to send it
 out.
 
 See below for the patch I'm currently using for my randconfig builder.
 Before you apply this, please check again which files are affected, as
 it's possible that there are other modules that suffer from the same
 problem.
 

Ah i see it now. The new Sha256 module as well as the Sha512 i am proposing 
here both use a single .o containing the !neon and neon implementations, and 
only expose the latter if KERNEL_MODE_NEON. This way, we can use the exact same 
.S file ad OpenSSL, which should mean less maintenance burden.

So your fix seems the most appropriate, even if it means v7m won't be able to 
use the !neon part either.


Arnd
 
 8---
 Subject: [PATCH] ARM: crypto: avoid sha256 code on ARMv7-M
 
 The sha256 assembly implementation can deal with all architecture levels
 from ARMv4 to ARMv7-A, but not with ARMv7-M. Enabling it in an
 ARMv7-M kernel results in this build failure:
 
 arm-linux-gnueabi-ld: error: arch/arm/crypto/sha256_glue.o: Conflicting 
 architecture profiles M/A
 arm-linux-gnueabi-ld: failed to merge target specific data of file 
 arch/arm/crypto/sha256_glue.o
 
 This adds a Kconfig dependency to prevent the code from being disabled
 for ARMv7-M.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 
 diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
 index 458729d2ce22..76463da22f81 100644
 --- a/arch/arm/crypto/Kconfig
 +++ b/arch/arm/crypto/Kconfig
 @@ -49,6 +49,7 @@ config CRYPTO_SHA2_ARM_CE
 config CRYPTO_SHA256_ARM
tristate SHA-224/256 digest algorithm (ARM-asm and NEON)
select CRYPTO_HASH
 +depends on !CPU_V7M
help
  SHA-256 secure hash standard (DFIPS 180-2) implemented
  using optimized ARM assembler and NEON, when available.
 
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: arm: workaround for building with old binutils

2015-04-11 Thread Ard Biesheuvel 

 On 11 apr. 2015, at 10:55, Arnd Bergmann a...@arndb.de wrote:
 
 On Saturday 11 April 2015 09:41:08 Ard Biesheuvel wrote:
 Could you perhaps put the rules that build these modules inside a
 
 ifneq ($(armv8-ce-flags),-DARMV8_CE_DISABLED)
 ...
 endif
 
 How about something like this:
 
 ifeq ($(call as-option,-Wa$(comma)-mfpu=crypto-neon-fp-armv8),)
 $(warning ARMv8 Crypto Extensions need binutils 2.23 or higher)
 else
 ...
 endif
 
 That would basically be a reimplementation of the missing as-option-yn
 macro though, so we could also add that instead and do
 
 ifeq ($(call as-option-yn,-Wa$(comma)-mfpu=crypto-neon-fp-armv8),y)
 $(warning ARMv8 Crypto Extensions need binutils 2.23 or higher)
 else
 ...
 endif
 

Yes, that should work. Could we also move the CE objs to ce-obj-$() and put

ifneq ($(ce-obj-y)$(ce-obj-m),)
if as check
obj-y += $(ce-obj-y)
obj-m += $(ce-obj-m)
else
$(warning ...)
endif
endif

around it so you only get the warning if you have selected any of these modules?

In any case, I strongly prefer to leave the .S files themselves alone if at all 
possible

Ard.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

DO YOU NEED LOAN

2015-04-11 Thread Merchant Finance Loan Services. 
DO YOU NEED LOAN?




--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html