Re: linux-next: build warnings after merge of the crypto tree

2015-03-09 Thread Stephen Rothwell 
Hi Herbert,

On Tue, 10 Mar 2015 17:03:28 +1100 Herbert Xu  
wrote:
>
> On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the crypto tree, today's (and the past few days)
> > linux-next build (powerpc allyesconfig) produced these warnings:
> > 
> > crypto/algif_aead.c:561:2: warning: initialization from incompatible 
> > pointer type
> >   .sendmsg = aead_sendmsg,
> >   ^
> > crypto/algif_aead.c:561:2: warning: (near initialization for 
> > 'algif_aead_ops.sendmsg')
> > crypto/algif_aead.c:563:2: warning: initialization from incompatible 
> > pointer type
> >   .recvmsg = aead_recvmsg,
> >   ^
> > crypto/algif_aead.c:563:2: warning: (near initialization for 
> > 'algif_aead_ops.recvmsg')
> > 
> > Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").
> 
> This is a bit of a bummer.  What happened is that net-next has
> killed the kiocb argument to sendmsg/recvmsg.  However, this
> change is obviously not part of the crypto tree and algif_aead
> only exists in the crypto tree.
> 
> So Stephen could you fix this by hand until one of them is merged
> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

No worries, I will put a merge fix patch in from tomorrow (and send you
a copy just in case).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpPsv3ae1G7P.pgp
Description: OpenPGP digital signature

Re: linux-next: build warnings after merge of the crypto tree

2015-03-09 Thread Herbert Xu 
On Tue, Mar 10, 2015 at 04:44:17PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> After merging the crypto tree, today's (and the past few days)
> linux-next build (powerpc allyesconfig) produced these warnings:
> 
> crypto/algif_aead.c:561:2: warning: initialization from incompatible pointer 
> type
>   .sendmsg = aead_sendmsg,
>   ^
> crypto/algif_aead.c:561:2: warning: (near initialization for 
> 'algif_aead_ops.sendmsg')
> crypto/algif_aead.c:563:2: warning: initialization from incompatible pointer 
> type
>   .recvmsg = aead_recvmsg,
>   ^
> crypto/algif_aead.c:563:2: warning: (near initialization for 
> 'algif_aead_ops.recvmsg')
> 
> Introduced by commit 400c40cf78da ("crypto: algif - add AEAD support").

This is a bit of a bummer.  What happened is that net-next has
killed the kiocb argument to sendmsg/recvmsg.  However, this
change is obviously not part of the crypto tree and algif_aead
only exists in the crypto tree.

So Stephen could you fix this by hand until one of them is merged
upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

Thanks!
-- 
Email: Herbert Xu 
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 net-next v2 0/2] net: Remove iocb argument from sendmsg and recvmsg

2015-03-09 Thread Herbert Xu 
David Miller  wrote:
> From: Ying Xue 
> Date: Mon, 2 Mar 2015 15:37:46 +0800
> 
>> Currently there is only one user - TIPC whose sendmsg() instances
>> using iocb argument. Meanwhile, there is no user using iocb argument
>> in its recvmsg() instance. Therefore, if we eliminate the werid usage
>> of iobc argument from TIPC, the iocb argument can be removed from
>> all sendmsg() and recvmsg() instances of the whole networking stack.
>> 
>> Reference:
>> https://patchwork.ozlabs.org/patch/433960/
>> 
>> Changes:
>> 
>> v2:
>>  * Fix compile errors of DCCP module pointed by David
> 
> Series applied, thanks.

This totally breaks Tadeusz Struk's attempt at making an AIO
interface for algif_skcipher:

https://patchwork.kernel.org/patch/5971491/

Now granted nothing in the network stack ever supported AIO so
maybe this is a bad idea anyway.  But I guess it's a good time
and place to discuss what alternatives are available for Tadeus
to export his crypto hardware using an asynchronous interface
to user-space?

Cheers,
-- 
Email: Herbert Xu 
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 v2 15/17] crypto: talitos - Implementation of SEC1

2015-03-09 Thread Kim Phillips 
On Fri, 6 Mar 2015 17:42:26 +0100
Christophe Leroy  wrote:

> This patch adds talitos1.c and talitos1.h with all specificities needed
> to handle the SEC1 security engine found in MPC885 and MPC8272.
> 
> The SEC1 has several differences with its younger brother SEC2:
> * Several bits in registers have different locations
> * Many bits are missing
> * Some bits are in addition
> * SEC1 doesn't support scatter/gather
> * SEC1 has a different descriptor structure
> 
> We add a helper function for clearing the desc field in the descriptor as 
> that field needs to be cleared on SEC1 and doesn't exist on SEC2.
> 
> Signed-off-by: Christophe Leroy 

Hi Christophe,

Thanks for rebasing on cryptodev-2.6, now I can easily see the
differences for review.

> +++ b/drivers/crypto/Kconfig
> @@ -211,7 +211,8 @@ config CRYPTO_DEV_TALITOS
>   select CRYPTO_ALGAPI
>   select CRYPTO_AUTHENC
>   select HW_RANDOM
> - select CRYPTO_DEV_TALITOS2
> + select CRYPTO_DEV_TALITOS1 if PPC_8xx || PPC_82xx
> + select CRYPTO_DEV_TALITOS2 if !CRYPTO_DEV_TALITOS1

This will set CONFIG_CRYPTO_DEV_TALITOS1=y on a kernel with both
PPC_82xx and PPC_83xx set, and will therefore break talitos when run
on an 83xx part.

The driver needs to work on both v1 and v2/3 SECs dynamically,
and behave accordingly depending on what version h/w is described in
the device tree ("fsl,secX").

So, barring making a completely new driver, a couple of points:

- A h/w version 1 vs 2 compatible priv variable can be allocated for
parts of the driver that need quicker access than calling
of_device_is_compatible().  Other parts that do better as complete
function rewrites (the scatter-gather mapping fns?) can be
abstracted away using pointers to the v1 vs. v2+ base functions.
The pointers would live in the device's priv struct, and be assigned
at module initialization time.

- instead of rewriting the structs talitos_ptr, talitos_desc, either
use the v2-named member as-is, or make unions.

E.g., instead of having a new struct talitos_ptr, either use the v2
h/w version as-is and shift the length into place, or, add a v1 len
via a union, and make to_talitos_ptr a pointer to a function, with
the v1 version of the function updating only the v1 len.

For struct talitos_desc, how about:

struct talitos_desc {
__be32 hdr;
struct talitos_ptr[8];
}

and have the desc->ptr[X] assigning code add 1 via a new macro iff
on a SEC2 compatible (the hdr_lo code would have to be hardcoded to
refer to ptr[0] instead of hdr_lo directly, and next_desc would be
ptr[7]).

talitos_edesc shouldn't need the extra ptr_{in,out}, rather allocate
the extra space when they're needed, and refer to them via aliases
to defines that cast and use link_tbl[0] as a base reference.

For IO register accesses, either a lookup table can be used, or,
since they're not frequent, define v1-specific defines in addition
to the v2 ones, and reference using the compatible variable.

Other than that, please make sure to use checkpatch.pl --strict,
sparse -D__CHECK_ENDIAN__, and that building as a module doesn't
break.

Thanks,

Kim
--
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 v2 1/2] crypto: af_alg - Allow to link sgl

2015-03-09 Thread Tadeusz Struk 
Allow to link af_alg sgls.

Signed-off-by: Tadeusz Struk 
---
 crypto/af_alg.c |   18 +-
 include/crypto/if_alg.h |4 +++-
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 7f8b7edc..26089d1 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -358,8 +358,8 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter 
*iter, int len)
npages = (off + n + PAGE_SIZE - 1) >> PAGE_SHIFT;
if (WARN_ON(npages == 0))
return -EINVAL;
-
-   sg_init_table(sgl->sg, npages);
+   /* Add one extra for linking */
+   sg_init_table(sgl->sg, npages + 1);
 
