Re: [PATCH] crypto_memcmp: add constant-time memcmp

2013-09-13 Thread Daniel Borkmann

On 09/11/2013 07:20 PM, James Yonan wrote:

On 10/09/2013 12:57, Daniel Borkmann wrote:

There was a similar patch posted some time ago [1] on lkml, where
Florian (CC) made a good point in [2] that future compiler optimizations
could short circuit on this. This issue should probably be addressed in
such a patch here as well.

 [1] https://lkml.org/lkml/2013/2/10/131
 [2] https://lkml.org/lkml/2013/2/11/381


On 11/09/2013 06:19, Marcelo Cerri wrote:

The discussion that Daniel pointed out has another interesting point
regarding the function name. I don't think it's a good idea to name it
crypto_memcpy since it doesn't have behavior the same way as strcmp.

Florian suggested in the thread names such crypto_mem_equal, which I
think fits better here.


Ok, here's another stab at this:

* Changed the name to crypto_mem_not_equal.  The not_equal seems to
make more sense because the function returns a nonzero true value if
the memory regions are not equal.


Ok, sounds good.


* Good point that a smart optimizer might add instructions to
short-circuit the loop if all bits in ret have been set.  One way to
deal with this is to disable optimizations that might increase code
size, since a short-circuit optimization in this case would require
adding instructions.

#pragma GCC optimize (Os)

The nice thing about using #pragma is that older versions of gcc that
don't recognize it will simply ignore it, and we can probably presume
that older versions of gcc do not support a short-circuit optimization
if the latest one does not.  I did a quick test using gcc 3.4.6 at -O2,
and did not see any evidence of a short-circuit optimization.

* Improved performance when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is
enabled.  This makes the performance roughly on-par with memcmp.


Hm, why don't we take fixed-size versions of Daniel J Bernstein from NaCl
library [1], e.g. for comparing hashes?

E.g. for 16 bytes:

int crypto_verify(const unsigned char *x,const unsigned char *y)
{
  unsigned int differentbits = 0;
#define F(i) differentbits |= x[i] ^ y[i];
  F(0)
  F(1)
  F(2)
  F(3)
  F(4)
  F(5)
  F(6)
  F(7)
  F(8)
  F(9)
  F(10)
  F(11)
  F(12)
  F(13)
  F(14)
  F(15)
  return (1  ((differentbits - 1)  8)) - 1;
}

It will return 0 if x[0], x[1], ..., x[15] are the same as y[0], y[1], ..., 
y[15],
otherwise it returns -1. That's w/o for loops, so probably more 
compiler-proof ...

  [1] http://nacl.cr.yp.to/




#pragma GCC optimize (Os)

noinline unsigned long crypto_mem_not_equal(const void *a, const void *b, 
size_t size)
{
 unsigned long ret = 0;

#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
#if BITS_PER_LONG == 64
 while (size = 8) {
 ret |= *(unsigned long *)a ^ *(unsigned long *)b;
 a += 8;
 b += 8;
 size -= 8;
 }
 if (!size)
 return ret;
#endif /* BITS_PER_LONG == 64 */
 if (sizeof(unsigned int) == 4) {
 while (size = 4) {
 ret |= *(unsigned int *)a ^ *(unsigned int *)b;
 a += 4;
 b += 4;
 size -= 4;
 }
 if (!size)
 return ret;
 }
#endif /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
 while (size  0) {
 ret |= *(unsigned char *)a ^ *(unsigned char *)b;
 a += 1;
 b += 1;
 size -= 1;
 }
 return ret;
}

James

--
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: question about rfc404 support.