for (i = 0, len = n; i < npages; i++) {
int plen = min_t(int, len, PAGE_SIZE - off);
@@ -369,18 +369,26 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct 
iov_iter *iter, int len)
off = 0;
len -= plen;
}
+   sg_mark_end(sgl->sg + npages - 1);
+   sgl->npages = npages;
+
return n;
 }
 EXPORT_SYMBOL_GPL(af_alg_make_sg);
 
+void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new)
+{
+   sg_unmark_end(sgl_prev->sg + sgl_prev->npages - 1);
+   sg_chain(sgl_prev->sg, sgl_prev->npages + 1, sgl_new->sg);
+}
+EXPORT_SYMBOL(af_alg_link_sg);
+
 void af_alg_free_sg(struct af_alg_sgl *sgl)
 {
int i;
 
-   i = 0;
-   do {
+   for (i = 0; i < sgl->npages; i++)
put_page(sgl->pages[i]);
-   } while (!sg_is_last(sgl->sg + (i++)));
 }
 EXPORT_SYMBOL_GPL(af_alg_free_sg);
 
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 178525e..018afb2 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -58,8 +58,9 @@ struct af_alg_type {
 };
 
 struct af_alg_sgl {
-   struct scatterlist sg[ALG_MAX_PAGES];
+   struct scatterlist sg[ALG_MAX_PAGES + 1];
struct page *pages[ALG_MAX_PAGES];
+   unsigned int npages;
 };
 
 int af_alg_register_type(const struct af_alg_type *type);
@@ -70,6 +71,7 @@ int af_alg_accept(struct sock *sk, struct socket *newsock);
 
 int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter *iter, int len);
 void af_alg_free_sg(struct af_alg_sgl *sgl);
+void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new);
 
 int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con);
 

--
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 v2 2/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-09 Thread Tadeusz Struk 
The way the algif_skcipher works currently is that on sendmsg/sendpage it
builds an sgl for the input data and then on read/recvmsg it sends the job
for encryption putting the user to sleep till the data is processed.
This way it can only handle one job at a given time.
This patch changes it to be asynchronous by adding AIO support.

Signed-off-by: Tadeusz Struk 
---
 crypto/algif_skcipher.c |  233 ++-
 1 file changed, 226 insertions(+), 7 deletions(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 0c8a1e5..790ed35 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -39,6 +39,7 @@ struct skcipher_ctx {
 
struct af_alg_completion completion;
 
+   atomic_t inflight;
unsigned used;
 
unsigned int len;
@@ -49,9 +50,65 @@ struct skcipher_ctx {
struct ablkcipher_request req;
 };
 
+struct skcipher_async_rsgl {
+   struct af_alg_sgl sgl;
+   struct list_head list;
+};
+
+struct skcipher_async_req {
+   struct kiocb *iocb;
+   struct skcipher_async_rsgl first_sgl;
+   struct list_head list;
+   struct scatterlist *tsg;
+   char iv[];
+};
+
+#define GET_SREQ(areq, ctx) (struct skcipher_async_req *)((char *)areq + \
+   crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(&ctx->req)))
+
+#define GET_REQ_SIZE(ctx) \
+   crypto_ablkcipher_reqsize(crypto_ablkcipher_reqtfm(&ctx->req))
+
+#define GET_IV_SIZE(ctx) \
+   crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(&ctx->req))
+
 #define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
  sizeof(struct scatterlist) - 1)
 
+static void skcipher_free_async_sgls(struct skcipher_async_req *sreq)
+{
+   struct skcipher_async_rsgl *rsgl, *tmp;
+   struct scatterlist *sgl;
+   struct scatterlist *sg;
+   int i, n;
+
+   list_for_each_entry_safe(rsgl, tmp, &sreq->list, list) {
+   af_alg_free_sg(&rsgl->sgl);
+   if (rsgl != &sreq->first_sgl)
+   kfree(rsgl);
+   }
+   sgl = sreq->tsg;
+   n = sg_nents(sgl);
+   for_each_sg(sgl, sg, n, i)
+   put_page(sg_page(sg));
+
+   kfree(sreq->tsg);
+}
+
+static void skcipher_async_cb(struct crypto_async_request *req, int err)
+{
+   struct sock *sk = req->data;
+   struct alg_sock *ask = alg_sk(sk);
+   struct skcipher_ctx *ctx = ask->private;
+   struct skcipher_async_req *sreq = GET_SREQ(req, ctx);
+   struct kiocb *iocb = sreq->iocb;
+
+   atomic_dec(&ctx->inflight);
+   skcipher_free_async_sgls(sreq);
+   kfree(req);
+   aio_complete(iocb, err, err);
+}
+
 static inline int skcipher_sndbuf(struct sock *sk)
 {
struct alg_sock *ask = alg_sk(sk);
@@ -96,7 +153,7 @@ static int skcipher_alloc_sgl(struct sock *sk)
return 0;
 }
 
-static void skcipher_pull_sgl(struct sock *sk, int used)
+static void skcipher_pull_sgl(struct sock *sk, int used, int put)
 {
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask->private;
@@ -123,8 +180,8 @@ static void skcipher_pull_sgl(struct sock *sk, int used)
 
if (sg[i].length)
return;
-
-   put_page(sg_page(sg + i));
+   if (put)
+   put_page(sg_page(sg + i));
sg_assign_page(sg + i, NULL);
}
 
@@ -143,7 +200,7 @@ static void skcipher_free_sgl(struct sock *sk)
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask->private;
 
-   skcipher_pull_sgl(sk, ctx->used);
+   skcipher_pull_sgl(sk, ctx->used, 1);
 }
 
 static int skcipher_wait_for_wmem(struct sock *sk, unsigned flags)
@@ -424,8 +481,149 @@ unlock:
return err ?: size;
 }
 
-static int skcipher_recvmsg(struct kiocb *unused, struct socket *sock,
-   struct msghdr *msg, size_t ignored, int flags)
+static int skcipher_all_sg_nents(struct skcipher_ctx *ctx)
+{
+   struct skcipher_sg_list *sgl;
+   struct scatterlist *sg;
+   int nents = 0;
+
+   list_for_each_entry(sgl, &ctx->tsgl, list) {
+   sg = sgl->sg;
+
+   while (!sg->length)
+   sg++;
+
+   nents += sg_nents(sg);
+   }
+   return nents;
+}
+
+static int skcipher_recvmsg_async(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *msg, int flags)
+{
+   struct sock *sk = sock->sk;
+   struct alg_sock *ask = alg_sk(sk);
+   struct skcipher_ctx *ctx = ask->private;
+   struct skcipher_sg_list *sgl;
+   struct scatterlist *sg;
+   struct skcipher_async_req *sreq;
+   struct ablkcipher_request *req;
+   struct skcipher_async_rsgl *last_rsgl = NULL;
+   unsigned int len = 0, tx_nents = skcipher_all_sg_nents(ctx);
+   unsigned int reqlen = sizeof(struct skcipher_asy

Re: [PATCH v2] crypto: omap-sham: Check for return value from pm_runtime_get_sync

2015-03-09 Thread Pavel Machek 
On Sun 2015-03-08 11:01:01, Pali Rohár wrote:
> Function pm_runtime_get_sync could fail and we need to check return
> value to prevent kernel crash.
> 
> Signed-off-by: Pali Rohár 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 v2 0/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-09 Thread Tadeusz Struk 
The way the algif_skcipher works currently is that on sendmsg/sendpage it
builds an sgl for the input data and then on read/recvmsg it sends the job
for encryption putting the user to sleep till the data is processed.
This way it can only handle one job at a given time.
To be able to fuly utilize the potential of existing crypto hardware
accelerators it is required to submit multiple jobs in asynchronously.
This series adds support for asynchronous operations for algif_skcipher.
First patch enables af_alg sgl to be linked.
Second patch implement asynch read for skcipher.

Changes in v2:
 - Use kmalloc instead of caches

Signed-off-by: Tadeusz Struk 
---
Tadeusz Struk (2):
  crypto: af_alg - Allow to link sgl
  crypto: algif - change algif_skcipher to be asynchronous


 crypto/af_alg.c |   18 +++-
 crypto/algif_skcipher.c |  233 ++-
 include/crypto/if_alg.h |4 +
 3 files changed, 242 insertions(+), 13 deletions(-)
--
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: amcc: remove incorrect __init/__exit markups

2015-03-09 Thread Dmitry Torokhov 
Even if bus is not hot-pluggable, the devices can be bound and unbound
from the driver via sysfs, so we should not be using __init/__exit
annotations on probe() and remove() methods. The only exception is
drivers registered with platform_driver_probe() which specifically
disables sysfs bind/unbind attributes.

Signed-off-by: Dmitry Torokhov 
---
 drivers/crypto/amcc/crypto4xx_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index d02b771..3b28e8c 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1155,7 +1155,7 @@ struct crypto4xx_alg_common crypto4xx_alg[] = {
 /**
  * Module Initialization Routine
  */
-static int __init crypto4xx_probe(struct platform_device *ofdev)
+static int crypto4xx_probe(struct platform_device *ofdev)
 {
int rc;
struct resource res;
@@ -1263,7 +1263,7 @@ err_alloc_dev:
return rc;
 }
 
-static int __exit crypto4xx_remove(struct platform_device *ofdev)
+static int crypto4xx_remove(struct platform_device *ofdev)
 {
struct device *dev = &ofdev->dev;
struct crypto4xx_core_device *core_dev = dev_get_drvdata(dev);
@@ -1291,7 +1291,7 @@ static struct platform_driver crypto4xx_driver = {
.of_match_table = crypto4xx_match,
},
.probe  = crypto4xx_probe,
-   .remove = __exit_p(crypto4xx_remove),
+   .remove = crypto4xx_remove,
 };
 
 module_platform_driver(crypto4xx_driver);
-- 
2.2.0.rc0.207.ga3a616c


-- 
Dmitry
--
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: qat - remove incorrect __exit markup

2015-03-09 Thread Dmitry Torokhov 
PCI bus is hot-pluggable, and even if it wasn't one can still unbind the
device from driver via sysfs, so we should not make driver's remove
method as __exit.

Signed-off-by: Dmitry Torokhov 
---
 drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c 
b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
index 8ffdb95..e7af9d5 100644
--- a/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
+++ b/drivers/crypto/qat/qat_dh895xcc/adf_drv.c
@@ -379,7 +379,7 @@ out_err:
return ret;
 }
 
-static void __exit adf_remove(struct pci_dev *pdev)
+static void adf_remove(struct pci_dev *pdev)
 {
struct adf_accel_dev *accel_dev = adf_devmgr_pci_to_accel_dev(pdev);
 
-- 
2.2.0.rc0.207.ga3a616c


-- 
Dmitry
--
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 RESEND 2/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-09 Thread Tadeusz Struk 
On 03/06/2015 04:09 AM, Herbert Xu wrote:
>> It helps to make it faster.
>> > This way I can do some of the request setup beforehand and minimize 
>> > overhead on the data path.
> Do you have numbers to back this up?

Ok, you are right. It was implemented that way when I used the qat type socket, 
which was rejected.
It made more sense to do it that way as there was some dma remapping that I 
could do upfront.
Now the difference in performance is negligible. I'll send v2 shortly.
Thanks for pointing this out.
--
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: add support for GHASH using ARMv8 Crypto Extensions

2015-03-09 Thread Ard Biesheuvel 
This implements the GHASH hash algorithm (as used by the GCM AEAD
chaining mode) using the AArch32 version of the 64x64 to 128 bit
polynomial multiplication instruction (vmull.p64) that is part of
the ARMv8 Crypto Extensions.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig |   9 ++
 arch/arm/crypto/Makefile|   2 +
 arch/arm/crypto/ghash-ce-core.S |  93 
 arch/arm/crypto/ghash-ce-glue.c | 318 
 4 files changed, 422 insertions(+)
 create mode 100644 arch/arm/crypto/ghash-ce-core.S
 create mode 100644 arch/arm/crypto/ghash-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 63588bdf3b5d..5dc8a9e79744 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -110,4 +110,13 @@ config CRYPTO_AES_ARM_CE
  Use an implementation of AES in CBC, CTR and XTS modes that uses
  ARMv8 Crypto Extensions
 
+config CRYPTO_GHASH_ARM_CE
+   tristate "PMULL-accelerated GHASH using ARMv8 Crypto Extensions"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_HASH
+   help
+ Use an implementation of GHASH (used by the GCM AEAD chaining mode)
+ that uses the 64x64 to 128 bit polynomial multiplication (vmull.p64)
+ that is part of the ARMv8 Crypto Extensions
+
 endif
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 2514c420e8d3..9a273bd7dffd 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.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
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
@@ -19,6 +20,7 @@ sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
 sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
 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
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/ghash-ce-core.S b/arch/arm/crypto/ghash-ce-core.S
new file mode 100644
index ..53bee60ff94b
--- /dev/null
+++ b/arch/arm/crypto/ghash-ce-core.S
@@ -0,0 +1,93 @@
+/*
+ * Accelerated GHASH implementation with ARMv8 vmull.p64 instructions.
+ *
+ * Copyright (C) 2015 Linaro Ltd. 
+ *
+ * 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 
+#include 
+
+   SHASH   .reqq0
+   SHASH2  .reqq1
+   T1  .reqq2
+   T2  .reqq3
+   MASK.reqq4
+   XL  .reqq5
+   XM  .reqq6
+   XH  .reqq7
+   IN1 .reqq7
+
+   SHASH_L .reqd0
+   SHASH_H .reqd1
+   SHASH2_L.reqd2
+   T1_L.reqd4
+   MASK_L  .reqd8
+   XL_L.reqd10
+   XL_H.reqd11
+   XM_L.reqd12
+   XM_H.reqd13
+   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)
+*/
+ENTRY(pmull_ghash_update)
+   vld1.8  {SHASH}, [r3]
+   vld1.8  {XL}, [r1]
+   vmov.i8 MASK, #0xe1
+   vext.8  SHASH2, SHASH, SHASH, #8
+   vshl.u64MASK, MASK, #57
+   veorSHASH2, SHASH2, SHASH
+
+   /* do the head block first, if supplied */
+   ldr ip, [sp]
+   teq ip, #0
+   beq 0f
+   vld1.8  {T1}, [ip]
+   teq r0, #0
+   b   1f
+
+0: vld1.8  {T1}, [r2]!
+   subsr0, r0, #1
+
+1: /* multiply XL by SHASH in GF(2^128) */
+   vrev64.8T1, T1
+
+   vext.8  T2, XL, XL, #8
+   vext.8  IN1, T1, T1, #8
+   veorT1, T1, T2
+   veorXL, XL, IN1
+
+   vmull.p64   XH, SHASH_H, XL_H   @ a1 * b1
+   veorT1, T1, XL
+   vmull.p64   XL, SHASH_L, XL_L   @ a0 * b0
+   vmull.p64   XM, SHASH2_L, T1_L  @ (a1 + a0)(b1 + b0)
+
+   vext.8  T1, XL, XH, #8
+   veorT2, XL, XH
+   veorXM, XM, T1
+   veorXM, XM, T2
+   vmull.p64   T2, XL_L, MASK_L
+
+   vmovXH_L, XM_H
+   vmovXM_H, XL_L
+
+

[PATCH 2/4] hwrng: omap - remove #ifdefery around PM methods

2015-03-09 Thread Dmitry Torokhov 
Instead of using #ifdefs let's mark suspend and resume methods as
__maybe_unused which will suppress compiler warnings about them being
unused and provide better compile coverage. This will not increase image
size.

Signed-off-by: Dmitry Torokhov 
---
 drivers/char/hw_random/omap-rng.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 7f3597d..5c171b1 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -422,9 +422,7 @@ static int omap_rng_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
-
-static int omap_rng_suspend(struct device *dev)
+static int __maybe_unused omap_rng_suspend(struct device *dev)
 {
struct omap_rng_dev *priv = dev_get_drvdata(dev);
 
@@ -434,7 +432,7 @@ static int omap_rng_suspend(struct device *dev)
return 0;
 }
 
-static int omap_rng_resume(struct device *dev)
+static int __maybe_unused omap_rng_resume(struct device *dev)
 {
struct omap_rng_dev *priv = dev_get_drvdata(dev);
 
@@ -445,18 +443,11 @@ static int omap_rng_resume(struct device *dev)
 }
 
 static SIMPLE_DEV_PM_OPS(omap_rng_pm, omap_rng_suspend, omap_rng_resume);
-#defineOMAP_RNG_PM (&omap_rng_pm)
-
-#else
-
-#defineOMAP_RNG_PM NULL
-
-#endif
 
 static struct platform_driver omap_rng_driver = {
.driver = {
.name   = "omap_rng",
-   .pm = OMAP_RNG_PM,
+   .pm = &omap_rng_pm,
.of_match_table = of_match_ptr(omap_rng_of_match),
},
.probe  = omap_rng_probe,
-- 
2.2.0.rc0.207.ga3a616c

--
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/4] hwrng: octeon - remove incorrect __exit markups

2015-03-09 Thread Dmitry Torokhov 
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes

Signed-off-by: Dmitry Torokhov 
---
 drivers/char/hw_random/octeon-rng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/octeon-rng.c 
b/drivers/char/hw_random/octeon-rng.c
index be1c3f6..6234a4a 100644
--- a/drivers/char/hw_random/octeon-rng.c
+++ b/drivers/char/hw_random/octeon-rng.c
@@ -105,7 +105,7 @@ static int octeon_rng_probe(struct platform_device *pdev)
return 0;
 }
 
-static int __exit octeon_rng_remove(struct platform_device *pdev)
+static int octeon_rng_remove(struct platform_device *pdev)
 {
struct hwrng *rng = platform_get_drvdata(pdev);
 
@@ -119,7 +119,7 @@ static struct platform_driver octeon_rng_driver = {
.name   = "octeon_rng",
},
.probe  = octeon_rng_probe,
-   .remove = __exit_p(octeon_rng_remove),
+   .remove = octeon_rng_remove,
 };
 
 module_platform_driver(octeon_rng_driver);
-- 
2.2.0.rc0.207.ga3a616c

--
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 4/4] hwrng: pseries-rng - remove incorrect __init/__exit markups

2015-03-09 Thread Dmitry Torokhov 
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Similarly probe() methods should not be marked __init unless
platform_driver_probe() is used.

Signed-off-by: Dmitry Torokhov 
---
 drivers/char/hw_random/pseries-rng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/pseries-rng.c 
b/drivers/char/hw_random/pseries-rng.c
index bcf86f9..63ce51d 100644
--- a/drivers/char/hw_random/pseries-rng.c
+++ b/drivers/char/hw_random/pseries-rng.c
@@ -61,13 +61,13 @@ static struct hwrng pseries_rng = {
.read   = pseries_rng_read,
 };
 
-static int __init pseries_rng_probe(struct vio_dev *dev,
+static int pseries_rng_probe(struct vio_dev *dev,
const struct vio_device_id *id)
 {
return hwrng_register(&pseries_rng);
 }
 
-static int __exit pseries_rng_remove(struct vio_dev *dev)
+static int pseries_rng_remove(struct vio_dev *dev)
 {
hwrng_unregister(&pseries_rng);
return 0;
-- 
2.2.0.rc0.207.ga3a616c

--
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/4] hwrng: omap - remove incorrect __exit markups

2015-03-09 Thread Dmitry Torokhov 
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov 
---
 drivers/char/hw_random/omap-rng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index d14dcf7..7f3597d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -408,7 +408,7 @@ err_ioremap:
return ret;
 }
 
-static int __exit omap_rng_remove(struct platform_device *pdev)
+static int omap_rng_remove(struct platform_device *pdev)
 {
struct omap_rng_dev *priv = platform_get_drvdata(pdev);
 
@@ -460,7 +460,7 @@ static struct platform_driver omap_rng_driver = {
.of_match_table = of_match_ptr(omap_rng_of_match),
},
.probe  = omap_rng_probe,
-   .remove = __exit_p(omap_rng_remove),
+   .remove = omap_rng_remove,
 };
 
 module_platform_driver(omap_rng_driver);
-- 
2.2.0.rc0.207.ga3a616c

--
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 RESEND 0/2] crypto: algif - change algif_skcipher to be asynchronous