2013-09-13 Thread Herbert Xu
On Wed, Sep 11, 2013 at 07:16:13PM +, Hsieh, Che-Min wrote:
 Herbert:
 
   Can you confirm the following. Thanks.
 
   Rfc2404 - The Use of HMAC-SHA-1-96 within ESP and AH
  
  For the support, I can't find any algorithm to be specified in the .craname 
 of ahash_alg for Rfc2404.
  
   From 
 http://www.freebsd.org/cgi/man.cgi?query=setkeysektion=8
  it says the following :
 
   ALGORITHMS
  The following list shows the supported algorithms.  The protocol and 
 algorithm are almost completely orthogonal.  The following list of 
 authentication algorithms can be used as aalgo in the -A aalgo of the 
 protocol parameter:
 
  algorithm   keylen (bits)   comment
  
  hmac-sha1   160 ah: rfc2404
  
 
 That leads me to believe, from crypto driver stand point, there is no need to 
 have a new algorithm for hmac-sha-1-96 support.  Instead, the agent SW(such 
 as ipsec) should use  hmac(sha1), and do the truncation of digested data 
 from 160 bits to 96 bits.
 
 I run a quick test. The input file to setkey command is defined as such 
 
 flush;
 spdflush;
 add 10.2.243.75 10.2.243.29 ah 0x604 -A hmac-sha1 
 0x8D967D88F6CAA9D714800AB3D48051D63F73A312;
 add 10.2.243.29 10.2.243.75 ah 0x605 -A hmac-sha1 
 0x8D967D88F6CAA9D714800AB3D48051D63F73A314;
 spdadd 10.2.243.75 10.2.243.29 any -P in ipsec ah/transport//use;
 spdadd 10.2.243.29 10.2.243.75 any -P out ipsec ah/transport//use;
 
 
 I use tcpdump. Clearly I can see 24 bytes of AH header of the ipsec packets.  
 The header has 12 bytes of fixed information  - Next (1), Ah len (1) 
 ,Reserved (2), Spi (4)  ,Sequence  (4),  and Auth result. 
  (12 bytes)
 
 
 Can you confirm the above? Thanks.

Yes, see net/xfrm/xfrm_algo.c.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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


Crypto Fixes for 3.12

2013-09-13 Thread Herbert Xu
Hi Linus:

This push fixes a 7+ year race condition in the crypto API that
causes sporadic crashes when multiple threads load the same
algorithm.

It also fixes the crct10dif algorithm again to prevent boot
failures on systems where the initramfs tool ignores module
softdeps.

Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git

or

master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git


Herbert Xu (2):
  crypto: api - Fix race condition in larval lookup
  crypto: crct10dif - Add fallback for broken initrds

 crypto/Makefile |2 +-
 crypto/api.c|7 +-
 crypto/{crct10dif.c = crct10dif_common.c}  |  100 +--
 crypto/{crct10dif.c = crct10dif_generic.c} |   53 +-
 lib/crc-t10dif.c|   11 ++-
 5 files changed, 20 insertions(+), 153 deletions(-)

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 3/3] crypto: tegra-aes - Staticize tegra_aes_cra_exit

2013-09-13 Thread Sachin Kamat
'tegra_aes_cra_exit' is used only in this file.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
---
 drivers/crypto/tegra-aes.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/tegra-aes.c b/drivers/crypto/tegra-aes.c
index 2d58da9..4f5f715 100644
--- a/drivers/crypto/tegra-aes.c
+++ b/drivers/crypto/tegra-aes.c
@@ -804,7 +804,7 @@ static int tegra_aes_cra_init(struct crypto_tfm *tfm)
return 0;
 }
 
-void tegra_aes_cra_exit(struct crypto_tfm *tfm)
+static void tegra_aes_cra_exit(struct crypto_tfm *tfm)
 {
struct tegra_aes_ctx *ctx =
crypto_ablkcipher_ctx((struct crypto_ablkcipher *)tfm);
-- 
1.7.9.5

--
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 1/3] crypto: mv_cesa - Staticize local symbols

2013-09-13 Thread Sachin Kamat
Local symbols used only in this file are made static.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
 drivers/crypto/mv_cesa.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 3374a3e..f9b9560 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -907,7 +907,7 @@ static int mv_cra_hash_hmac_sha1_init(struct crypto_tfm 
*tfm)
return mv_cra_hash_init(tfm, sha1, COP_HMAC_SHA1, SHA1_BLOCK_SIZE);
 }
 
-irqreturn_t crypto_int(int irq, void *priv)
+static irqreturn_t crypto_int(int irq, void *priv)
 {
u32 val;
 
@@ -928,7 +928,7 @@ irqreturn_t crypto_int(int irq, void *priv)
return IRQ_HANDLED;
 }
 