2015-03-09 Thread Tadeusz Struk 
Hi Stephan,
On 03/08/2015 11:20 AM, Stephan Mueller wrote:
> As you may know, I am working on libkcapi [1] to cover the user space AF_ALG 
> interface and provide an easy-to use interface for applications.
> 
> I am now trying to cover your interface proposal there and also measure the 
> speed of it. What bothers me currently is the following: how would I be able 
> to detect whether the implemented support is available in the current kernel?

You don't need to detect that. You can just use the new interface, and in the 
older
kernels without AIO support in skcipher it will seamlessly fallback to the 
synchronous interface.

The only problem is that the socket layer didn't like asynch operations before 
commit
06539d3071067ff146a9bffd1c801fa56d290909.
The way it can be tackled for the older kernels is the distros will need update 
their kernels
with the mentioned commit. They should do it anyway because it looks like that 
was a bug.

One other thing to keep in mind is - to be able to see the benefit of AIO you 
need to use
some encryption offload engine, where you can asynchronously offload multiple 
operations.
With my dh895xxcc engine I see around 8x throughput improvement.
Regards,
Tadeusz

--
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/2] crypto: talitos: Add AES-XTS mode

2015-03-09 Thread Martin Hicks 
On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă  wrote:
> On 3/3/2015 7:44 PM, Martin Hicks wrote:
>> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
>>  wrote:
>>>
>>> For talitos, there are two cases:
>>>
>>> 1. request data size is <= data unit / sector size
>>> talitos can handle any IV / tweak scheme
>>>
>>> 2. request data size > sector size
>>> since talitos internally generates the IV for the next sector by
>>> incrementing the previous IV, only IV schemes that allocate consecutive
>>> IV to consecutive sectors will function correctly.
>>>
>>
>> it's not clear to me that #1 is right.  I guess it could be, but the
>> IV length would be limited to 8 bytes.
>
> Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up
> to 8 bytes.
> So I guess ESSIV won't work with talitos-xts, since the encrypted IV
> output is 16 bytes.
> But as previously said, ESSIV breaks the XTS standard requirement for
> having a consecutive IV for consecutive blocks. ESSIV should really be
> used only with disk-level encryption schemes that require an
> unpredictable IV.

Ok.  I'll verify that the second half of the IV is zeroed.

One last thing that I'm not sure of is what string to place in
cra_ablkcipher.geniv field.   "eseqiv" seems wrong if plain/plain64
are the IVs that XTS is designed for.

Thanks,
mh

-- 
Martin Hicks P.Eng.  | m...@bork.org
Bork Consulting Inc. |   +1 (613) 266-2296
--
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: tcrypt - fix uninit sg entries in test_acipher_speed

2015-03-09 Thread Horia Geanta 
Commit 5be4d4c94b1f ("crypto: replace scatterwalk_sg_next with sg_next")
did not consider the fact that scatterwalk_sg_next() was looking at
sg entry length, while sg_next() looks at the "chained" sg bit.

This should have no effect in theory. However in practice, there are
cases where the sg table is initialized to a number of entries and
some of them are not properly configured. While scatterwalk_sg_next()
would have returned NULL (since sg length = 0 and sg page_link = 0),
sg_next() happily returns the next unconfigured sg entry.

insmod tcrypt.ko mode=500 sec=1

testing speed of async cbc(aes) (cbc-aes-talitos) encryption
test 0 (128 bit key, 16 byte blocks):
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc00d79e4
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 P1022 DS
Modules linked in: tcrypt(+) talitos
CPU: 0 PID: 2670 Comm: insmod Not tainted 
4.0.0-rc1-QorIQ-SDK-V1.6+g904f1ca82209 #1
task: e8de3200 ti: e70bc000 task.ti: e70bc000
NIP: c00d79e4 LR: f92d223c CTR: c00d79c8
REGS: e70bda00 TRAP: 0300   Not tainted  
(4.0.0-rc1-QorIQ-SDK-V1.6+g904f1ca82209)
MSR: 00029000   CR: 84428f22  XER: 
DEAR:  ESR: 
GPR00: f92d223c e70bdab0 e8de3200  e70bdbb8 0001  
GPR08:   c08b0380 27282010 c00d79c8 1003a634  e70bdf1c
GPR16: e70bdef0 0020  c08c 0010  e70bdbb8 0010
GPR24: e976d3a8 0010  e70bdbd8 e8961010 0001 c086e560 
NIP [c00d79e4] page_address+0x1c/0x110
LR [f92d223c] talitos_map_sg+0x130/0x184 [talitos]
Call Trace:
[e70bdab0] [0010] 0x10 (unreliable)
[e70bdad0] [f92d223c] talitos_map_sg+0x130/0x184 [talitos]
[e70bdb00] [f92d30d8] common_nonsnoop.constprop.13+0xc0/0x304 [talitos]
[e70bdb30] [f933fd90] test_acipher_speed+0x434/0x7dc [tcrypt]
[e70bdcc0] [f934318c] do_test+0x2478/0x306c [tcrypt]
[e70bdd80] [f11fe058] tcrypt_mod_init+0x58/0x100 [tcrypt]
[e70bdda0] [c0002354] do_one_initcall+0x90/0x1f4
[e70bde10] [c061fe00] do_init_module+0x60/0x1ac
[e70bde30] [c00a79f0] load_module+0x185c/0x1f88
[e70bdee0] [c00a82b0] SyS_finit_module+0x7c/0x98
[e70bdf40] [c000e8b0] ret_from_syscall+0x0/0x3c
--- interrupt: c01 at 0xff1985c
LR = 0x10012df0
Instruction dump:
54ea402e 7d494b78 55292834 7c634a14 4e800020 9421ffe0 7c0802a6 3d40c08b
394a0380 bf61000c 7c7f1b78 90010024 <8123> 552917be 1d290320 7d295214
---[ end trace ff191e5b504b4671 ]---

Signed-off-by: Horia Geanta 
---

This might affect other drivers, haven't checked.
There might be other cases failing too.

Please carrefuly review side effects of commit 5be4d4c94b1f.

 crypto/tcrypt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 4b9e23fa4204..1a2800107fc8 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1155,9 +1155,9 @@ static void test_acipher_speed(const char *algo, int enc, 
unsigned int secs,
goto out_free_req;
}
 
-   sg_init_table(sg, TVMEMSIZE);
-
k = *keysize + *b_size;
+   sg_init_table(sg, DIV_ROUND_UP(k, PAGE_SIZE));
+
if (k > PAGE_SIZE) {
sg_set_buf(sg, tvmem[0] + *keysize,
   PAGE_SIZE - *keysize);
-- 
1.8.3.1

--
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 5/5] crypto: talitos: Add software backlog queue handling

2015-03-09 Thread Horia Geantă 
On 3/6/2015 6:48 AM, Herbert Xu wrote:
> On Thu, Mar 05, 2015 at 11:35:23AM +0200, Horia Geantă wrote:
>>
>>> Only potential problem is getting the crypto API to set the GFP_DMA
>>> flag in the allocation request, but presumably a
>>> CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
>>
>> Right. And this flag would apply only to request __ctx[].
>>
>> Herbert, would this be an acceptable addition to crypto API?
> 
> How would such a flag work?

Hm, I thought that GFP_DMA memory could be allocated only for request
private ctx. This is obviously not the case.

*_request_alloc(tfm, gfp) crypto API functions would do:
if (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_DMA)
gfp |= GFP_DMA;

Thanks,
Horia


--
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 4/4] crypto/arm: AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions

2015-03-09 Thread Ard Biesheuvel 
This implements the ECB, CBC, CTR and XTS asynchronous block ciphers
using the AArch32 versions of the ARMv8 Crypto Extensions for AES.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig   |   9 +
 arch/arm/crypto/Makefile  |   2 +
 arch/arm/crypto/aes-ce-core.S | 535 ++
 arch/arm/crypto/aes-ce-glue.c | 520 
 4 files changed, 1066 insertions(+)
 create mode 100644 arch/arm/crypto/aes-ce-core.S
 create mode 100644 arch/arm/crypto/aes-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 9c1478e55a40..63588bdf3b5d 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -101,4 +101,13 @@ config CRYPTO_AES_ARM_BS
  This implementation does not rely on any lookup tables so it is
  believed to be invulnerable to cache timing attacks.
 
+config CRYPTO_AES_ARM_CE
+   tristate "Accelerated AES using ARMv8 Crypto Extensions"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_ALGAPI
+   select CRYPTO_ABLK_HELPER
+   help
+ Use an implementation of AES in CBC, CTR and XTS modes that uses
+ ARMv8 Crypto Extensions
+
 endif
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 4ea9f96c2782..2514c420e8d3 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -4,6 +4,7 @@
 
 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_SHA512_ARM_NEON) += sha512-arm-neon.o
@@ -17,6 +18,7 @@ sha1-arm-neon-y   := sha1-armv7-neon.o sha1_neon_glue.o
 sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
 sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
 sha2-arm-ce-y  := sha2-ce-core.o sha2-ce-glue.o
+aes-arm-ce-y   := aes-ce-core.o aes-ce-glue.o
 
 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