-struct crypto_alg mv_aes_alg_ecb = {
+static struct crypto_alg mv_aes_alg_ecb = {
.cra_name   = ecb(aes),
.cra_driver_name= mv-ecb-aes,
.cra_priority   = 300,
@@ -951,7 +951,7 @@ struct crypto_alg mv_aes_alg_ecb = {
},
 };
 
-struct crypto_alg mv_aes_alg_cbc = {
+static struct crypto_alg mv_aes_alg_cbc = {
.cra_name   = cbc(aes),
.cra_driver_name= mv-cbc-aes,
.cra_priority   = 300,
@@ -975,7 +975,7 @@ struct crypto_alg mv_aes_alg_cbc = {
},
 };
 
-struct ahash_alg mv_sha1_alg = {
+static struct ahash_alg mv_sha1_alg = {
.init = mv_hash_init,
.update = mv_hash_update,
.final = mv_hash_final,
@@ -999,7 +999,7 @@ struct ahash_alg mv_sha1_alg = {
 }
 };
 
-struct ahash_alg mv_hmac_sha1_alg = {
+static struct ahash_alg mv_hmac_sha1_alg = {
.init = mv_hash_init,
.update = mv_hash_update,
.final = mv_hash_final,
-- 
1.7.9.5

--
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 2/3] crypto: omap-aes - Staticize local symbols

2013-09-13 Thread Sachin Kamat
Local symbols used only in this file are made static.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
 drivers/crypto/omap-aes.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce791c2..e1e58d0 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -554,7 +554,7 @@ static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
return err;
 }
 
-int omap_aes_check_aligned(struct scatterlist *sg)
+static int omap_aes_check_aligned(struct scatterlist *sg)
 {
while (sg) {
if (!IS_ALIGNED(sg-offset, 4))
@@ -566,7 +566,7 @@ int omap_aes_check_aligned(struct scatterlist *sg)
return 0;
 }
 
-int omap_aes_copy_sgs(struct omap_aes_dev *dd)
+static int omap_aes_copy_sgs(struct omap_aes_dev *dd)
 {
void *buf_in, *buf_out;
int pages;
-- 
1.7.9.5

--
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: sha256_ssse3 - use correct module alias for sha224

2013-09-13 Thread Herbert Xu
On Tue, Sep 03, 2013 at 04:26:49PM +0300, Jussi Kivilinna wrote:
 Commit a710f761f (crypto: sha256_ssse3 - add sha224 support) attempted to add
 MODULE_ALIAS for SHA-224, but it ended up being sha384, probably because
 mix-up with previous commit 340991e30 (crypto: sha512_ssse3 - add sha384
 support). Patch corrects module alias to sha224.
 
 Reported-by: Pierre-Mayeul Badaire pierre-mayeul.bada...@m4x.org
 Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi

Patch applied.  Thanks.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: x86: restore avx2_supported check

2013-09-13 Thread Herbert Xu
On Tue, Sep 03, 2013 at 04:49:47PM +0300, Jussi Kivilinna wrote:
 Commit 3d387ef08c4 (Revert crypto: blowfish - add AVX2/x86_64 implementation
 of blowfish cipher) reverted too much as it removed the 'assembler supports
 AVX2' check and therefore disabled remaining AVX2 implementations of Camellia
 and Serpent. Patch restores the check and enables these implementations.
 
 Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi

Also applied.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 0/7] crypto: caam - RNG4 patches and fixes

2013-09-13 Thread Herbert Xu
On Mon, Sep 09, 2013 at 06:56:27PM +0300, Alex Porosanu wrote:
 This patch series attempts to fix some identified issues and add some new
 functionalities regarding the RNG4 block in the CAAM driver:
 o if the CAAM driver isn't properly instantiated (e.g. RNG4 initialization
   fails), then there's an illegal memory access generated by the modules
   depending on it; patch 1 in the patch-set fixes this;
 o if the CAAM module is removed, the state handles are not uninstantiated;
   patch 3  in the patch-set adds the necessary descriptor to uninstantiate
   state handle 0;
 o the RNG4 block in CAAM needs to be 'seeded' first before being used
   for generating pseudo-random data. The 'seeding' is done by getting
   entropy from the TRNG ring oscillator. The RTFRQMAX register controls
   the maximum allowable number of samples that can be acquired during
   an entropy sample. Depending on the clock at which the RNG4 block
   (and for that matter the SEC block) runs, it's possible that a
   hard-coded value for the maximum frequency is inadequate, i.e. more
   samples than needed are taken. This leads to failures on devices
   like BSC913x. Patch number 2 fixes this issue by using a kind of
   a software loop to increase the maximum number of samples taken
   until the state handle can be properly initialized; o there are two
   state handles present in the RNG4 block and only one
   is initialized; patch 5 in the patch-set fixes this issue, also
   adding the necessary code for deinstantiation only the handles that were
   instantiated by the driver.

All applied.  Thanks.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: tegra: use kernel entropy instead of ad-hoc

2013-09-13 Thread Herbert Xu
On Mon, Sep 09, 2013 at 10:02:04AM -0600, Stephen Warren wrote:
 On 09/09/2013 01:35 AM, Linus Walleij wrote:
  The way I read the Tegra AES RNG is that it has a homebrew
  algorithm for initializing the 128bit RNG using timespec and
  the unique chip ID. This looks like reinventing the (square)
  wheel, instead just grab 128bits from the kernel entropy pool
  where the time and (after another patch) chip unique ID is
  already mixed in.
  
  Incidentally this also gets rid of a rather ugly
  cross-dependence on the machine using an extern declaration.
 
 This sounds reasonable to me, although I know little about the driver.
 Varun, can you please comment?
 
 Acked-by: Stephen Warren swar...@nvidia.com

Patch applied.  Thanks.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: [3.12-rc1] Dependency on module-init-tools = 3.11 ?

2013-09-13 Thread Tetsuo Handa
Waiman Long wrote:
 I would like to report that I also have the same boot problem on a 
 RHEL6.4 box with the crypto patch. My workaround is to force kernel 
 build to have the crc_t10dif code built-in by changing the config file:
 
 4889c4889
  CONFIG_CRYPTO_CRCT10DIF=m
 ---
   CONFIG_CRYPTO_CRCT10DIF=y
 5002c5002
  CONFIG_CRC_T10DIF=m
 ---
   CONFIG_CRC_T10DIF=y
 
 This solved the boot problem without any additional patch.  Do you think 
 you should consider changing the configuration default to y instead of 
 m or doesn't allow the m option at all?

That was proposed but not accepted.
https://lkml.org/lkml/2013/7/17/543

You should choose CONFIG_CRYPTO_CRCT10DIF_PCLMUL=y in your kernel config
if your CPU supports PCLMULQDQ.
--
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: Crypto Fixes for 3.12

2013-09-13 Thread Linus Torvalds
On Fri, Sep 13, 2013 at 4:30 AM, Herbert Xu herb...@gondor.apana.org.au wrote:

 Herbert Xu (2):
   crypto: api - Fix race condition in larval lookup
   crypto: crct10dif - Add fallback for broken initrds

  crypto/Makefile |2 +-
  crypto/api.c|7 +-
  crypto/{crct10dif.c = crct10dif_common.c}  |  100 
 +--
  crypto/{crct10dif.c = crct10dif_generic.c} |   53 +-
  lib/crc-t10dif.c|   11 ++-
  5 files changed, 20 insertions(+), 153 deletions(-)

Please fix your script. You apparently have it using -C to find
copies, which can be very useful to see what is going on especially
with --summary (which you don't have), but is misleading when
sending diffstats when people don't expect it.

The pull request does not have 20 insertions, it has 146
insertions, and it's just that a fair chunk of them come from a file
being essentially duplicated. See the difference:

With copy detection (git diff -C --stat --summary)
 crypto/Makefile |   2 +-
 crypto/api.c|   7 +-
 crypto/{crct10dif.c = crct10dif_common.c}  | 100 +---
 crypto/{crct10dif.c = crct10dif_generic.c} |  53 +--
 lib/crc-t10dif.c|  11 ++-
 5 files changed, 20 insertions(+), 153 deletions(-)
 copy crypto/{crct10dif.c = crct10dif_common.c} (63%)
 rename crypto/{crct10dif.c = crct10dif_generic.c} (55%)

With just rename detection (git diff -M --stat --summary)
 crypto/Makefile|   2 +-
 crypto/api.c   |   7 +-
 crypto/{crct10dif.c = crct10dif_common.c} | 100 +---
 crypto/crct10dif_generic.c | 127 +
 lib/crc-t10dif.c   |  11 +-
 5 files changed, 146 insertions(+), 101 deletions(-)
 rename crypto/{crct10dif.c = crct10dif_common.c} (63%)
 create mode 100644 crypto/crct10dif_generic.c

and your pull request looked really misleading because it did -C but
didn't have that summary pointing out that one of them was a copy.

So please use -M --stat --summary. That's what git shows me when I
do a git pull, so that's what I'm going to compare with..

As mentioned -C _is_ useful, but it's useful when you're
specifically looking for that's a lot of new lines, is it copying old
files kind of things.

  Linus
--
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: Crypto Fixes for 3.12

2013-09-13 Thread Herbert Xu
On Fri, Sep 13, 2013 at 07:22:55AM -0700, Linus Torvalds wrote:
 On Fri, Sep 13, 2013 at 4:30 AM, Herbert Xu herb...@gondor.apana.org.au 
 wrote:
 
  Herbert Xu (2):
crypto: api - Fix race condition in larval lookup
crypto: crct10dif - Add fallback for broken initrds
 
   crypto/Makefile |2 +-
   crypto/api.c|7 +-
   crypto/{crct10dif.c = crct10dif_common.c}  |  100 
  +--
   crypto/{crct10dif.c = crct10dif_generic.c} |   53 +-
   lib/crc-t10dif.c|   11 ++-
   5 files changed, 20 insertions(+), 153 deletions(-)
 
 Please fix your script. You apparently have it using -C to find
 copies, which can be very useful to see what is going on especially
 with --summary (which you don't have), but is misleading when
 sending diffstats when people don't expect it.

Sorry, will do for future pushes.  FWIW the -M stats are

 crypto/Makefile|2 +-
 crypto/api.c   |7 +-
 crypto/{crct10dif.c = crct10dif_common.c} |  100 +-
 crypto/crct10dif_generic.c |  127 
 lib/crc-t10dif.c   |   11 ++-
 5 files changed, 146 insertions(+), 101 deletions(-)
 
 With just rename detection (git diff -M --stat --summary)
  crypto/Makefile|   2 +-
  crypto/api.c   |   7 +-
  crypto/{crct10dif.c = crct10dif_common.c} | 100 +---
  crypto/crct10dif_generic.c | 127 +
  lib/crc-t10dif.c   |  11 +-
  5 files changed, 146 insertions(+), 101 deletions(-)
  rename crypto/{crct10dif.c = crct10dif_common.c} (63%)
  create mode 100644 crypto/crct10dif_generic.c

Thanks,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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


[RFC PATCH 0/2] AES in CBC/CTR/XTS modes using ARMv8 Crypto Extensions

2013-09-13 Thread Ard Biesheuvel
Hello all,

This is a first attempt at getting something implemented that uses the ARMv8
crypto extensions for performing AES encryption in CBC, CTR and XTS modes.

The first patch moves the ablk helper code out of arch/x86. This code is used
to automagically instantiate async blkciphers based on the synchronous ones in
my implementation.

The second patch contains the actual AES code. Note that this is only compile
tested, there are most likely numerous bugs that need to be shaken out before
this will even run, so consider yourselves warned.

Comments highly appreciated,

Regards,
Ard.


Ard Biesheuvel (2):
  crypto: move ablk_helper out of arch/x86
  arm64: add support for AES using ARMv8 Crypto Extensions

 arch/arm64/Makefile|   8 +-
 arch/arm64/crypto/Makefile |  12 +
 arch/arm64/crypto/aesce-cbc.S  |  58 +
 arch/arm64/crypto/aesce-ctr.S  |  83 +++
 arch/arm64/crypto/aesce-glue.c | 352 +
 arch/arm64/crypto/aesce-macros.S   |  95 
 arch/arm64/crypto/aesce-xts.S  | 129 +++
 arch/x86/crypto/Makefile   |   1 -
 arch/x86/crypto/ablk_helper.c  | 149 
 arch/x86/crypto/aesni-intel_glue.c |   2 +-
 arch/x86/crypto/camellia_aesni_avx2_glue.c |   2 +-
 arch/x86/crypto/camellia_aesni_avx_glue.c  |   2 +-
 arch/x86/crypto/cast5_avx_glue.c   |   2 +-
 arch/x86/crypto/cast6_avx_glue.c   |   2 +-
 arch/x86/crypto/serpent_avx2_glue.c|   2 +-
 arch/x86/crypto/serpent_avx_glue.c |   2 +-
 arch/x86/crypto/serpent_sse2_glue.c|   2 +-
 arch/x86/crypto/twofish_avx_glue.c |   2 +-
 arch/x86/include/asm/crypto/ablk_helper.h  |  31 ---
 crypto/Kconfig |  28 ++-
 crypto/Makefile|   4 +
 crypto/ablk_helper_generic.c   | 155 +
 crypto/ablk_helper_x86.c   |   8 +
 include/crypto/ablk_helper.h   |  34 +++
 24 files changed, 961 insertions(+), 204 deletions(-)
 create mode 100644 arch/arm64/crypto/Makefile
 create mode 100644 arch/arm64/crypto/aesce-cbc.S
 create mode 100644 arch/arm64/crypto/aesce-ctr.S
 create mode 100644 arch/arm64/crypto/aesce-glue.c
 create mode 100644 arch/arm64/crypto/aesce-macros.S
 create mode 100644 arch/arm64/crypto/aesce-xts.S
 delete mode 100644 arch/x86/crypto/ablk_helper.c
 delete mode 100644 arch/x86/include/asm/crypto/ablk_helper.h
 create mode 100644 crypto/ablk_helper_generic.c
 create mode 100644 crypto/ablk_helper_x86.c
 create mode 100644 include/crypto/ablk_helper.h

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


[RFC PATCH 1/2] crypto: move ablk_helper out of arch/x86

2013-09-13 Thread Ard Biesheuvel
Move the ablk_helper code out of arch/x86 so it can be reused
by other architectures. The only x86 specific dependency was
a call to irq_fpu_usable(), this has been factored out and moved
to crypto/ablk_helper_x86.c

Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 arch/x86/crypto/Makefile   |   1 -
 arch/x86/crypto/ablk_helper.c  | 149 ---
 arch/x86/crypto/aesni-intel_glue.c |   2 +-
 arch/x86/crypto/camellia_aesni_avx2_glue.c |   2 +-
 arch/x86/crypto/camellia_aesni_avx_glue.c  |   2 +-
 arch/x86/crypto/cast5_avx_glue.c   |   2 +-
 arch/x86/crypto/cast6_avx_glue.c   |   2 +-
 arch/x86/crypto/serpent_avx2_glue.c|   2 +-
 arch/x86/crypto/serpent_avx_glue.c |   2 +-
 arch/x86/crypto/serpent_sse2_glue.c|   2 +-
 arch/x86/crypto/twofish_avx_glue.c |   2 +-
 arch/x86/include/asm/crypto/ablk_helper.h  |  31 --
 crypto/Kconfig |  21 ++--
 crypto/Makefile|   4 +
 crypto/ablk_helper_generic.c   | 155 +
 crypto/ablk_helper_x86.c   |   8 ++
 include/crypto/ablk_helper.h   |  34 +++
 17 files changed, 220 insertions(+), 201 deletions(-)
 delete mode 100644 arch/x86/crypto/ablk_helper.c
 delete mode 100644 arch/x86/include/asm/crypto/ablk_helper.h
 create mode 100644 crypto/ablk_helper_generic.c
 create mode 100644 crypto/ablk_helper_x86.c
 create mode 100644 include/crypto/ablk_helper.h

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 7d6ba9d..18fda50 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -4,7 +4,6 @@
 
 avx_supported := $(call as-instr,vpxor %xmm0$(comma)%xmm0$(comma)%xmm0,yes,no)
 
-obj-$(CONFIG_CRYPTO_ABLK_HELPER_X86) += ablk_helper.o
 obj-$(CONFIG_CRYPTO_GLUE_HELPER_X86) += glue_helper.o
 
 obj-$(CONFIG_CRYPTO_AES_586) += aes-i586.o
diff --git a/arch/x86/crypto/ablk_helper.c b/arch/x86/crypto/ablk_helper.c
deleted file mode 100644
index 43282fe..000
--- a/arch/x86/crypto/ablk_helper.c
+++ /dev/null
@@ -1,149 +0,0 @@
-/*
- * Shared async block cipher helpers
- *
- * Copyright (c) 2012 Jussi Kivilinna jussi.kivili...@mbnet.fi
- *
- * Based on aesni-intel_glue.c by:
- *  Copyright (C) 2008, Intel Corp.
- *Author: Huang Ying ying.hu...@intel.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
- *
- */
-
-#include linux/kernel.h
-#include linux/crypto.h
-#include linux/init.h
-#include linux/module.h
-#include crypto/algapi.h
-#include crypto/cryptd.h
-#include asm/i387.h
-#include asm/crypto/ablk_helper.h
-
-int ablk_set_key(struct crypto_ablkcipher *tfm, const u8 *key,
-unsigned int key_len)
-{
-   struct async_helper_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-   struct crypto_ablkcipher *child = ctx-cryptd_tfm-base;
-   int err;
-
-   crypto_ablkcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
-   crypto_ablkcipher_set_flags(child, crypto_ablkcipher_get_flags(tfm)
-CRYPTO_TFM_REQ_MASK);
-   err = crypto_ablkcipher_setkey(child, key, key_len);
-   crypto_ablkcipher_set_flags(tfm, crypto_ablkcipher_get_flags(child)
-CRYPTO_TFM_RES_MASK);
-   return err;
-}
-EXPORT_SYMBOL_GPL(ablk_set_key);
-
-int __ablk_encrypt(struct ablkcipher_request *req)
-{
-   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
-   struct async_helper_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-   struct blkcipher_desc desc;
-
-   desc.tfm = cryptd_ablkcipher_child(ctx-cryptd_tfm);
-   desc.info = req-info;
-   desc.flags = 0;
-
-   return crypto_blkcipher_crt(desc.tfm)-encrypt(
-   desc, req-dst, req-src, req-nbytes);
-}
-EXPORT_SYMBOL_GPL(__ablk_encrypt);
-
-int ablk_encrypt(struct ablkcipher_request *req)
-{
-   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
-   struct async_helper_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-
-   if (!irq_fpu_usable()) {
-   struct ablkcipher_request *cryptd_req =
-   ablkcipher_request_ctx(req);
-
-   memcpy(cryptd_req, req, sizeof(*req));
-   ablkcipher_request_set_tfm(cryptd_req, 

[RFC PATCH 2/2] arm64: add support for AES using ARMv8 Crypto Extensions

2013-09-13 Thread Ard Biesheuvel
This adds ARMv8 Crypto Extensions based implemenations of
AES in CBC, CTR and XTS mode.

Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 arch/arm64/Makefile  |   8 +-
 arch/arm64/crypto/Makefile   |  12 ++
 arch/arm64/crypto/aesce-cbc.S|  58 +++
 arch/arm64/crypto/aesce-ctr.S|  83 +
 arch/arm64/crypto/aesce-glue.c   | 352 +++
 arch/arm64/crypto/aesce-macros.S |  95 +++
 arch/arm64/crypto/aesce-xts.S| 129 ++
 crypto/Kconfig   |   7 +
 8 files changed, 741 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/crypto/Makefile
 create mode 100644 arch/arm64/crypto/aesce-cbc.S
 create mode 100644 arch/arm64/crypto/aesce-ctr.S
 create mode 100644 arch/arm64/crypto/aesce-glue.c
 create mode 100644 arch/arm64/crypto/aesce-macros.S
 create mode 100644 arch/arm64/crypto/aesce-xts.S

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index d90cf79..c7d4959 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -36,9 +36,11 @@ TEXT_OFFSET := 0x0008
 
 export TEXT_OFFSET GZFLAGS
 
-core-y += arch/arm64/kernel/ arch/arm64/mm/
-core-$(CONFIG_KVM) += arch/arm64/kvm/
-core-$(CONFIG_XEN) += arch/arm64/xen/
+core-y += arch/arm64/kernel/ arch/arm64/mm/
+core-$(CONFIG_KVM) += arch/arm64/kvm/
+core-$(CONFIG_XEN) += arch/arm64/xen/
+core-$(CONFIG_CRYPTO)  += arch/arm64/crypto/
+
 libs-y := arch/arm64/lib/ $(libs-y)
 libs-y += $(LIBGCC)
 
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
new file mode 100644
index 000..da1a437
--- /dev/null
+++ b/arch/arm64/crypto/Makefile
@@ -0,0 +1,12 @@
+#
+# linux/arch/arm64/crypto/Makefile
+#
+# Copyright (C) 2013 Linaro Ltd ard.biesheu...@linaro.org
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+
+aes-arm64ce-y := aesce-cbc.o aesce-ctr.o aesce-xts.o aesce-glue.o
+obj-$(CONFIG_CRYPTO_AES_ARM64CE) += aes-arm64ce.o
diff --git a/arch/arm64/crypto/aesce-cbc.S b/arch/arm64/crypto/aesce-cbc.S
new file mode 100644
index 000..d955bf2
--- /dev/null
+++ b/arch/arm64/crypto/aesce-cbc.S
@@ -0,0 +1,58 @@
+/*
+ * linux/arch/arm64/crypto/aesce-cbc.S - AES-CBC using ARMv8 crypto extensions
+ *
+ * Copyright (C) 2013 Linaro Ltd ard.biesheu...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/linkage.h
+
+#include aesce-macros.S
+
+   .text
+   .arch   armv8-a+crypto
+
+   // aesce_cbc_encrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
+   //   int blocks, u8 iv[], int first)
+   // aesce_cbc_decrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
+   //   int blocks, u8 iv[], int first)
+
+ENTRY(aesce_cbc_encrypt)
+   tst w6, #1
+   beq .Lencloop
+
+   ld1 {v2.16b}, [x5]  // get iv
+   load_round_keys w3, x2
+
+.Lencloop:
+   ld1 {v1.16b}, [x1], #16 // get next pt block
+   eor v0.16b, v1.16b, v2.16b  // ... and xor with iv
+   encrypt_block   v2.16b, v0.16b, w3
+   st1 {v2.16b}, [x0], #16
+   subsw4, w4, #1
+   bne .Lencloop
+   ret
+ENDPROC(aesce_cbc_encrypt)
+
+
+ENTRY(aesce_cbc_decrypt)
+   tst w6, #1
+   beq .Ldecloop
+
+   ld1 {v3.16b}, [x5]  // get iv
+   load_round_keys w3, x2
+
+.Ldecloop:
+   ld1 {v1.16b}, [x1], #16 // get next ct block
+   mov v0.16b, v1.16b  // ... and copy to v0
+   decrypt_block   v2.16b, v0.16b, w3
+   eor v0.16b, v2.16b, v3.16b  // xor with iv to get pt
+   mov v3.16b, v1.16b  // ct is next round's iv
+   st1 {v0.16b}, [x0], #16
+   subsw4, w4, #1
+   bne .Ldecloop
+   ret
+ENDPROC(aesce_cbc_decrypt)
diff --git a/arch/arm64/crypto/aesce-ctr.S b/arch/arm64/crypto/aesce-ctr.S
new file mode 100644
index 000..5b5f02f
--- /dev/null
+++ b/arch/arm64/crypto/aesce-ctr.S
@@ -0,0 +1,83 @@
+/*
+ * linux/arch/arm64/crypto/aesce-ctr.S - AES-CTR using ARMv8 crypto extensions
+ *
+ * Copyright (C) 2013 Linaro Ltd ard.biesheu...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/linkage.h
+
+#include aesce-macros.S
+
+   .text
+   .arch   armv8-a+crypto
+
+   // 

Re: [PATCH] crypto: tegra: use kernel entropy instead of ad-hoc

2013-09-13 Thread Stephen Warren
On 09/13/2013 06:23 AM, Herbert Xu wrote:
 On Mon, Sep 09, 2013 at 10:02:04AM -0600, Stephen Warren wrote:
 On 09/09/2013 01:35 AM, Linus Walleij wrote:
 The way I read the Tegra AES RNG is that it has a homebrew
 algorithm for initializing the 128bit RNG using timespec and
 the unique chip ID. This looks like reinventing the (square)
 wheel, instead just grab 128bits from the kernel entropy pool
 where the time and (after another patch) chip unique ID is
 already mixed in.

 Incidentally this also gets rid of a rather ugly
 cross-dependence on the machine using an extern declaration.

 This sounds reasonable to me, although I know little about the driver.
 Varun, can you please comment?

 Acked-by: Stephen Warren swar...@nvidia.com
 
 Patch applied.  Thanks.

I'm curious which kernel version it was merged for; it'd be nice to
remove tegra_chip_uid() from the Tegra tree now since it's unused, but
that obviously requires this patch in the history.
--
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