new file mode 100644
index ..0fb1b7b29c51
--- /dev/null
+++ b/arch/arm/crypto/aes-ce-core.S
@@ -0,0 +1,535 @@
+/*
+ * aes-ce-core.S - AES in CBC/CTR/XTS mode using ARMv8 Crypto Extensions
+ *
+ * Copyright (C) 2015 Linaro Ltd 
+ *
+ * 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 
+#include 
+
+   .text
+   .fpucrypto-neon-fp-armv8
+   .align  3
+
+   /*
+* u32 ce_aes_sub(u32 input) - use the aese instruction to perform the
+* AES sbox substitution on each byte in
+* 'input'
+*/
+ENTRY(ce_aes_sub)
+   vdup.32 q1, r0
+   veorq0, q0, q0
+   aese.8  q0, q1
+   vmovr0, s0
+   bx  lr
+ENDPROC(ce_aes_sub)
+
+   /*
+* void ce_aes_invert(u8 *dst, u8 *src) - perform the Inverse MixColumns
+*operation on round key *src
+*/
+ENTRY(ce_aes_invert)
+   vld1.8  {q0}, [r1]
+   aesimc.8q0, q0
+   vst1.8  {q0}, [r0]
+   bx  lr
+ENDPROC(ce_aes_invert)
+
+   .macro  enc_round, state, key
+   aese.8  \state, \key
+   aesmc.8 \state, \state
+   .endm
+
+   .macro  dec_round, state, key
+   aesd.8  \state, \key
+   aesimc.8\state, \state
+   .endm
+
+   .macro  enc_dround, key1, key2
+   enc_round   q0, \key1
+   enc_round   q0, \key2
+   .endm
+
+   .macro  dec_dround, key1, key2
+   dec_round   q0, \key1
+   dec_round   q0, \key2
+   .endm
+
+   .macro  enc_fround, key1, key2, key3
+   enc_round   q0, \key1
+   aese.8  q0, \key2
+   veorq0, q0, \key3
+   .endm
+
+   .macro  dec_fround, key1, key2, key3
+   dec_round   q0, \key1
+   aesd.8  q0, \key2
+   veorq0, q0, \key3
+   .endm
+
+   .macro  enc_dround_3x, key1, key2
+   enc_round   q0, \key1
+   enc_round   q1, \key1
+   enc_round   q2, \key1
+   enc_round   q0, \key2
+   enc_round   q1, \key2
+   enc_round   q2, \key2
+   .endm
+
+   .macro  dec_dround_3x, key1, key2
+   dec_round   q0, \key1
+   dec_round   q1, \key1
+   dec_round   q2, \key1
+   dec_round   q0, \key2
+   dec_round   q1, \key2
+   dec_round   q2, \key2
+   .endm
+
+   .macro  enc_fround_3x, key1, key2, key3
+   enc_round   q0, \key1
+   enc_round

[PATCH 2/4] crypto/arm: add support for SHA1 using ARMv8 Crypto Instructions

2015-03-09 Thread Ard Biesheuvel 
This implements the SHA1 secure hash algorithm using the AArch32
versions of the ARMv8 Crypto Extensions for SHA1.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig|  10 +++
 arch/arm/crypto/Makefile   |   2 +
 arch/arm/crypto/sha1-ce-core.S | 134 
 arch/arm/crypto/sha1-ce-glue.c | 150 +
 4 files changed, 296 insertions(+)
 create mode 100644 arch/arm/crypto/sha1-ce-core.S
 create mode 100644 arch/arm/crypto/sha1-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 66fe82857e99..d7bc10beb8ac 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -27,6 +27,16 @@ config CRYPTO_SHA1_ARM_NEON
  using optimized ARM NEON assembly, when NEON instructions are
  available.
 
+config CRYPTO_SHA1_ARM_CE
+   tristate "SHA1 digest algorithm (ARM v8 Crypto Extensions)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA1_ARM
+   select CRYPTO_SHA1
+   select CRYPTO_HASH
+   help
+ SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
+ using special ARMv8 Crypto Extensions.
+
 config CRYPTO_SHA512_ARM_NEON
tristate "SHA384 and SHA512 digest algorithm (ARM NEON)"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index b48fa341648d..d92d05ba646e 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -7,12 +7,14 @@ obj-$(CONFIG_CRYPTO_AES_ARM_BS) += aes-arm-bs.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
+obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
 sha1-arm-y := sha1-armv4-large.o sha1_glue.o
 sha1-arm-neon-y:= sha1-armv7-neon.o sha1_neon_glue.o
 sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
+sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/sha1-ce-core.S b/arch/arm/crypto/sha1-ce-core.S
new file mode 100644
index ..7542f10b2233
--- /dev/null
+++ b/arch/arm/crypto/sha1-ce-core.S
@@ -0,0 +1,134 @@
+/*
+ * sha1-ce-core.S - SHA-1 secure hash using ARMv8 Crypto Extensions
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Ard Biesheuvel 
+ *
+ * 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 
+#include 
+
+   .text
+   .fpucrypto-neon-fp-armv8
+
+   k0  .reqq0
+   k1  .reqq1
+   k2  .reqq2
+   k3  .reqq3
+
+   ta0 .reqq4
+   ta1 .reqq5
+   tb0 .reqq5
+   tb1 .reqq4
+
+   dga .reqq6
+   dgb .reqq7
+   dgbs.reqs28
+
+   dg0 .reqq12
+   dg1a0   .reqq13
+   dg1a1   .reqq14
+   dg1b0   .reqq14
+   dg1b1   .reqq13
+
+   .macro  add_only, op, ev, rc, s0, dg1
+   .ifnb   \s0
+   vadd.u32tb\ev, q\s0, \rc
+   .endif
+   sha1h.32dg1b\ev, dg0
+   .ifb\dg1
+   sha1\op\().32   dg0, dg1a\ev, ta\ev
+   .else
+   sha1\op\().32   dg0, \dg1, ta\ev
+   .endif
+   .endm
+
+   .macro  add_update, op, ev, rc, s0, s1, s2, s3, dg1
+   sha1su0.32  q\s0, q\s1, q\s2
+   add_only\op, \ev, \rc, \s1, \dg1
+   sha1su1.32  q\s0, q\s3
+   .endm
+
+   .align  6
+.Lsha1_rcon:
+   .word   0x5a827999, 0x5a827999, 0x5a827999, 0x5a827999
+   .word   0x6ed9eba1, 0x6ed9eba1, 0x6ed9eba1, 0x6ed9eba1
+   .word   0x8f1bbcdc, 0x8f1bbcdc, 0x8f1bbcdc, 0x8f1bbcdc
+   .word   0xca62c1d6, 0xca62c1d6, 0xca62c1d6, 0xca62c1d6
+
+   /*
+* void sha1_ce_transform(int blocks, u8 const *src, u32 *state,
+*u8 *head);
+*/
+ENTRY(sha1_ce_transform)
+   /* load round constants */
+   adr ip, .Lsha1_rcon
+   vld1.32 {k0-k1}, [ip]!
+   vld1.32 {k2-k3}, [ip]
+
+   /* load state */
+   vldmr2, {dga}
+   vldrdgbs, [r2, #16]
+
+   /* load partial input (if supplied) */
+   teq r3, #0
+   beq 0f
+   vld1.8  {q8-q9}, [r3]!
+   vld1.8  {q10-q11}, [r3]
+   teq r0, #0
+   b   1f
+
+   /* load input */
+0: vld1.8  {q8-q9}, [r1]!
+   vld1.8  {q10-q11}, [r1]!
+   subs

[PATCH 3/4] crypto/arm: add support for SHA-224/256 using ARMv8 Crypto Extensions

2015-03-09 Thread Ard Biesheuvel 
This implements the SHA-224/256 secure hash algorithm using the AArch32
versions of the ARMv8 Crypto Extensions for SHA2.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/Kconfig|   9 ++
 arch/arm/crypto/Makefile   |   2 +
 arch/arm/crypto/sha2-ce-core.S | 134 +++
 arch/arm/crypto/sha2-ce-glue.c | 203 +
 4 files changed, 348 insertions(+)
 create mode 100644 arch/arm/crypto/sha2-ce-core.S
 create mode 100644 arch/arm/crypto/sha2-ce-glue.c

diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index d7bc10beb8ac..9c1478e55a40 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -37,6 +37,15 @@ config CRYPTO_SHA1_ARM_CE
  SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
  using special ARMv8 Crypto Extensions.
 
+config CRYPTO_SHA2_ARM_CE
+   tristate "SHA-224/256 digest algorithm (ARM v8 Crypto Extensions)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA256
+   select CRYPTO_HASH
+   help
+ SHA-256 secure hash standard (DFIPS 180-2) implemented
+ using special ARMv8 Crypto Extensions.
+
 config CRYPTO_SHA512_ARM_NEON
tristate "SHA384 and SHA512 digest algorithm (ARM NEON)"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index d92d05ba646e..4ea9f96c2782 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
 obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
+obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
 
 aes-arm-y  := aes-armv4.o aes_glue.o
 aes-arm-bs-y   := aesbs-core.o aesbs-glue.o
@@ -15,6 +16,7 @@ sha1-arm-y:= sha1-armv4-large.o sha1_glue.o
 sha1-arm-neon-y:= sha1-armv7-neon.o sha1_neon_glue.o
 sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
 sha1-arm-ce-y  := sha1-ce-core.o sha1-ce-glue.o
+sha2-arm-ce-y  := sha2-ce-core.o sha2-ce-glue.o
 
 quiet_cmd_perl = PERL$@
   cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/sha2-ce-core.S b/arch/arm/crypto/sha2-ce-core.S
new file mode 100644
index ..39e01ee7d485
--- /dev/null
+++ b/arch/arm/crypto/sha2-ce-core.S
@@ -0,0 +1,134 @@
+/*
+ * sha2-ce-core.S - SHA-224/256 secure hash using ARMv8 Crypto Extensions
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Ard Biesheuvel 
+ *
+ * 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 
+#include 
+
+   .text
+   .fpucrypto-neon-fp-armv8
+
+   k0  .reqq7
+   k1  .reqq8
+   rk  .reqr3
+
+   ta0 .reqq9
+   ta1 .reqq10
+   tb0 .reqq10
+   tb1 .reqq9
+
+   dga .reqq11
+   dgb .reqq12
+
+   dg0 .reqq13
+   dg1 .reqq14
+   dg2 .reqq15
+
+   .macro  add_only, ev, s0
+   vmovdg2, dg0
+   .ifnb   \s0
+   vld1.32 {k\ev}, [rk]!
+   .endif
+   sha256h.32  dg0, dg1, tb\ev
+   sha256h2.32 dg1, dg2, tb\ev
+   .ifnb   \s0
+   vadd.u32ta\ev, q\s0, k\ev
+   .endif
+   .endm
+
+   .macro  add_update, ev, s0, s1, s2, s3
+   sha256su0.32q\s0, q\s1
+   add_only\ev, \s1
+   sha256su1.32q\s0, q\s2, q\s3
+   .endm
+
+   .align  6
+.Lsha256_rcon:
+   .word   0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5
+   .word   0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5
+   .word   0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3
+   .word   0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174
+   .word   0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc
+   .word   0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da
+   .word   0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7
+   .word   0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967
+   .word   0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13
+   .word   0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85
+   .word   0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3
+   .word   0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070
+   .word   0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5
+   .word   0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3
+   .word   0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208
+   .word   0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
+
+   /*
+* void sha2_ce_t

[PATCH 1/4] crypto/arm: move ARM specific Kconfig definitions to a dedicated file

2015-03-09 Thread Ard Biesheuvel 
This moves all Kconfig symbols defined in crypto/Kconfig that depend
on CONFIG_ARM to a dedicated Kconfig file in arch/arm/crypto, which is
where the code that implements those features resides as well.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/Kconfig|  3 ++
 arch/arm/crypto/Kconfig | 85 +
 crypto/Kconfig  | 75 ---
 3 files changed, 88 insertions(+), 75 deletions(-)
 create mode 100644 arch/arm/crypto/Kconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9f1f09a2bc9b..e60da5ab8aec 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2167,6 +2167,9 @@ source "arch/arm/Kconfig.debug"
 source "security/Kconfig"
 
 source "crypto/Kconfig"
+if CRYPTO
+source "arch/arm/crypto/Kconfig"
+endif
 
 source "lib/Kconfig"
 
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
new file mode 100644
index ..66fe82857e99
--- /dev/null
+++ b/arch/arm/crypto/Kconfig
@@ -0,0 +1,85 @@
+
+menuconfig ARM_CRYPTO
+   bool "ARM Accelerated Cryptographic Algorithms"
+   depends on ARM
+   help
+ Say Y here to choose from a selection of cryptographic algorithms
+ implemented using ARM specific CPU features or instructions.
+
+if ARM_CRYPTO
+
+config CRYPTO_SHA1_ARM
+   tristate "SHA1 digest algorithm (ARM-asm)"
+   select CRYPTO_SHA1
+   select CRYPTO_HASH
+   help
+ SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
+ using optimized ARM assembler.
+
+config CRYPTO_SHA1_ARM_NEON
+   tristate "SHA1 digest algorithm (ARM NEON)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA1_ARM
+   select CRYPTO_SHA1
+   select CRYPTO_HASH
+   help
+ SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
+ using optimized ARM NEON assembly, when NEON instructions are
+ available.
+
+config CRYPTO_SHA512_ARM_NEON
+   tristate "SHA384 and SHA512 digest algorithm (ARM NEON)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_SHA512
+   select CRYPTO_HASH
+   help
+ SHA-512 secure hash standard (DFIPS 180-2) implemented
+ using ARM NEON instructions, when available.
+
+ This version of SHA implements a 512 bit hash with 256 bits of
+ security against collision attacks.
+
+ This code also includes SHA-384, a 384 bit hash with 192 bits
+ of security against collision attacks.
+
+config CRYPTO_AES_ARM
+   tristate "AES cipher algorithms (ARM-asm)"
+   depends on ARM
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES
+   help
+ Use optimized AES assembler routines for ARM platforms.
+
+ AES cipher algorithms (FIPS-197). AES uses the Rijndael
+ algorithm.
+
+ Rijndael appears to be consistently a very good performer in
+ both hardware and software across a wide range of computing
+ environments regardless of its use in feedback or non-feedback
+ modes. Its key setup time is excellent, and its key agility is
+ good. Rijndael's very low memory requirements make it very well
+ suited for restricted-space environments, in which it also
+ demonstrates excellent performance. Rijndael's operations are
+ among the easiest to defend against power and timing attacks.
+
+ The AES specifies three key sizes: 128, 192 and 256 bits
+
+ See  for more information.
+
+config CRYPTO_AES_ARM_BS
+   tristate "Bit sliced AES using NEON instructions"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_ALGAPI
+   select CRYPTO_AES_ARM
+   select CRYPTO_ABLK_HELPER
+   help
+ Use a faster and more secure NEON based implementation of AES in CBC,
+ CTR and XTS modes
+
+ Bit sliced AES gives around 45% speedup on Cortex-A15 for CTR mode
+ and for XTS mode encryption, CBC and XTS mode decryption speedup is
+ around 25%. (CBC encryption speed is not affected by this driver.)
+ This implementation does not rely on any lookup tables so it is
+ believed to be invulnerable to cache timing attacks.
+
+endif
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 50f4da44a304..c50900b467c8 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -555,26 +555,6 @@ config CRYPTO_SHA1_SPARC64
  SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
  using sparc64 crypto instructions, when available.
 
-config CRYPTO_SHA1_ARM
-   tristate "SHA1 digest algorithm (ARM-asm)"
-   depends on ARM
-   select CRYPTO_SHA1
-   select CRYPTO_HASH
-   help
- SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented
- using optimized ARM assembler.
-
-config CRYPTO_SHA1_ARM_NEON
-   tristate "SHA1 digest algorithm (ARM NEON)"
-   depends on ARM && KERNEL_MODE_NEON
-

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-09 Thread Horia Geantă 
On 3/3/2015 7:44 PM, Martin Hicks wrote:
> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
>  wrote:
>> On 3/3/2015 12:09 AM, Martin Hicks wrote:
>>>
>>> On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:

 If crypto API allows to encrypt more sectors in one run
 (handling IV internally) dmcrypt can be modified of course.

 But do not forget we can use another IV (not only sequential number)
 e.g. ESSIV with XTS as well (even if it doesn't make much sense, some 
 people
 are using it).
>>>
>>> Interesting, I'd not considered using XTS with an IV other than plain/64.
>>> The talitos hardware would not support aes/xts in any mode other than
>>> plain/plain64 I don't think...Although perhaps you could push in an 8-byte
>>> IV and the hardware would interpret it as the sector #.
>>>
>>
>> For talitos, there are two cases:
>>
>> 1. request data size is <= data unit / sector size
>> talitos can handle any IV / tweak scheme
>>
>> 2. request data size > sector size
>> since talitos internally generates the IV for the next sector by
>> incrementing the previous IV, only IV schemes that allocate consecutive
>> IV to consecutive sectors will function correctly.
>>
> 
> it's not clear to me that #1 is right.  I guess it could be, but the
> IV length would be limited to 8 bytes.

Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up
to 8 bytes.
So I guess ESSIV won't work with talitos-xts, since the encrypted IV
output is 16 bytes.
But as previously said, ESSIV breaks the XTS standard requirement for
having a consecutive IV for consecutive blocks. ESSIV should really be
used only with disk-level encryption schemes that require an
unpredictable IV.

> 
> This also points out that claiming that the XTS IV size is 16 bytes,
> as my current patch does, could be problematic.  It's handy because
> the first 8 bytes should contain a plain64 sector #, and the second
> u64 can be used to encode the sector size but it would be a mistake
> for someone to use the second 8 bytes for the rest of a 16byte IV.

XTS IV *is* 16 bytes. The fact that xts-talitos can handle only 8 bytes
is a problem indeed, but for plain and plain64 should not matter.

Horia


--
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: powerpc - move files to fix build error

2015-03-09 Thread Herbert Xu 
On Fri, Mar 06, 2015 at 06:46:21PM -0600, Kim Phillips wrote:
> The current cryptodev-2.6 tree commits:
> 
> d9850fc529ef ("crypto: powerpc/sha1 - kernel config")
> 50ba29aaa7b0 ("crypto: powerpc/sha1 - glue")
> 
> failed to properly place files under arch/powerpc/crypto, which
> leads to build errors:
> 
> make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1-spe-asm.o', 
> needed by 'arch/powerpc/crypto/sha1-ppc-spe.o'.  Stop.
> make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1_spe_glue.o', 
> needed by 'arch/powerpc/crypto/sha1-ppc-spe.o'.  Stop.
> Makefile:947: recipe for target 'arch/powerpc/crypto' failed
> 
> Move the two sha1 spe files under crypto/, and whilst there, rename
> other powerpc crypto files with underscores to use dashes for
> consistency.
> 
> Cc: Markus Stockhausen 
> Signed-off-by: Kim Phillips 

Patch applied.  Thanks!
-- 
Email: Herbert Xu 
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] rng: xgene-rng: add ACPI support for APM X-Gene RNG unit

2015-03-09 Thread Herbert Xu 
On Fri, Mar 06, 2015 at 02:53:15PM -0800, Feng Kan wrote:
> This adds ACPI support for APM X-Gene RNG unit.
> 
> Signed-off-by: Feng Kan 

Applied.
-- 
Email: Herbert Xu 
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: RNGs must return 0 in success case

2015-03-09 Thread Herbert Xu 
On Fri, Mar 06, 2015 at 08:26:31AM +0100, Stephan Mueller wrote:
> Change the RNGs to always return 0 in success case.
> 
> This patch ensures that seqiv.c works with RNGs other than krng. seqiv
> expects that any return code other than 0 is an error. Without the
> patch, rfc4106(gcm(aes)) will not work when using a DRBG or an ANSI
> X9.31 RNG.
> 
> Signed-off-by: Stephan Mueller 

Applied.
-- 
Email: Herbert Xu 
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/2] crypto: Documentation - add AF_ALG to DocBook

2015-03-09 Thread Herbert Xu 
On Fri, Mar 06, 2015 at 09:33:41PM +0100, Stephan Mueller wrote:
> Hi,
> 
> the AF_ALG interface description is added to the kernel crypto API
> DocBook. It is extended by the newly added AEAD and RNG interfaces.
> 
> An example of the documentation can be viewed at [1].
> 
> [1] http://www.chronox.de/crypto-API/User.html

All applied.  Thanks!
-- 
Email: Herbert Xu 
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: [V3 PATCH 0/2] fix some CAAM warnings.

2015-03-09 Thread Herbert Xu 
On Fri, Mar 06, 2015 at 10:34:40AM +0800, yanjiang@windriver.com wrote:
> From: Yanjiang Jin 
> 
> Hi,
> 
> This patch series fix some CAAM compile and runtime warnings.
> 
> I have tested this on fsl-p5020ds board using upstream 4.0.0-rc2 with the 
> below configs:
> 
> CONFIG_DMA_API_DEBUG=y
> # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> 
> Change log:
> v3:
> 
> 0001-crypto-caamhash-fix-uninitialized-edesc-sec4_sg_byte.patch is same as 
> before.
> 
> For 0002-crypto-caam_rng-fix-rng_unmap_ctx-s-DMA_UNMAP-size-p.patch
> 1. Fix an alignment issue;
> 2. update DESC_RNG_LEN to (4 * CAAM_CMD_SZ).
> 
> Abandon the v2 patch 0001-crypto-caam-fix-some-compile-warnings.patch.

All applied.  Thanks
-- 
Email: Herbert Xu 
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 2/2] crypto: talitos: Add AES-XTS Support

2015-03-09 Thread Horia Geantă 
On 3/7/2015 3:16 AM, Kim Phillips wrote:
> On Fri, 6 Mar 2015 11:49:43 -0500
> Martin Hicks  wrote:
> 
>> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips  
>> wrote:
>>> On Fri, 20 Feb 2015 12:00:10 -0500
>>> Martin Hicks  wrote:
>>>
 The newer talitos hardware has support for AES in XTS mode.
>>>
>>> Assuming it's the same thing, AES-XCBC gets added with SEC v3.0
>>> h/w.  Assuming hw_supports() doesn't already support this algorithm
>>
>> AES-XCBC isn't the same thing as AES-XTS.
> 
> Thanks.
> 
>>> combination (technically via the mode bit), this needs to be
>>> reflected in the patch so the driver doesn't think SEC 2.x devices
>>> can do XTS, too.
>>
>> Right.  I hadn't looked into how exactly hw_supports() works.  It only
>> indicates which execution units are present (in this case the AES
>> unit).  I actually think XTS gets introduced in SEC v3.3.2.  I also
>> have an MPC8379 (sec3.3) and it does not have XTS.
>>
>> Can you look internally to find out in which hardware it was
>> introduced?  Is there a SEC 3.3.1 that also has XTS?
> 
> later MPC8315Es had a SEC v3.3.1, but AFAICT, it doesn't support
> XTS, so, yes, it's likely v3.3.2 and above (if any).

There's a public application note on freescale.com:
"AN3645 - SEC 2x/3x Descriptor Programmer's Guide" (Rev.3/2010)

"Table 4 - EUs Supported in Each SEC Version" summarizes which
algorithms / modes are supported for every talitos version.
Unfortunately this goes up to SEC 3.3.1.
Since XTS doesn't show up, 3.3.2 would be the first supporting it.

Horia


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