[PATCH 10/10] crypto: caam - add support for RSA algorithm

2016-03-19 Thread Tudor Ambarus 
Add RSA support to caam driver.

Coauthored-by: Yashpal Dutta 

Signed-off-by: Tudor Ambarus 
---
 drivers/crypto/caam/Kconfig|  12 +
 drivers/crypto/caam/Makefile   |   4 +
 drivers/crypto/caam/caampkc.c  | 513 +
 drivers/crypto/caam/caampkc.h  |  84 +++
 drivers/crypto/caam/desc.h |   2 +
 drivers/crypto/caam/pdb.h  |  16 +-
 drivers/crypto/caam/pkc_desc.c | 138 +++
 7 files changed, 768 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/caam/caampkc.c
 create mode 100644 drivers/crypto/caam/caampkc.h
 create mode 100644 drivers/crypto/caam/pkc_desc.c

diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index 5652a53..5427e63 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -99,6 +99,18 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
  To compile this as a module, choose M here: the module
  will be called caamhash.
 
+config CRYPTO_DEV_FSL_CAAM_PKC_API
+tristate "Register public key cryptography implementations with Crypto 
API"
+depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
+default y
+select CRYPTO_RSA_HELPER
+help
+  Selecting this will allow SEC Public key support for RSA.
+  Supported cryptographic primitives: encryption, decryption,
+  signature and verification.
+  To compile this as a module, choose M here: the module
+  will be called caam_pkc.
+
 config CRYPTO_DEV_FSL_CAAM_RNG_API
tristate "Register caam device for hwrng API"
depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 550758a..399ad55 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -5,11 +5,15 @@ ifeq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG), y)
EXTRA_CFLAGS := -DDEBUG
 endif
 
+ccflags-y += -I$(srctree)/crypto
+
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
 
 caam-objs := ctrl.o
 caam_jr-objs := jr.o key_gen.o error.o
+caam_pkc-y := caampkc.o pkc_desc.o
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
new file mode 100644
index 000..1c53158
--- /dev/null
+++ b/drivers/crypto/caam/caampkc.c
@@ -0,0 +1,513 @@
+/*
+ * caam - Freescale FSL CAAM support for Public Key Cryptography
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * There is no Shared Descriptor for PKC so that the Job Descriptor must carry
+ * all the desired key parameters, input and output pointers.
+ */
+#include 
+#include 
+#include "compat.h"
+#include "caampkc.h"
+#include "sg_sw_sec4.h"
+#include "regs.h"
+#include "intern.h"
+#include "jr.h"
+#include "error.h"
+
+void rsa_free_key(struct rsa_raw_key *key)
+{
+   kzfree(key->d);
+   key->d = NULL;
+
+   kfree(key->e);
+   key->e = NULL;
+
+   kfree(key->n);
+   key->n = NULL;
+
+   key->n_sz = 0;
+   key->e_sz = 0;
+}
+
+static int caam_rsa_setpubkey(struct crypto_akcipher *tfm, const void *key,
+ unsigned int keylen)
+{
+   struct rsa_raw_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct rsa_raw_key *raw_key = >key;
+   int ret;
+
+   set_raw_rsa_pub_action(>action);
+
+   /* Free the old key if any */
+   rsa_free_key(raw_key);
+
+   ret = asn1_ber_decoder(_decoder, ctx, key, keylen);
+   if (ret < 0)
+   goto free;
+
+   if (!raw_key->n || !raw_key->e) {
+   /* Invalid key provided */
+   ret = -EINVAL;
+   goto free;
+   }
+
+   return 0;
+free:
+   rsa_free_key(raw_key);
+   return ret;
+}
+
+static int caam_rsa_setprivkey(struct crypto_akcipher *tfm, const void *key,
+  unsigned int keylen)
+{
+   struct rsa_raw_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct rsa_raw_key *raw_key = >key;
+   int ret;
+
+   set_raw_rsa_priv_action(>action);
+
+   /* Free the old key if any */
+   rsa_free_key(raw_key);
+
+   ret = asn1_ber_decoder(_decoder, ctx, key, keylen);
+   if (ret < 0)
+   goto free;
+
+   if (!raw_key->n || !raw_key->e || !raw_key->d) {
+   /* Invalid key provided */
+   ret = -EINVAL;
+   goto free;
+   }
+
+   return 0;
+free:
+   rsa_free_key(raw_key);
+   return ret;
+}
+
+static void rsa_pub_unmap(struct device *dev, struct rsa_edesc *edesc,
+ struct akcipher_request *req)
+{
+   struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
+   struct rsa_raw_ctx *ctx

Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Sinan Kaya 
On 3/18/2016 7:25 AM, Robin Murphy wrote:
> On 18/03/16 09:30, Boris Brezillon wrote:
>> On Thu, 17 Mar 2016 23:50:20 +
>> Russell King - ARM Linux  wrote:
>>
>>> On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
 What is the correct way? I don't want to write engine->sram_dma = sram
>>>
>>> Well, what the driver _is_ wanting to do is to go from a CPU physical
>>> address to a device DMA address.  phys_to_dma() looks like the correct
>>> thing there to me, but I guess that's just an offset and doesn't take
>>> account of any IOMMU that may be in the way.
>>>
>>> If you have an IOMMU, then the whole phys_to_dma() thing is a total
>>> failure as it only does a linear translation, and there are no
>>> interfaces in the kernel to take account of an IOMMU in the way.  So,
>>> it needs something designed for the job, implemented and discussed by
>>> the normal methods of proposing a new cross-arch interface for drivers
>>> to use.
>>>
>>> What I'm certain of, though, is that the change proposed in this patch
>>> will break current users of this driver: virt_to_page() on an address
>>> returned by ioremap() is completely undefined, and will result in
>>> either a kernel oops, or if not poking at memory which isn't a struct
>>> page, ultimately resulting in something that isn't SRAM being pointed
>>> to by "engine->sram_dma".
>>>
>>
>> Or we could just do
>>
>> engine->sram_dma = res->start;
>>
>> which is pretty much what the SRAM/genalloc code is doing already.
> 
> As Russell points out this is yet another type of "set up a DMA master to 
> access something other than kernel RAM" - there's already discussion in 
> progress over how to handle this for dmaengine slaves[1], so gathering more 
> use-cases might help distil exactly what the design of 
> not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else 
> needs to be.
> 
> Robin.
> 
> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.html
> 

Thanks for the link. 

dma_map_resource looks like to be the correct way of doing things. Just from
the purist point of view, a driver is not supposed to know the physical address
of a DMA address. That kills the intent of using DMA API. When programming 
descriptors,
the DMA addresses should be programmed not physical addresses so that the same 
driver can be used in a system with IOMMU. The IOMMU DMA ops will remap the DMA 
address to a bus address that is not physical address. All of this operation 
needs
to be isolated from the device driver.


I don't know the architecture or the driver enough to write this. This is not 
ideally
right but I can do this if Boris you are OK with this. 

 engine->sram_dma = res->start;

Another option is I can write

 engine->sram_dma = swiotlb_dma_to_phys(res->start)

I agree that dma_map_single is not the right thing. 

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project
--
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 02/10] crypto: rsa_helper - add raw integer parser actions

2016-03-19 Thread Tudor Ambarus 
Dedicated to RSA (hardware) implementations that want to use
raw integers instead of MPI keys.

Signed-off-by: Tudor Ambarus 
---
 crypto/rsa.c  |  15 
 crypto/rsa_helper.c   | 158 ++
 include/crypto/internal/rsa.h |  24 +++
 3 files changed, 182 insertions(+), 15 deletions(-)

diff --git a/crypto/rsa.c b/crypto/rsa.c
index 2d53ad8..44baccf 100644
--- a/crypto/rsa.c
+++ b/crypto/rsa.c
@@ -235,21 +235,6 @@ err_free_m:
return ret;
 }
 
-static int rsa_check_key_length(unsigned int len)
-{
-   switch (len) {
-   case 512:
-   case 1024:
-   case 1536:
-   case 2048:
-   case 3072:
-   case 4096:
-   return 0;
-   }
-
-   return -EINVAL;
-}
-
 static int rsa_set_pub_key(struct crypto_akcipher *tfm, const void *key,
   unsigned int keylen)
 {
diff --git a/crypto/rsa_helper.c b/crypto/rsa_helper.c
index 1ed32af..1708db8 100644
--- a/crypto/rsa_helper.c
+++ b/crypto/rsa_helper.c
@@ -14,6 +14,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include "rsapubkey-asn1.h"
 #include "rsaprivkey-asn1.h"
@@ -190,3 +193,158 @@ void set_rsa_priv_action(struct rsa_asn1_action *action)
action->get_n = rsa_get_mpi_n;
 }
 EXPORT_SYMBOL_GPL(set_rsa_priv_action);
+
+int rsa_check_key_length(unsigned int len)
+{
+   switch (len) {
+   case 512:
+   case 1024:
+   case 1536:
+   case 2048:
+   case 3072:
+   case 4096:
+   return 0;
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(rsa_check_key_length);
+
+int raw_rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
+ const void *value, size_t vlen)
+{
+   struct rsa_raw_ctx *ctx = context;
+   struct rsa_raw_key *key = >key;
+   const char *ptr = value;
+   int ret = -EINVAL;
+
+   while (!*ptr && vlen) {
+   ptr++;
+   vlen--;
+   }
+
+   key->n_sz = vlen;
+   /* In FIPS mode only allow key size 2K & 3K */
+   if (fips_enabled && (key->n_sz != 256 && key->n_sz != 384)) {
+   dev_err(ctx->dev, "RSA: key size not allowed in FIPS mode\n");
+   goto err;
+   }
+   /* invalid key size provided */
+   ret = rsa_check_key_length(key->n_sz << 3);
+   if (ret)
+   goto err;
+
+   if (key->is_coherent)
+   key->n = kzalloc(key->n_sz, key->flags);
+   else
+   key->n = dma_zalloc_coherent(ctx->dev, key->n_sz, >dma_n,
+key->flags);
+
+   if (!key->n) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   memcpy(key->n, ptr, key->n_sz);
+
+   return 0;
+err:
+   key->n_sz = 0;
+   key->n = NULL;
+   return ret;
+}
+
+int raw_rsa_get_e(void *context, size_t hdrlen, unsigned char tag,
+ const void *value, size_t vlen)
+{
+   struct rsa_raw_ctx *ctx = context;
+   struct rsa_raw_key *key = >key;
+   const char *ptr = value;
+
+   while (!*ptr && vlen) {
+   ptr++;
+   vlen--;
+   }
+
+   key->e_sz = vlen;
+
+   if (!key->n_sz || !vlen || vlen > key->n_sz) {
+   key->e = NULL;
+   return -EINVAL;
+   }
+
+   if (key->is_coherent)
+   key->e = kzalloc(key->e_sz, key->flags);
+   else
+   key->e = dma_zalloc_coherent(ctx->dev, key->n_sz, >dma_e,
+key->flags);
+
+   if (!key->e)
+   return -ENOMEM;
+
+   if (key->is_coherent)
+   memcpy(key->e, ptr, key->e_sz);
+   else
+   memcpy(key->e + (key->n_sz - vlen), ptr, vlen);
+
+   return 0;
+}
+
+int raw_rsa_get_d(void *context, size_t hdrlen, unsigned char tag,
+ const void *value, size_t vlen)
+{
+   struct rsa_raw_ctx *ctx = context;
+   struct rsa_raw_key *key = >key;
+   const char *ptr = value;
+   int ret = -EINVAL;
+
+   while (!*ptr && vlen) {
+   ptr++;
+   vlen--;
+   }
+
+   if (!key->n_sz || !vlen || vlen > key->n_sz)
+   goto err;
+
+   /* In FIPS mode only allow key size 2K & 3K */
+   if (fips_enabled && (vlen != 256 && vlen != 384)) {
+   dev_err(ctx->dev, "RSA: key size not allowed in FIPS mode\n");
+   goto err;
+   }
+
+   if (key->is_coherent)
+   key->d = kzalloc(key->n_sz, key->flags);
+   else
+   key->d = dma_zalloc_coherent(ctx->dev, key->n_sz, >dma_d,
+key->flags);
+
+   if (!key->n) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   if (key->is_coherent)
+   memcpy(key->d, ptr, vlen);
+   else
+   memcpy(key->d + (key->n_sz - vlen), ptr,

[PATCH] crypto: marvell/cesa - forward devm_ioremap_resource() error code

2016-03-19 Thread Boris Brezillon 
Forward devm_ioremap_resource() error code instead of returning
-ENOMEM.

Signed-off-by: Boris Brezillon 
Reported-by: Russell King - ARM Linux 
Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's 
CESA")
Cc:  # 4.2+
---
 drivers/crypto/marvell/cesa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0656e7..80239ae 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -420,7 +420,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
cesa->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(cesa->regs))
-   return -ENOMEM;
+   return PTR_ERR(cesa->regs);
 
ret = mv_cesa_dev_dma_init(cesa);
if (ret)
-- 
2.5.0

--
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Sinan Kaya 
On 3/18/2016 9:51 AM, Sinan Kaya wrote:
> Another option is I can write
> 
>  engine->sram_dma = swiotlb_dma_to_phys(res->start)

I realized that I made a mistake in the commit message and the code above.

The code is trying to find DMA address from physical address. Not the other
way around. I'll fix it on the next version. 

The correct suggestion above would be 

  engine->sram_dma = swiotlb_phys_to_dmares->start)

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project
--
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: marvell/cesa - forward devm_ioremap_resource() error code

2016-03-19 Thread Boris Brezillon 
Sorry for the noise, just sent twice the same patch :-/.
Please ignore this one.

On Thu, 17 Mar 2016 10:47:11 +0100
Boris Brezillon  wrote:

> Forward devm_ioremap_resource() error code instead of returning
> -ENOMEM.
> 
> Signed-off-by: Boris Brezillon 
> Reported-by: Russell King - ARM Linux 
> Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's 
> CESA")
> Cc:  # 4.2+
> ---
>  drivers/crypto/marvell/cesa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index c0656e7..80239ae 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -420,7 +420,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
>   cesa->regs = devm_ioremap_resource(dev, res);
>   if (IS_ERR(cesa->regs))
> - return -ENOMEM;
> + return PTR_ERR(cesa->regs);
>  
>   ret = mv_cesa_dev_dma_init(cesa);
>   if (ret)



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 1/2] crypto: marvell/cesa - fix memory leak

2016-03-19 Thread Boris Brezillon 
On Thu, 17 Mar 2016 10:21:34 +0100
Boris Brezillon  wrote:

> Crypto requests are not guaranteed to be finalized (->final() call),
> and can be freed at any moment, without getting any notification from
> the core. This can lead to memory leaks of the ->cache buffer.
> 
> Make this buffer part of the request object, and allocate an extra buffer
> from the DMA cache pool when doing DMA operations.
> 
> As a side effect, this patch also fixes another bug related to cache
> allocation and DMA operations. When the core allocates a new request and
> import an existing state, a cache buffer can be allocated (depending
> on the state). The problem is, at that very moment, we don't know yet
> whether the request will use DMA or not, and since everything is
> likely to be initialized to zero, mv_cesa_ahash_alloc_cache() thinks it
> should allocate a buffer for standard operation. But when
> mv_cesa_ahash_free_cache() is called, req->type has been set to
> CESA_DMA_REQ in the meantime, thus leading to an invalind dma_pool_free()
> call (the buffer passed in argument has not been allocated from the pool).
> 
> Signed-off-by: Boris Brezillon 
> Reported-by: Gregory CLEMENT 

Forgot to add

Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's 
CESA")
Cc: sta...@vger.kernel.org # 4.3+

> ---
>  drivers/crypto/marvell/cesa.h |  3 +-
>  drivers/crypto/marvell/hash.c | 86 
> +--
>  2 files changed, 20 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
> index bd985e7..74071e4 100644
> --- a/drivers/crypto/marvell/cesa.h
> +++ b/drivers/crypto/marvell/cesa.h
> @@ -588,6 +588,7 @@ struct mv_cesa_ahash_dma_req {
>   struct mv_cesa_tdma_req base;
>   u8 *padding;
>   dma_addr_t padding_dma;
> + u8 *cache;
>   dma_addr_t cache_dma;
>  };
>  
> @@ -609,7 +610,7 @@ struct mv_cesa_ahash_req {
>   struct mv_cesa_ahash_std_req std;
>   } req;
>   struct mv_cesa_op_ctx op_tmpl;
> - u8 *cache;
> + u8 cache[CESA_MAX_HASH_BLOCK_SIZE];
>   unsigned int cache_ptr;
>   u64 len;
>   int src_nents;
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index 683cca9..f07c1fa 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -45,69 +45,25 @@ mv_cesa_ahash_req_iter_next_op(struct 
> mv_cesa_ahash_dma_iter *iter)
>   return mv_cesa_req_dma_iter_next_op(>base);
>  }
>  
> -static inline int mv_cesa_ahash_dma_alloc_cache(struct mv_cesa_ahash_req 
> *creq,
> - gfp_t flags)
> +static inline int
> +mv_cesa_ahash_dma_alloc_cache(struct mv_cesa_ahash_dma_req *req, gfp_t flags)
>  {
> - struct mv_cesa_ahash_dma_req *dreq = >req.dma;
> -
> - creq->cache = dma_pool_alloc(cesa_dev->dma->cache_pool, flags,
> -  >cache_dma);
> - if (!creq->cache)
> - return -ENOMEM;
> -
> - return 0;
> -}
> -
> -static inline int mv_cesa_ahash_std_alloc_cache(struct mv_cesa_ahash_req 
> *creq,
> - gfp_t flags)
> -{
> - creq->cache = kzalloc(CESA_MAX_HASH_BLOCK_SIZE, flags);
> - if (!creq->cache)
> + req->cache = dma_pool_alloc(cesa_dev->dma->cache_pool, flags,
> + >cache_dma);
> + if (!req->cache)
>   return -ENOMEM;
>  
>   return 0;
>  }
>  
> -static int mv_cesa_ahash_alloc_cache(struct ahash_request *req)
> -{
> - struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
> - gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
> -   GFP_KERNEL : GFP_ATOMIC;
> - int ret;
> -
> - if (creq->cache)
> - return 0;
> -
> - if (creq->req.base.type == CESA_DMA_REQ)
> - ret = mv_cesa_ahash_dma_alloc_cache(creq, flags);
> - else
> - ret = mv_cesa_ahash_std_alloc_cache(creq, flags);
> -
> - return ret;
> -}
> -
> -static inline void mv_cesa_ahash_dma_free_cache(struct mv_cesa_ahash_req 
> *creq)
> -{
> - dma_pool_free(cesa_dev->dma->cache_pool, creq->cache,
> -   creq->req.dma.cache_dma);
> -}
> -
> -static inline void mv_cesa_ahash_std_free_cache(struct mv_cesa_ahash_req 
> *creq)
> -{
> - kfree(creq->cache);
> -}
> -
> -static void mv_cesa_ahash_free_cache(struct mv_cesa_ahash_req *creq)
> +static inline void
> +mv_cesa_ahash_dma_free_cache(struct mv_cesa_ahash_dma_req *req)
>  {
> - if (!creq->cache)
> + if (!req->cache)
>   return;
>  
> - if (creq->req.base.type == CESA_DMA_REQ)
> - mv_cesa_ahash_dma_free_cache(creq);
> - else
> - mv_cesa_ahash_std_free_cache(creq);
> -
> - creq->cache = NULL;
> + dma_pool_free(cesa_dev->dma->cache_pool, req->cache,

Re: [PATCH] crypto: ccp - fix lock acquisition code

2016-03-19 Thread Herbert Xu 
On Wed, Mar 16, 2016 at 09:02:26AM -0500, Gary R Hook wrote:
> This patch simplifies an unneeded read-write lock.
> 
> Signed-off-by: Gary R Hook 

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 v3 2/8] crypto: add driver-side scomp interface

2016-03-19 Thread Giovanni Cabiddu 
Hi Herbert,

I would like to have some clarifications before submitting a v4.

On Thu, Mar 17, 2016 at 07:00:27PM +0800, Herbert Xu wrote:
> On Wed, Feb 24, 2016 at 05:51:44PM +, Giovanni Cabiddu wrote:
> >
> > +#define CRYPTO_SCOMP_DECOMP_NOCTX CRYPTO_ALG_PRIVATE
> 
> I don't think this should be an scomp-specific flag.  The point of
> noctx is that we don't need to do a request-specific vmalloc.
Are you suggesting to add to the struct acomp_req a pointer to a vmalloc
area and remove the request context (which is contiguous to acomp_req and
allocated in request_alloc)?

> Chances are that with hardware offload that you won't have to do
> such a vmalloc anyway.  IOW acomp implementations are much more
> likely to be of the noctx type than scomp.
Our HW offload will always need a context area in the acomp_req but
I agree, there might be other acomp implementations which won't.

> This is how I think it should work:
> 
> 1. There should be a single request_alloc function that allocates
> just the request without the vmalloc.
> 2. You then have to call an alloc_space function to allocate the
> vmalloc area (let's stop calling it ctx as it may lead to confusion
> with other contexts in the crypto API).
Will allocate_space require a parameter which indicates the direction
of the operation (compression or decompression) or are we relying on the
user of the crypto API to know if he needs to call this function or not?

> The second step can obviously be skipped for the noctx case.
> 
> Also instead of the private bit let's put this into the alg type:
> 
> #define CRYPTO_ALG_TYPE_ACOMP  0x0008
> #define CRYPTO_ALG_TYPE_ACOMP_NOCTX0x0009
> #define CRYPTO_ALG_TYPE_SCOMP  0x000a
> #define CRYPTO_ALG_TYPE_SCOMP_NOCTX0x000b
The reason why Joonsoo Kim proposed the concept of NOCTX was to avoid
allocating a decompression context.
Are you suggesting also to extend this concept to compression as well?
If yes we would need a way to indicate for which direction the driver
requires the context/space. How can we specify that?

> Now that we have killed crypto_hash we can shrink hash down to
> two types and move it to 0xe, freeing up the space for acomp/scomp.
Sounds good.

Thank you,

-- 
Giovanni
--
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: marvell/cesa - forward devm_ioremap_resource() error code

2016-03-19 Thread Boris Brezillon 
Forward devm_ioremap_resource() error code instead of returning
-ENOMEM.

Signed-off-by: Boris Brezillon 
Reported-by: Russell King - ARM Linux 
Fixes: f63601fd616a ("crypto: marvell/cesa - add a new driver for Marvell's 
CESA")
Cc:  # 4.2+
---
 drivers/crypto/marvell/cesa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0656e7..80239ae 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -420,7 +420,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
cesa->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(cesa->regs))
-   return -ENOMEM;
+   return PTR_ERR(cesa->regs);
 
ret = mv_cesa_dev_dma_init(cesa);
if (ret)
-- 
2.5.0

--
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: gcm - Fix rfc4543 decryption crash

2016-03-19 Thread Herbert Xu 
This bug has already bee fixed upstream since 4.2.  However, it
was fixed during the AEAD conversion so no fix was backported to
the older kernels.

When we do an RFC 4543 decryption, we will end up writing the
ICV beyond the end of the dst buffer.  This should lead to a
crash but for some reason it was never noticed.

This patch fixes it by only writing back the ICV for encryption.

Fixes: d733ac90f9fe ("crypto: gcm - fix rfc4543 to handle async...")
Reported-by: Patrick Meyer 
Signed-off-by: Herbert Xu 

diff --git a/crypto/gcm.c b/crypto/gcm.c
index b4c2520..cd97cdd 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -1173,6 +1173,9 @@ static struct aead_request *crypto_rfc4543_crypt(struct 
aead_request *req,
aead_request_set_tfm(subreq, ctx->child);
aead_request_set_callback(subreq, req->base.flags, crypto_rfc4543_done,
  req);
+   if (!enc)
+   aead_request_set_callback(subreq, req->base.flags,
+ req->base.complete, req->base.data);
aead_request_set_crypt(subreq, cipher, cipher, enc ? 0 : authsize, iv);
aead_request_set_assoc(subreq, assoc, assoclen);
 
-- 
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

[PATCH] x86: Avoid undefined behavior in macro expansion

2016-03-19 Thread Vinicius Tinti 
C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined
behavior when one of the result operands is not a valid preprocessing
token.

Therefore the macro expansion may depend on compiler implementation
which may or no preserve the leading white space.

Moreover other places in kernel use CONCAT(a,b) instead of CONCAT(a, b).
Changing favors concise usage.

Signed-off-by: Vinicius Tinti 
Acked-by: Behan Webster 
---
 arch/x86/crypto/aes_ctrby8_avx-x86_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/crypto/aes_ctrby8_avx-x86_64.S 
b/arch/x86/crypto/aes_ctrby8_avx-x86_64.S
index a916c4a..7a71553 100644
--- a/arch/x86/crypto/aes_ctrby8_avx-x86_64.S
+++ b/arch/x86/crypto/aes_ctrby8_avx-x86_64.S
@@ -93,7 +93,7 @@
 
 #define tmp%r10
 #defineDDQ(i)  CONCAT(ddq_add_,i)
-#defineXMM(i)  CONCAT(%xmm, i)
+#defineXMM(i)  CONCAT(%xmm,i)
 #defineDDQ_DATA0
 #defineXDATA   1
 #define KEY_1281
-- 
2.7.3

--
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Boris Brezillon 
On Fri, 18 Mar 2016 11:25:48 +
Robin Murphy  wrote:

> On 18/03/16 09:30, Boris Brezillon wrote:
> > On Thu, 17 Mar 2016 23:50:20 +
> > Russell King - ARM Linux  wrote:
> >
> >> On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
> >>> What is the correct way? I don't want to write engine->sram_dma = sram
> >>
> >> Well, what the driver _is_ wanting to do is to go from a CPU physical
> >> address to a device DMA address.  phys_to_dma() looks like the correct
> >> thing there to me, but I guess that's just an offset and doesn't take
> >> account of any IOMMU that may be in the way.
> >>
> >> If you have an IOMMU, then the whole phys_to_dma() thing is a total
> >> failure as it only does a linear translation, and there are no
> >> interfaces in the kernel to take account of an IOMMU in the way.  So,
> >> it needs something designed for the job, implemented and discussed by
> >> the normal methods of proposing a new cross-arch interface for drivers
> >> to use.
> >>
> >> What I'm certain of, though, is that the change proposed in this patch
> >> will break current users of this driver: virt_to_page() on an address
> >> returned by ioremap() is completely undefined, and will result in
> >> either a kernel oops, or if not poking at memory which isn't a struct
> >> page, ultimately resulting in something that isn't SRAM being pointed
> >> to by "engine->sram_dma".
> >>
> >
> > Or we could just do
> >
> > engine->sram_dma = res->start;
> >
> > which is pretty much what the SRAM/genalloc code is doing already.
> 
> As Russell points out this is yet another type of "set up a DMA master 
> to access something other than kernel RAM" - there's already discussion 
> in progress over how to handle this for dmaengine slaves[1], so 
> gathering more use-cases might help distil exactly what the design of 
> not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else 
> needs to be.
> 
> Robin.
> 
> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.html
> 

Hm, interesting, thanks for the pointer.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 06/10] crypto: qat - fix address leaking of RSA public exponent

2016-03-19 Thread Tudor Ambarus 
Signed-off-by: Tudor Ambarus 
---
 drivers/crypto/qat/qat_common/qat_asym_algs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c 
b/drivers/crypto/qat/qat_common/qat_asym_algs.c
index 8dbbf084..05f49d4 100644
--- a/drivers/crypto/qat/qat_common/qat_asym_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c
@@ -711,7 +711,7 @@ static void qat_rsa_exit_tfm(struct crypto_akcipher *tfm)
}
qat_crypto_put_instance(ctx->inst);
ctx->n = NULL;
-   ctx->d = NULL;
+   ctx->e = NULL;
ctx->d = NULL;
 }
 
-- 
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

[PATCH] PKCS#7: fix missing break on OID_sha224 case

2016-03-19 Thread Colin King 
From: Colin Ian King 

The OID_sha224 case is missing a break and it falls through
to the -ENOPKG error default.  Since HASH_ALGO_SHA224 seems
to be supported, this looks like an unintentional missing break.

Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos 
and use them")
Cc:  # 4.2+
Signed-off-by: Colin Ian King 
---
 crypto/asymmetric_keys/pkcs7_parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/asymmetric_keys/pkcs7_parser.c 
b/crypto/asymmetric_keys/pkcs7_parser.c
index 40de03f..bdd0d753 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -237,6 +237,7 @@ int pkcs7_sig_note_digest_algo(void *context, size_t hdrlen,
break;
case OID_sha224:
ctx->sinfo->sig.hash_algo = "sha224";
+   break;
default:
printk("Unsupported digest algo: %u\n", ctx->last_oid);
return -ENOPKG;
-- 
2.7.3

--
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 10/10] crypto: caam - add support for RSA algorithm

2016-03-19 Thread Stephan Mueller 
Am Freitag, 18. März 2016, 20:32:07 schrieb Tudor Ambarus:

Hi Tudor,

> Add RSA support to caam driver.
> 
> Coauthored-by: Yashpal Dutta 
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  drivers/crypto/caam/Kconfig|  12 +
>  drivers/crypto/caam/Makefile   |   4 +
>  drivers/crypto/caam/caampkc.c  | 513
> + drivers/crypto/caam/caampkc.h  | 
> 84 +++
>  drivers/crypto/caam/desc.h |   2 +
>  drivers/crypto/caam/pdb.h  |  16 +-
>  drivers/crypto/caam/pkc_desc.c | 138 +++
>  7 files changed, 768 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/crypto/caam/caampkc.c
>  create mode 100644 drivers/crypto/caam/caampkc.h
>  create mode 100644 drivers/crypto/caam/pkc_desc.c
> 
> diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
> index 5652a53..5427e63 100644
> --- a/drivers/crypto/caam/Kconfig
> +++ b/drivers/crypto/caam/Kconfig
> @@ -99,6 +99,18 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
> To compile this as a module, choose M here: the module
> will be called caamhash.
> 
> +config CRYPTO_DEV_FSL_CAAM_PKC_API
> +tristate "Register public key cryptography implementations with
> Crypto API" +depends on CRYPTO_DEV_FSL_CAAM &&
> CRYPTO_DEV_FSL_CAAM_JR
> +default y
> +select CRYPTO_RSA_HELPER
> +help
> +  Selecting this will allow SEC Public key support for RSA.
> +  Supported cryptographic primitives: encryption, decryption,
> +  signature and verification.
> +  To compile this as a module, choose M here: the module
> +  will be called caam_pkc.
> +
>  config CRYPTO_DEV_FSL_CAAM_RNG_API
>   tristate "Register caam device for hwrng API"
>   depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
> diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
> index 550758a..399ad55 100644
> --- a/drivers/crypto/caam/Makefile
> +++ b/drivers/crypto/caam/Makefile
> @@ -5,11 +5,15 @@ ifeq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG), y)
>   EXTRA_CFLAGS := -DDEBUG
>  endif
> 
> +ccflags-y += -I$(srctree)/crypto
> +
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
> +obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
> 
>  caam-objs := ctrl.o
>  caam_jr-objs := jr.o key_gen.o error.o
> +caam_pkc-y := caampkc.o pkc_desc.o
> diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
> new file mode 100644
> index 000..1c53158
> --- /dev/null
> +++ b/drivers/crypto/caam/caampkc.c
> @@ -0,0 +1,513 @@
> +/*
> + * caam - Freescale FSL CAAM support for Public Key Cryptography
> + *
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + *
> + * There is no Shared Descriptor for PKC so that the Job Descriptor must
> carry + * all the desired key parameters, input and output pointers.
> + */
> +#include 
> +#include 
> +#include "compat.h"
> +#include "caampkc.h"
> +#include "sg_sw_sec4.h"
> +#include "regs.h"
> +#include "intern.h"
> +#include "jr.h"
> +#include "error.h"
> +
> +void rsa_free_key(struct rsa_raw_key *key)
> +{
> + kzfree(key->d);
> + key->d = NULL;
> +
> + kfree(key->e);
> + key->e = NULL;
> +
> + kfree(key->n);
> + key->n = NULL;
> +
> + key->n_sz = 0;
> + key->e_sz = 0;
> +}

As you implement raw key support for use in other drivers, shouldn't that 
function go into some helper file like free_mpis().
> +
> +static int caam_rsa_setpubkey(struct crypto_akcipher *tfm, const void *key,
> +   unsigned int keylen)
> +{
> + struct rsa_raw_ctx *ctx = akcipher_tfm_ctx(tfm);
> + struct rsa_raw_key *raw_key = >key;
> + int ret;
> +
> + set_raw_rsa_pub_action(>action);
> +
> + /* Free the old key if any */
> + rsa_free_key(raw_key);
> +
> + ret = asn1_ber_decoder(_decoder, ctx, key, keylen);
> + if (ret < 0)
> + goto free;
> +
> + if (!raw_key->n || !raw_key->e) {
> + /* Invalid key provided */
> + ret = -EINVAL;
> + goto free;
> + }
> +
> + return 0;
> +free:
> + rsa_free_key(raw_key);
> + return ret;
> +}
> +
> +static int caam_rsa_setprivkey(struct crypto_akcipher *tfm, const void
> *key, +  unsigned int keylen)
> +{
> + struct rsa_raw_ctx *ctx = akcipher_tfm_ctx(tfm);
> + struct rsa_raw_key *raw_key = >key;
> + int ret;
> +
> + set_raw_rsa_priv_action(>action);
> +
> + /* Free the old key if any */
> + rsa_free_key(raw_key);
> +
> + ret = asn1_ber_decoder(_decoder, ctx, key, keylen);
> + if (ret < 0)
> + goto free;
> +
> + if (!raw_key->n || !raw_key->e || !raw_key->d) {
> + /*

[PATCH 04/10] crypto: rsa_helper - export symbols for asn1 structures

2016-03-19 Thread Tudor Ambarus 
Export rsapubkey_decoder and rsaprivkey_decoder structures,
since they can (will) be used by caam and qat drivers.

Signed-off-by: Tudor Ambarus 
---
 crypto/rsa_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/crypto/rsa_helper.c b/crypto/rsa_helper.c
index 1708db8..14aef69 100644
--- a/crypto/rsa_helper.c
+++ b/crypto/rsa_helper.c
@@ -21,6 +21,9 @@
 #include "rsapubkey-asn1.h"
 #include "rsaprivkey-asn1.h"
 
+EXPORT_SYMBOL_GPL(rsapubkey_decoder);
+EXPORT_SYMBOL_GPL(rsaprivkey_decoder);
+
 int rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
  const void *value, size_t vlen)
 {
-- 
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 v3 2/8] crypto: add driver-side scomp interface

2016-03-19 Thread Herbert Xu 
On Wed, Feb 24, 2016 at 05:51:44PM +, Giovanni Cabiddu wrote:
>
> +#define CRYPTO_SCOMP_DECOMP_NOCTX CRYPTO_ALG_PRIVATE

I don't think this should be an scomp-specific flag.  The point of
noctx is that we don't need to do a request-specific vmalloc.
Chances are that with hardware offload that you won't have to do
such a vmalloc anyway.  IOW acomp implementations are much more
likely to be of the noctx type than scomp.

This is how I think it should work:

1. There should be a single request_alloc function that allocates
just the request without the vmalloc.
2. You then have to call an alloc_space function to allocate the
vmalloc area (let's stop calling it ctx as it may lead to confusion
with other contexts in the crypto API).

The second step can obviously be skipped for the noctx case.

Also instead of the private bit let's put this into the alg type:

#define CRYPTO_ALG_TYPE_ACOMP  0x0008
#define CRYPTO_ALG_TYPE_ACOMP_NOCTX0x0009
#define CRYPTO_ALG_TYPE_SCOMP  0x000a
#define CRYPTO_ALG_TYPE_SCOMP_NOCTX0x000b

Now that we have killed crypto_hash we can shrink hash down to
two types and move it to 0xe, freeing up the space for acomp/scomp.

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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Robin Murphy 

On 18/03/16 09:30, Boris Brezillon wrote:

On Thu, 17 Mar 2016 23:50:20 +
Russell King - ARM Linux  wrote:


On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:

What is the correct way? I don't want to write engine->sram_dma = sram


Well, what the driver _is_ wanting to do is to go from a CPU physical
address to a device DMA address.  phys_to_dma() looks like the correct
thing there to me, but I guess that's just an offset and doesn't take
account of any IOMMU that may be in the way.

If you have an IOMMU, then the whole phys_to_dma() thing is a total
failure as it only does a linear translation, and there are no
interfaces in the kernel to take account of an IOMMU in the way.  So,
it needs something designed for the job, implemented and discussed by
the normal methods of proposing a new cross-arch interface for drivers
to use.

What I'm certain of, though, is that the change proposed in this patch
will break current users of this driver: virt_to_page() on an address
returned by ioremap() is completely undefined, and will result in
either a kernel oops, or if not poking at memory which isn't a struct
page, ultimately resulting in something that isn't SRAM being pointed
to by "engine->sram_dma".



Or we could just do

engine->sram_dma = res->start;

which is pretty much what the SRAM/genalloc code is doing already.


As Russell points out this is yet another type of "set up a DMA master 
to access something other than kernel RAM" - there's already discussion 
in progress over how to handle this for dmaengine slaves[1], so 
gathering more use-cases might help distil exactly what the design of 
not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else 
needs to be.


Robin.

[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.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

Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread kbuild test robot 
Hi Sinan,

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.5 next-20160318]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/crypto-marvell-cesa-replace-dma_to_phys-with-dma_map_single/20160318-060640
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 
for-next/core
config: arm-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/crypto/marvell/cesa.c: In function 'mv_cesa_get_sram':
>> drivers/crypto/marvell/cesa.c:354:21: error: macro "dma_map_single" requires 
>> 4 arguments, but only 3 given
   DMA_TO_DEVICE);
^
>> drivers/crypto/marvell/cesa.c:353:21: error: 'dma_map_single' undeclared 
>> (first use in this function)
 engine->sram_dma = dma_map_single(cesa->dev, engine->sram,
^
   drivers/crypto/marvell/cesa.c:353:21: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/dma_map_single +354 drivers/crypto/marvell/cesa.c

   347  return -EINVAL;
   348  
   349  engine->sram = devm_ioremap_resource(cesa->dev, res);
   350  if (IS_ERR(engine->sram))
   351  return PTR_ERR(engine->sram);
   352  
 > 353  engine->sram_dma = dma_map_single(cesa->dev, engine->sram,
 > 354DMA_TO_DEVICE);
   355  
   356  return 0;
   357  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

RE: RE

2016-03-19 Thread Robert 
Please confirm receipt of my previous mail..When can i call you 
--
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread okaya 

On 2016-03-17 18:54, Russell King - ARM Linux wrote:

On Thu, Mar 17, 2016 at 06:02:15PM -0400, Sinan Kaya wrote:

Getting ready to remove dma_to_phys API. Drivers should not be
using this API for DMA operations. Instead, they should go
through the dma_map or dma_alloc APIs.

Signed-off-by: Sinan Kaya 
---
 drivers/crypto/marvell/cesa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/marvell/cesa.c 
b/drivers/crypto/marvell/cesa.c

index c0656e7..52ddfa4 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -350,8 +350,8 @@ static int mv_cesa_get_sram(struct platform_device 
*pdev, int idx)

if (IS_ERR(engine->sram))
return PTR_ERR(engine->sram);

-   engine->sram_dma = phys_to_dma(cesa->dev,
-  (phys_addr_t)res->start);
+   engine->sram_dma = dma_map_single(cesa->dev, engine->sram,
+ DMA_TO_DEVICE);


Documentation/DMA-API.txt

dma_addr_t
dma_map_single(struct device *dev, void *cpu_addr, size_t size,
  enum dma_data_direction direction)

Notes:  Not all memory regions in a machine can be mapped by this API.
Further, contiguous kernel virtual space may not be contiguous as
physical memory.  Since this API does not provide any scatter/gather
capability, it will fail if the user tries to map a non-physically
contiguous piece of memory.  For this reason, memory to be mapped by
this API should be obtained from sources which guarantee it to be
physically contiguous (like kmalloc).

Specifically, ioremapped memory will *not* work as you expect with
dma_map_single().



What is the correct way? I don't want to write engine->sram_dma = sram

--
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 02/10] crypto: rsa_helper - add raw integer parser actions

2016-03-19 Thread Stephan Mueller 
Am Freitag, 18. März 2016, 20:31:59 schrieb Tudor Ambarus:

Hi Tudor,

> Dedicated to RSA (hardware) implementations that want to use
> raw integers instead of MPI keys.
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  crypto/rsa.c  |  15 
>  crypto/rsa_helper.c   | 158
> ++ include/crypto/internal/rsa.h | 
> 24 +++
>  3 files changed, 182 insertions(+), 15 deletions(-)
> 
> diff --git a/crypto/rsa.c b/crypto/rsa.c
> index 2d53ad8..44baccf 100644
> --- a/crypto/rsa.c
> +++ b/crypto/rsa.c
> @@ -235,21 +235,6 @@ err_free_m:
>   return ret;
>  }
> 
> -static int rsa_check_key_length(unsigned int len)
> -{
> - switch (len) {
> - case 512:
> - case 1024:
> - case 1536:
> - case 2048:
> - case 3072:
> - case 4096:
> - return 0;
> - }
> -
> - return -EINVAL;
> -}
> -
>  static int rsa_set_pub_key(struct crypto_akcipher *tfm, const void *key,
>  unsigned int keylen)
>  {
> diff --git a/crypto/rsa_helper.c b/crypto/rsa_helper.c
> index 1ed32af..1708db8 100644
> --- a/crypto/rsa_helper.c
> +++ b/crypto/rsa_helper.c
> @@ -14,6 +14,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include "rsapubkey-asn1.h"
>  #include "rsaprivkey-asn1.h"
> @@ -190,3 +193,158 @@ void set_rsa_priv_action(struct rsa_asn1_action
> *action) action->get_n = rsa_get_mpi_n;
>  }
>  EXPORT_SYMBOL_GPL(set_rsa_priv_action);
> +
> +int rsa_check_key_length(unsigned int len)
> +{
> + switch (len) {
> + case 512:
> + case 1024:
> + case 1536:
> + case 2048:
> + case 3072:
> + case 4096:
> + return 0;
> + }

I know that you copied the code to a new location that was there already. But 
based on the discussion we had for DH, does it make sense that the kernel adds 
such (artificial) limits?
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(rsa_check_key_length);
> +
> +int raw_rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> +   const void *value, size_t vlen)
> +{
> + struct rsa_raw_ctx *ctx = context;
> + struct rsa_raw_key *key = >key;
> + const char *ptr = value;
> + int ret = -EINVAL;
> +
> + while (!*ptr && vlen) {
> + ptr++;
> + vlen--;
> + }
> +
> + key->n_sz = vlen;
> + /* In FIPS mode only allow key size 2K & 3K */
> + if (fips_enabled && (key->n_sz != 256 && key->n_sz != 384)) {

Again, you copied that code that used to be there . But very very recently, 
NIST allowed 4k keys too. May I ask to allow it here?

> + dev_err(ctx->dev, "RSA: key size not allowed in FIPS mode\n");
> + goto err;
> + }
> + /* invalid key size provided */
> + ret = rsa_check_key_length(key->n_sz << 3);
> + if (ret)
> + goto err;
> +
> + if (key->is_coherent)
> + key->n = kzalloc(key->n_sz, key->flags);
> + else
> + key->n = dma_zalloc_coherent(ctx->dev, key->n_sz, >dma_n,
> +  key->flags);
> +
> + if (!key->n) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + memcpy(key->n, ptr, key->n_sz);
> +
> + return 0;
> +err:
> + key->n_sz = 0;
> + key->n = NULL;
> + return ret;
> +}
> +
> +int raw_rsa_get_e(void *context, size_t hdrlen, unsigned char tag,
> +   const void *value, size_t vlen)
> +{
> + struct rsa_raw_ctx *ctx = context;
> + struct rsa_raw_key *key = >key;
> + const char *ptr = value;
> +
> + while (!*ptr && vlen) {
> + ptr++;
> + vlen--;
> + }
> +
> + key->e_sz = vlen;
> +
> + if (!key->n_sz || !vlen || vlen > key->n_sz) {
> + key->e = NULL;
> + return -EINVAL;
> + }
> +
> + if (key->is_coherent)
> + key->e = kzalloc(key->e_sz, key->flags);
> + else
> + key->e = dma_zalloc_coherent(ctx->dev, key->n_sz, >dma_e,
> +  key->flags);
> +
> + if (!key->e)
> + return -ENOMEM;
> +
> + if (key->is_coherent)
> + memcpy(key->e, ptr, key->e_sz);
> + else
> + memcpy(key->e + (key->n_sz - vlen), ptr, vlen);
> +
> + return 0;
> +}
> +
> +int raw_rsa_get_d(void *context, size_t hdrlen, unsigned char tag,
> +   const void *value, size_t vlen)
> +{
> + struct rsa_raw_ctx *ctx = context;
> + struct rsa_raw_key *key = >key;
> + const char *ptr = value;
> + int ret = -EINVAL;
> +
> + while (!*ptr && vlen) {
> + ptr++;
> + vlen--;
> + }
> +
> + if (!key->n_sz || !vlen || vlen > key->n_sz)
> + goto err;
> +
> + /* In FIPS mode only allow key size 2K & 3K */
> + if (fips_enabled && (vlen != 256 && vlen != 384)) {
> + dev_err(ctx->dev, "RSA: key size not

[PATCH 01/10] crypto: rsa - generalize ASN.1 sequences

2016-03-19 Thread Tudor Ambarus 
Use common ASN.1 sequences for all RSA implementations.

Give hardware RSA implementations the chance to use
the RSA's software implementation parser even if they
are likely to want to use raw integers.

The parser expects a context that contains at the first address
a struct rsa_asn1_action with function pointers to specific
parser actions (return MPI or raw integer keys), followed by
a key representation structure (for MPI or raw integers).

This approach has the advantage that users can select specific
parser actions by using a general parser with function pointers
to specific actions.

Signed-off-by: Tudor Ambarus 
---
 crypto/rsa.c  |  48 +
 crypto/rsa_helper.c   | 117 +-
 include/crypto/internal/rsa.h |  28 +++---
 3 files changed, 130 insertions(+), 63 deletions(-)

diff --git a/crypto/rsa.c b/crypto/rsa.c
index 77d737f..2d53ad8 100644
--- a/crypto/rsa.c
+++ b/crypto/rsa.c
@@ -19,7 +19,7 @@
  * RSAEP function [RFC3447 sec 5.1.1]
  * c = m^e mod n;
  */
-static int _rsa_enc(const struct rsa_key *key, MPI c, MPI m)
+static int _rsa_enc(const struct rsa_mpi_key *key, MPI c, MPI m)
 {
/* (1) Validate 0 <= m < n */
if (mpi_cmp_ui(m, 0) < 0 || mpi_cmp(m, key->n) >= 0)
@@ -33,7 +33,7 @@ static int _rsa_enc(const struct rsa_key *key, MPI c, MPI m)
  * RSADP function [RFC3447 sec 5.1.2]
  * m = c^d mod n;
  */
-static int _rsa_dec(const struct rsa_key *key, MPI m, MPI c)
+static int _rsa_dec(const struct rsa_mpi_key *key, MPI m, MPI c)
 {
/* (1) Validate 0 <= c < n */
if (mpi_cmp_ui(c, 0) < 0 || mpi_cmp(c, key->n) >= 0)
@@ -47,7 +47,7 @@ static int _rsa_dec(const struct rsa_key *key, MPI m, MPI c)
  * RSASP1 function [RFC3447 sec 5.2.1]
  * s = m^d mod n
  */
-static int _rsa_sign(const struct rsa_key *key, MPI s, MPI m)
+static int _rsa_sign(const struct rsa_mpi_key *key, MPI s, MPI m)
 {
/* (1) Validate 0 <= m < n */
if (mpi_cmp_ui(m, 0) < 0 || mpi_cmp(m, key->n) >= 0)
@@ -61,7 +61,7 @@ static int _rsa_sign(const struct rsa_key *key, MPI s, MPI m)
  * RSAVP1 function [RFC3447 sec 5.2.2]
  * m = s^e mod n;
  */
-static int _rsa_verify(const struct rsa_key *key, MPI m, MPI s)
+static int _rsa_verify(const struct rsa_mpi_key *key, MPI m, MPI s)
 {
/* (1) Validate 0 <= s < n */
if (mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0)
@@ -71,15 +71,17 @@ static int _rsa_verify(const struct rsa_key *key, MPI m, 
MPI s)
return mpi_powm(m, s, key->e, key->n);
 }
 
-static inline struct rsa_key *rsa_get_key(struct crypto_akcipher *tfm)
+static inline struct rsa_mpi_key *rsa_get_key(struct crypto_akcipher *tfm)
 {
-   return akcipher_tfm_ctx(tfm);
+   struct rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
+
+   return >key;
 }
 
 static int rsa_enc(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI m, c = mpi_alloc(0);
int ret = 0;
int sign;
@@ -118,7 +120,7 @@ err_free_c:
 static int rsa_dec(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI c, m = mpi_alloc(0);
int ret = 0;
int sign;
@@ -156,7 +158,7 @@ err_free_m:
 static int rsa_sign(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI m, s = mpi_alloc(0);
int ret = 0;
int sign;
@@ -195,7 +197,7 @@ err_free_s:
 static int rsa_verify(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI s, m = mpi_alloc(0);
int ret = 0;
int sign;
@@ -251,15 +253,18 @@ static int rsa_check_key_length(unsigned int len)
 static int rsa_set_pub_key(struct crypto_akcipher *tfm, const void *key,
   unsigned int keylen)
 {
-   struct rsa_key *pkey = akcipher_tfm_ctx(tfm);
+   struct rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct rsa_mpi_key *pkey = >key;
int ret;
 
-   ret = rsa_parse_pub_key(pkey, key, keylen);
+   set_rsa_pub_action(>action);
+
+   ret = rsa_parse_mpi_pub_key(ctx, key, keylen);
if (ret)
return ret;
 
if (rsa_check_key_length(mpi_get_size(pkey->n) << 3)) {
-   rsa_free_key(pkey);
+   rsa_free_mpi_key(pkey);
ret = -EINVAL;
}
return ret;
@@ -268,15 +273,18 @@ static int rsa_set_pub_key(struct

Re: [PATCH] crypto: gcm - Fix rfc4543 decryption crash

2016-03-19 Thread Herbert Xu 
On Fri, Mar 18, 2016 at 10:34:23AM -0700, Greg KH wrote:
> On Fri, Mar 18, 2016 at 10:42:40PM +0800, Herbert Xu wrote:
> > This bug has already bee fixed upstream since 4.2.  However, it
> > was fixed during the AEAD conversion so no fix was backported to
> > the older kernels.
> 
> What was the commit id of that fix?

commit adcbc688fe2f8107b7f564187593293aa9ea3932
Author: Herbert Xu 
Date:   Tue Jun 16 13:54:18 2015 +0800

crypto: gcm - Convert to new AEAD interface
 
> What stable kernel(s) do you want this in?

Since the fix was merged in 4.2 this is needed on all kernels
prior to that, i.e., 4.1 and any prior version.

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

[PATCH 07/10] crypto: qat - remove duplicate ASN.1 parser

2016-03-19 Thread Tudor Ambarus 
Use the RSA's software implementation parser with
raw integer actions.

Compile-tested only.

Signed-off-by: Tudor Ambarus 
---
 drivers/crypto/qat/Kconfig|   3 +-
 drivers/crypto/qat/qat_common/Makefile|  10 +-
 drivers/crypto/qat/qat_common/qat_asym_algs.c | 265 +++---
 drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1 |  11 -
 drivers/crypto/qat/qat_common/qat_rsapubkey.asn1  |   4 -
 5 files changed, 83 insertions(+), 210 deletions(-)
 delete mode 100644 drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1
 delete mode 100644 drivers/crypto/qat/qat_common/qat_rsapubkey.asn1

diff --git a/drivers/crypto/qat/Kconfig b/drivers/crypto/qat/Kconfig
index 85b44e5..59314e6 100644
--- a/drivers/crypto/qat/Kconfig
+++ b/drivers/crypto/qat/Kconfig
@@ -3,13 +3,12 @@ config CRYPTO_DEV_QAT
select CRYPTO_AEAD
select CRYPTO_AUTHENC
select CRYPTO_BLKCIPHER
-   select CRYPTO_AKCIPHER
select CRYPTO_HMAC
select CRYPTO_SHA1
select CRYPTO_SHA256
select CRYPTO_SHA512
select FW_LOADER
-   select ASN1
+   select CRYPTO_RSA_HELPER
 
 config CRYPTO_DEV_QAT_DH895xCC
tristate "Support for Intel(R) DH895xCC"
diff --git a/drivers/crypto/qat/qat_common/Makefile 
b/drivers/crypto/qat/qat_common/Makefile
index 29c7c53..dd62918 100644
--- a/drivers/crypto/qat/qat_common/Makefile
+++ b/drivers/crypto/qat/qat_common/Makefile
@@ -1,10 +1,4 @@
-$(obj)/qat_rsapubkey-asn1.o: $(obj)/qat_rsapubkey-asn1.c \
-$(obj)/qat_rsapubkey-asn1.h
-$(obj)/qat_rsaprivkey-asn1.o: $(obj)/qat_rsaprivkey-asn1.c \
- $(obj)/qat_rsaprivkey-asn1.h
-
-clean-files += qat_rsapubkey-asn1.c qat_rsapubkey-asn1.h
-clean-files += qat_rsaprivkey-asn1.c qat_rsaprivkey-asn1.h
+ccflags-y += -I$(srctree)/crypto
 
 obj-$(CONFIG_CRYPTO_DEV_QAT) += intel_qat.o
 intel_qat-objs := adf_cfg.o \
@@ -20,8 +14,6 @@ intel_qat-objs := adf_cfg.o \
adf_hw_arbiter.o \
qat_crypto.o \
qat_algs.o \
-   qat_rsapubkey-asn1.o \
-   qat_rsaprivkey-asn1.o \
qat_asym_algs.o \
qat_uclo.o \
qat_hal.o
diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c 
b/drivers/crypto/qat/qat_common/qat_asym_algs.c
index 05f49d4..196269c5 100644
--- a/drivers/crypto/qat/qat_common/qat_asym_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c
@@ -52,8 +52,8 @@
 #include 
 #include 
 #include 
-#include "qat_rsapubkey-asn1.h"
-#include "qat_rsaprivkey-asn1.h"
+#include "rsapubkey-asn1.h"
+#include "rsaprivkey-asn1.h"
 #include "icp_qat_fw_pke.h"
 #include "adf_accel_devices.h"
 #include "adf_transport.h"
@@ -92,13 +92,7 @@ struct qat_rsa_output_params {
 } __packed __aligned(64);
 
 struct qat_rsa_ctx {
-   char *n;
-   char *e;
-   char *d;
-   dma_addr_t dma_n;
-   dma_addr_t dma_e;
-   dma_addr_t dma_d;
-   unsigned int key_sz;
+   struct rsa_raw_ctx raw_key_ctx;
struct qat_crypto_instance *inst;
 } __packed __aligned(64);
 
@@ -118,6 +112,7 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp)
 {
struct akcipher_request *areq = (void *)(__force long)resp->opaque;
struct qat_rsa_request *req = PTR_ALIGN(akcipher_request_ctx(areq), 64);
+   struct rsa_raw_key *key = >ctx->raw_key_ctx.key;
struct device *dev = _DEV(req->ctx->inst->accel_dev);
int err = ICP_QAT_FW_PKE_RESP_PKE_STAT_GET(
resp->pke_resp_hdr.comn_resp_flags);
@@ -125,13 +120,12 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp)
err = (err == ICP_QAT_FW_COMN_STATUS_FLAG_OK) ? 0 : -EINVAL;
 
if (req->src_align)
-   dma_free_coherent(dev, req->ctx->key_sz, req->src_align,
+   dma_free_coherent(dev, key->n_sz, req->src_align,
  req->in.enc.m);
else
-   dma_unmap_single(dev, req->in.enc.m, req->ctx->key_sz,
-DMA_TO_DEVICE);
+   dma_unmap_single(dev, req->in.enc.m, key->n_sz, DMA_TO_DEVICE);
 
-   areq->dst_len = req->ctx->key_sz;
+   areq->dst_len = key->n_sz;
if (req->dst_align) {
char *ptr = req->dst_align;
 
@@ -140,13 +134,13 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp)
ptr++;
}
 
-   if (areq->dst_len != req->ctx->key_sz)
+   if (areq->dst_len != key->n_sz)
memmove(req->dst_align, ptr, areq->dst_len);
 
scatterwalk_map_and_copy(req->dst_align, areq->dst, 0,
 areq->dst_len, 1);
 
-   dma_free_coherent(dev, req->ctx->key_sz, req->dst_align,
+   dma_free_coherent(dev, key->n_sz, req->dst_align,
  req->out.enc.c);
} else {
char *ptr = sg_virt(areq->dst);
@@

[PATCH 03/10] crypto: add CONFIG_ symbol for rsa helper

2016-03-19 Thread Tudor Ambarus 
All RSA implementations can now use the key extract symbols
by selecting CRYPTO_RSA_HELPER.

Signed-off-by: Tudor Ambarus 
---
 crypto/Kconfig  | 8 ++--
 crypto/Makefile | 6 +++---
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index f6bfdda..2bdf882 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -93,11 +93,15 @@ config CRYPTO_AKCIPHER
select CRYPTO_AKCIPHER2
select CRYPTO_ALGAPI
 
-config CRYPTO_RSA
-   tristate "RSA algorithm"
+config CRYPTO_RSA_HELPER
+   bool "RSA key extract helper"
select CRYPTO_AKCIPHER
select MPILIB
select ASN1
+
+config CRYPTO_RSA
+   tristate "RSA algorithm"
+   select CRYPTO_RSA_HELPER
help
  Generic implementation of the RSA public key algorithm.
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 4f4ef7e..d336d83 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -36,10 +36,10 @@ $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c 
$(obj)/rsaprivkey-asn1.h
 clean-files += rsapubkey-asn1.c rsapubkey-asn1.h
 clean-files += rsaprivkey-asn1.c rsaprivkey-asn1.h
 
-rsa_generic-y := rsapubkey-asn1.o
-rsa_generic-y += rsaprivkey-asn1.o
+crypto_rsa_helper-y += rsapubkey-asn1.o rsaprivkey-asn1.o rsa_helper.o
+obj-$(CONFIG_CRYPTO_RSA_HELPER) += crypto_rsa_helper.o
+
 rsa_generic-y += rsa.o
-rsa_generic-y += rsa_helper.o
 rsa_generic-y += rsa-pkcs1pad.o
 obj-$(CONFIG_CRYPTO_RSA) += rsa_generic.o
 
-- 
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

[PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Sinan Kaya 
Getting ready to remove dma_to_phys API. Drivers should not be
using this API for DMA operations. Instead, they should go
through the dma_map or dma_alloc APIs.

Signed-off-by: Sinan Kaya 
---
 drivers/crypto/marvell/cesa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0656e7..52ddfa4 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -350,8 +350,8 @@ static int mv_cesa_get_sram(struct platform_device *pdev, 
int idx)
if (IS_ERR(engine->sram))
return PTR_ERR(engine->sram);
 
-   engine->sram_dma = phys_to_dma(cesa->dev,
-  (phys_addr_t)res->start);
+   engine->sram_dma = dma_map_single(cesa->dev, engine->sram,
+ DMA_TO_DEVICE);
 
return 0;
 }
-- 
1.8.2.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

[PATCH 08/10] crypto: scatterwak - Add scatterwalk_sg_copychunks

2016-03-19 Thread Tudor Ambarus 
This patch adds the function scatterwalk_sg_copychunks which writes
a chunk of data from a scatterwalk to another scatterwalk.
It will be used by caam driver to remove the leading zeros of RSA's
algorithm output.

Signed-off-by: Tudor Ambarus 
---
 crypto/scatterwalk.c | 26 ++
 include/crypto/scatterwalk.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index ea5815c..bc3222d 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -125,6 +125,32 @@ void scatterwalk_map_and_copy(void *buf, struct 
scatterlist *sg,
 }
 EXPORT_SYMBOL_GPL(scatterwalk_map_and_copy);
 
+void scatterwalk_sg_copychunks(struct scatter_walk *dest,
+  struct scatter_walk *src, size_t nbytes)
+{
+   for (;;) {
+   unsigned int len_this_page = scatterwalk_pagelen(dest);
+   u8 *vaddr;
+
+   if (len_this_page > nbytes)
+   len_this_page = nbytes;
+
+   vaddr = scatterwalk_map(dest);
+   scatterwalk_copychunks(vaddr, src, len_this_page, 0);
+   scatterwalk_unmap(vaddr);
+
+   scatterwalk_advance(dest, len_this_page);
+
+   if (nbytes == len_this_page)
+   break;
+
+   nbytes -= len_this_page;
+
+   scatterwalk_pagedone(dest, 0, 1);
+   }
+}
+EXPORT_SYMBOL_GPL(scatterwalk_sg_copychunks);
+
 int scatterwalk_bytes_sglen(struct scatterlist *sg, int num_bytes)
 {
int offset = 0, n = 0;
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 35f99b6..8b799c5 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -86,6 +86,8 @@ static inline void scatterwalk_unmap(void *vaddr)
 void scatterwalk_start(struct scatter_walk *walk, struct scatterlist *sg);
 void scatterwalk_copychunks(void *buf, struct scatter_walk *walk,
size_t nbytes, int out);
+void scatterwalk_sg_copychunks(struct scatter_walk *dest,
+  struct scatter_walk *src, size_t nbytes);
 void *scatterwalk_map(struct scatter_walk *walk);
 void scatterwalk_done(struct scatter_walk *walk, int out, int more);
 
-- 
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Russell King - ARM Linux 
On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
> What is the correct way? I don't want to write engine->sram_dma = sram

Well, what the driver _is_ wanting to do is to go from a CPU physical
address to a device DMA address.  phys_to_dma() looks like the correct
thing there to me, but I guess that's just an offset and doesn't take
account of any IOMMU that may be in the way.

If you have an IOMMU, then the whole phys_to_dma() thing is a total
failure as it only does a linear translation, and there are no
interfaces in the kernel to take account of an IOMMU in the way.  So,
it needs something designed for the job, implemented and discussed by
the normal methods of proposing a new cross-arch interface for drivers
to use.

What I'm certain of, though, is that the change proposed in this patch
will break current users of this driver: virt_to_page() on an address
returned by ioremap() is completely undefined, and will result in
either a kernel oops, or if not poking at memory which isn't a struct
page, ultimately resulting in something that isn't SRAM being pointed
to by "engine->sram_dma".

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: ccp - fix lock acquisition code

2016-03-19 Thread Gary R Hook 
This patch simplifies an unneeded read-write lock.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 336e5b7..4dbc187 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -53,7 +53,7 @@ static DEFINE_RWLOCK(ccp_unit_lock);
 static LIST_HEAD(ccp_units);
 
 /* Round-robin counter */
-static DEFINE_RWLOCK(ccp_rr_lock);
+static DEFINE_SPINLOCK(ccp_rr_lock);
 static struct ccp_device *ccp_rr;
 
 /* Ever-increasing value to produce unique unit numbers */
@@ -128,14 +128,14 @@ static struct ccp_device *ccp_get_device(void)
 */
read_lock_irqsave(_unit_lock, flags);
if (!list_empty(_units)) {
-   write_lock_irqsave(_rr_lock, flags);
+   spin_lock(_rr_lock);
dp = ccp_rr;
if (list_is_last(_rr->entry, _units))
ccp_rr = list_first_entry(_units, struct ccp_device,
  entry);
else
ccp_rr = list_next_entry(ccp_rr, entry);
-   write_unlock_irqrestore(_rr_lock, flags);
+   spin_unlock(_rr_lock);
}
read_unlock_irqrestore(_unit_lock, flags);
 

--
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: n2 - Remove return statement from void function

2016-03-19 Thread Amitoj Kaur Chawla 
Return statement at the end of a void function is useless.

The Coccinelle semantic patch used to make this change is as follows:
//
@@
identifier f;
expression e;
@@
void f(...) {
<...
- return
  e;
...>
}
//

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/crypto/n2_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index b85a7a7..c5aac25 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -1598,7 +1598,7 @@ static void *new_queue(unsigned long q_type)
 
 static void free_queue(void *p, unsigned long q_type)
 {
-   return kmem_cache_free(queue_cache[q_type - 1], p);
+   kmem_cache_free(queue_cache[q_type - 1], p);
 }
 
 static int queue_cache_init(void)
-- 
1.9.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

[PATCH 05/10] crypto: qat - avoid memory corruption or undefined behaviour

2016-03-19 Thread Tudor Ambarus 
memcopying to a (null pointer + offset) will result
in memory corruption or undefined behaviour.

Signed-off-by: Tudor Ambarus 
---
 drivers/crypto/qat/qat_common/qat_asym_algs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c 
b/drivers/crypto/qat/qat_common/qat_asym_algs.c
index e5c0727..8dbbf084 100644
--- a/drivers/crypto/qat/qat_common/qat_asym_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c
@@ -593,7 +593,7 @@ int qat_rsa_get_d(void *context, size_t hdrlen, unsigned 
char tag,
 
ret = -ENOMEM;
ctx->d = dma_zalloc_coherent(dev, ctx->key_sz, >dma_d, GFP_KERNEL);
-   if (!ctx->n)
+   if (!ctx->d)
goto err;
 
memcpy(ctx->d + (ctx->key_sz - vlen), ptr, vlen);
-- 
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

КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79139393506 Email: mnoskova...@gmail.com Skype: prodawez389

2016-03-19 Thread linux-crypto@vger.kernel.org 
КЛИЕНТСКИЕ БАЗЫ!

Соберем для Вас по интернет базу данных потенциальных клиентов 
для Вашего Бизнеса!
Много! Быстро! Недорого! 
Узнайте об этом подробнее по 
Тел: +79139393506
Viber: +79139393506
Whatsapp: +79139393506
Skype: prodawez389
Email: mnoskova...@gmail.com
--
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: cleaning and refactoring in rsa.c

2016-03-19 Thread maitesin 
* Removed several unused initializations of variables.
* Inlined couple of functions.
* rsa_check_key_length: changed to use only the switch statement.
* rsa_setkey: refactored the implementation to be closer to the other
functions in the file.

Signed-off-by: Oscar Forner Martinez 
---
 crypto/rsa.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/crypto/rsa.c b/crypto/rsa.c
index 466003e..0832b38 100644
--- a/crypto/rsa.c
+++ b/crypto/rsa.c
@@ -80,8 +80,7 @@ static int rsa_enc(struct akcipher_request *req)
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
const struct rsa_key *pkey = rsa_get_key(tfm);
MPI m, c = mpi_alloc(0);
-   int ret = 0;
-   int sign;
+   int ret, sign;
 
if (!c)
return -ENOMEM;
@@ -128,8 +127,7 @@ static int rsa_dec(struct akcipher_request *req)
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
const struct rsa_key *pkey = rsa_get_key(tfm);
MPI c, m = mpi_alloc(0);
-   int ret = 0;
-   int sign;
+   int ret, sign;
 
if (!m)
return -ENOMEM;
@@ -176,8 +174,7 @@ static int rsa_sign(struct akcipher_request *req)
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
const struct rsa_key *pkey = rsa_get_key(tfm);
MPI m, s = mpi_alloc(0);
-   int ret = 0;
-   int sign;
+   int ret, sign;
 
if (!s)
return -ENOMEM;
@@ -224,8 +221,7 @@ static int rsa_verify(struct akcipher_request *req)
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
const struct rsa_key *pkey = rsa_get_key(tfm);
MPI s, m = mpi_alloc(0);
-   int ret = 0;
-   int sign;
+   int ret, sign;
 
if (!m)
return -ENOMEM;
@@ -277,25 +273,24 @@ static int rsa_check_key_length(unsigned int len)
case 3072:
case 4096:
return 0;
+   default:
+   return -EINVAL;
}
-
-   return -EINVAL;
 }
 
 static int rsa_setkey(struct crypto_akcipher *tfm, const void *key,
  unsigned int keylen)
 {
struct rsa_key *pkey = akcipher_tfm_ctx(tfm);
-   int ret;
+   int ret = rsa_parse_key(pkey, key, keylen);
 
-   ret = rsa_parse_key(pkey, key, keylen);
if (ret)
return ret;
 
-   if (rsa_check_key_length(mpi_get_size(pkey->n) << 3)) {
+   ret = rsa_check_key_length(mpi_get_size(pkey->n) << 3);
+   if (ret)
rsa_free_key(pkey);
-   ret = -EINVAL;
-   }
+
return ret;
 }
 
@@ -322,12 +317,12 @@ static struct akcipher_alg rsa = {
},
 };
 
-static int rsa_init(void)
+static inline int rsa_init(void)
 {
return crypto_register_akcipher();
 }
 
-static void rsa_exit(void)
+static inline void rsa_exit(void)
 {
crypto_unregister_akcipher();
 }
-- 
2.7.3

--
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Boris Brezillon 
On Fri, 18 Mar 2016 09:51:37 -0400
Sinan Kaya  wrote:

> On 3/18/2016 7:25 AM, Robin Murphy wrote:
> > On 18/03/16 09:30, Boris Brezillon wrote:
> >> On Thu, 17 Mar 2016 23:50:20 +
> >> Russell King - ARM Linux  wrote:
> >>
> >>> On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
>  What is the correct way? I don't want to write engine->sram_dma = sram
> >>>
> >>> Well, what the driver _is_ wanting to do is to go from a CPU physical
> >>> address to a device DMA address.  phys_to_dma() looks like the correct
> >>> thing there to me, but I guess that's just an offset and doesn't take
> >>> account of any IOMMU that may be in the way.
> >>>
> >>> If you have an IOMMU, then the whole phys_to_dma() thing is a total
> >>> failure as it only does a linear translation, and there are no
> >>> interfaces in the kernel to take account of an IOMMU in the way.  So,
> >>> it needs something designed for the job, implemented and discussed by
> >>> the normal methods of proposing a new cross-arch interface for drivers
> >>> to use.
> >>>
> >>> What I'm certain of, though, is that the change proposed in this patch
> >>> will break current users of this driver: virt_to_page() on an address
> >>> returned by ioremap() is completely undefined, and will result in
> >>> either a kernel oops, or if not poking at memory which isn't a struct
> >>> page, ultimately resulting in something that isn't SRAM being pointed
> >>> to by "engine->sram_dma".
> >>>
> >>
> >> Or we could just do
> >>
> >> engine->sram_dma = res->start;
> >>
> >> which is pretty much what the SRAM/genalloc code is doing already.
> > 
> > As Russell points out this is yet another type of "set up a DMA master to 
> > access something other than kernel RAM" - there's already discussion in 
> > progress over how to handle this for dmaengine slaves[1], so gathering more 
> > use-cases might help distil exactly what the design of 
> > not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else 
> > needs to be.
> > 
> > Robin.
> > 
> > [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.html
> > 
> 
> Thanks for the link. 
> 
> dma_map_resource looks like to be the correct way of doing things. Just from
> the purist point of view, a driver is not supposed to know the physical 
> address
> of a DMA address. That kills the intent of using DMA API. When programming 
> descriptors,
> the DMA addresses should be programmed not physical addresses so that the 
> same 
> driver can be used in a system with IOMMU. The IOMMU DMA ops will remap the 
> DMA 
> address to a bus address that is not physical address. All of this operation 
> needs
> to be isolated from the device driver.
> 
> 
> I don't know the architecture or the driver enough to write this. This is not 
> ideally
> right but I can do this if Boris you are OK with this. 
> 
>  engine->sram_dma = res->start;

I don't know.

How about waiting for the 'dma_{map,unmap}_resource' discussion to
settle down before removing phy_to_dma()/dma_to_phys() APIs (as
suggested by Robin and Russell)?


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: gcm - Fix rfc4543 decryption crash

2016-03-19 Thread Greg KH 
On Fri, Mar 18, 2016 at 10:42:40PM +0800, Herbert Xu wrote:
> This bug has already bee fixed upstream since 4.2.  However, it
> was fixed during the AEAD conversion so no fix was backported to
> the older kernels.

What was the commit id of that fix?

> 
> When we do an RFC 4543 decryption, we will end up writing the
> ICV beyond the end of the dst buffer.  This should lead to a
> crash but for some reason it was never noticed.
> 
> This patch fixes it by only writing back the ICV for encryption.
> 
> Fixes: d733ac90f9fe ("crypto: gcm - fix rfc4543 to handle async...")
> Reported-by: Patrick Meyer 
> Signed-off-by: Herbert Xu 

What stable kernel(s) do you want this in?

thanks,

greg k-h
--
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 09/10] crypto: scatterwalk - export scatterwalk_pagedone

2016-03-19 Thread Tudor Ambarus 
Used in caam driver. Export the symbol since the caam driver
can be built as a module.

Signed-off-by: Tudor Ambarus 
---
 crypto/scatterwalk.c | 5 +++--
 include/crypto/scatterwalk.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index bc3222d..03d34f9 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -47,8 +47,8 @@ void *scatterwalk_map(struct scatter_walk *walk)
 }
 EXPORT_SYMBOL_GPL(scatterwalk_map);
 
-static void scatterwalk_pagedone(struct scatter_walk *walk, int out,
-unsigned int more)
+void scatterwalk_pagedone(struct scatter_walk *walk, int out,
+ unsigned int more)
 {
if (out) {
struct page *page;
@@ -69,6 +69,7 @@ static void scatterwalk_pagedone(struct scatter_walk *walk, 
int out,
scatterwalk_start(walk, sg_next(walk->sg));
}
 }
+EXPORT_SYMBOL_GPL(scatterwalk_pagedone);
 
 void scatterwalk_done(struct scatter_walk *walk, int out, int more)
 {
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 8b799c5..6535a20 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -89,6 +89,8 @@ void scatterwalk_copychunks(void *buf, struct scatter_walk 
*walk,
 void scatterwalk_sg_copychunks(struct scatter_walk *dest,
   struct scatter_walk *src, size_t nbytes);
 void *scatterwalk_map(struct scatter_walk *walk);
+void scatterwalk_pagedone(struct scatter_walk *walk, int out,
+ unsigned int more);
 void scatterwalk_done(struct scatter_walk *walk, int out, int more);
 
 void scatterwalk_map_and_copy(void *buf, struct scatterlist *sg,
-- 
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Russell King - ARM Linux 
On Thu, Mar 17, 2016 at 06:02:15PM -0400, Sinan Kaya wrote:
> Getting ready to remove dma_to_phys API. Drivers should not be
> using this API for DMA operations. Instead, they should go
> through the dma_map or dma_alloc APIs.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  drivers/crypto/marvell/cesa.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index c0656e7..52ddfa4 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -350,8 +350,8 @@ static int mv_cesa_get_sram(struct platform_device *pdev, 
> int idx)
>   if (IS_ERR(engine->sram))
>   return PTR_ERR(engine->sram);
>  
> - engine->sram_dma = phys_to_dma(cesa->dev,
> -(phys_addr_t)res->start);
> + engine->sram_dma = dma_map_single(cesa->dev, engine->sram,
> +   DMA_TO_DEVICE);

Documentation/DMA-API.txt

dma_addr_t
dma_map_single(struct device *dev, void *cpu_addr, size_t size,
  enum dma_data_direction direction)

Notes:  Not all memory regions in a machine can be mapped by this API.
Further, contiguous kernel virtual space may not be contiguous as
physical memory.  Since this API does not provide any scatter/gather
capability, it will fail if the user tries to map a non-physically
contiguous piece of memory.  For this reason, memory to be mapped by
this API should be obtained from sources which guarantee it to be
physically contiguous (like kmalloc).

Specifically, ioremapped memory will *not* work as you expect with
dma_map_single().

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: cleaning and refactoring in rsa.c

2016-03-19 Thread Herbert Xu 
On Fri, Mar 18, 2016 at 08:39:51PM +, maitesin wrote:
> * Removed several unused initializations of variables.
> * Inlined couple of functions.
> * rsa_check_key_length: changed to use only the switch statement.
> * rsa_setkey: refactored the implementation to be closer to the other
> functions in the file.
> 
> Signed-off-by: Oscar Forner Martinez 

Nack.  I don't think this patch improves the code at all.
-- 
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Boris Brezillon 
On Thu, 17 Mar 2016 23:50:20 +
Russell King - ARM Linux  wrote:

> On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
> > What is the correct way? I don't want to write engine->sram_dma = sram
> 
> Well, what the driver _is_ wanting to do is to go from a CPU physical
> address to a device DMA address.  phys_to_dma() looks like the correct
> thing there to me, but I guess that's just an offset and doesn't take
> account of any IOMMU that may be in the way.
> 
> If you have an IOMMU, then the whole phys_to_dma() thing is a total
> failure as it only does a linear translation, and there are no
> interfaces in the kernel to take account of an IOMMU in the way.  So,
> it needs something designed for the job, implemented and discussed by
> the normal methods of proposing a new cross-arch interface for drivers
> to use.
> 
> What I'm certain of, though, is that the change proposed in this patch
> will break current users of this driver: virt_to_page() on an address
> returned by ioremap() is completely undefined, and will result in
> either a kernel oops, or if not poking at memory which isn't a struct
> page, ultimately resulting in something that isn't SRAM being pointed
> to by "engine->sram_dma".
> 

Or we could just do

engine->sram_dma = res->start;

which is pretty much what the SRAM/genalloc code is doing already.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Sinan Kaya 
On 3/18/2016 10:20 AM, Boris Brezillon wrote:
> On Fri, 18 Mar 2016 09:51:37 -0400
> Sinan Kaya  wrote:
> 
>> On 3/18/2016 7:25 AM, Robin Murphy wrote:
>>> On 18/03/16 09:30, Boris Brezillon wrote:
 On Thu, 17 Mar 2016 23:50:20 +
 Russell King - ARM Linux  wrote:

> On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
>> What is the correct way? I don't want to write engine->sram_dma = sram
>
> Well, what the driver _is_ wanting to do is to go from a CPU physical
> address to a device DMA address.  phys_to_dma() looks like the correct
> thing there to me, but I guess that's just an offset and doesn't take
> account of any IOMMU that may be in the way.
>
> If you have an IOMMU, then the whole phys_to_dma() thing is a total
> failure as it only does a linear translation, and there are no
> interfaces in the kernel to take account of an IOMMU in the way.  So,
> it needs something designed for the job, implemented and discussed by
> the normal methods of proposing a new cross-arch interface for drivers
> to use.
>
> What I'm certain of, though, is that the change proposed in this patch
> will break current users of this driver: virt_to_page() on an address
> returned by ioremap() is completely undefined, and will result in
> either a kernel oops, or if not poking at memory which isn't a struct
> page, ultimately resulting in something that isn't SRAM being pointed
> to by "engine->sram_dma".
>

 Or we could just do

 engine->sram_dma = res->start;

 which is pretty much what the SRAM/genalloc code is doing already.
>>>
>>> As Russell points out this is yet another type of "set up a DMA master to 
>>> access something other than kernel RAM" - there's already discussion in 
>>> progress over how to handle this for dmaengine slaves[1], so gathering more 
>>> use-cases might help distil exactly what the design of 
>>> not-strictly-DMA-but-so-closely-coupled-it-can't-really-live-anywhere-else 
>>> needs to be.
>>>
>>> Robin.
>>>
>>> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/414422.html
>>>
>>
>> Thanks for the link. 
>>
>> dma_map_resource looks like to be the correct way of doing things. Just from
>> the purist point of view, a driver is not supposed to know the physical 
>> address
>> of a DMA address. That kills the intent of using DMA API. When programming 
>> descriptors,
>> the DMA addresses should be programmed not physical addresses so that the 
>> same 
>> driver can be used in a system with IOMMU. The IOMMU DMA ops will remap the 
>> DMA 
>> address to a bus address that is not physical address. All of this operation 
>> needs
>> to be isolated from the device driver.
>>
>>
>> I don't know the architecture or the driver enough to write this. This is 
>> not ideally
>> right but I can do this if Boris you are OK with this. 
>>
>>  engine->sram_dma = res->start;
> 
> I don't know.
> 
> How about waiting for the 'dma_{map,unmap}_resource' discussion to
> settle down before removing phy_to_dma()/dma_to_phys() APIs (as
> suggested by Robin and Russell)?
> 
> 

Sure, that's fine for me.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project
--
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/2] crypto: marvell/cesa - initialize hash states

2016-03-19 Thread Boris Brezillon 
->export() might be called before we have done an update operation,
and in this case the ->state field is left uninitialized.
Put the correct default value when initializing the request.

Signed-off-by: Boris Brezillon 
---
 drivers/crypto/marvell/hash.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index f07c1fa..7ca2e0f 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -810,9 +810,14 @@ static int mv_cesa_ahash_import(struct ahash_request *req, 
const void *hash,
 
 static int mv_cesa_md5_init(struct ahash_request *req)
 {
+   struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
struct mv_cesa_op_ctx tmpl = { };
 
mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
+   creq->state[0] = MD5_H0;
+   creq->state[1] = MD5_H1;
+   creq->state[2] = MD5_H2;
+   creq->state[3] = MD5_H3;
 
mv_cesa_ahash_init(req, , true);
 
@@ -873,9 +878,15 @@ struct ahash_alg mv_md5_alg = {
 
 static int mv_cesa_sha1_init(struct ahash_request *req)
 {
+   struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
struct mv_cesa_op_ctx tmpl = { };
 
mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_SHA1);
+   creq->state[0] = SHA1_H0;
+   creq->state[1] = SHA1_H1;
+   creq->state[2] = SHA1_H2;
+   creq->state[3] = SHA1_H3;
+   creq->state[4] = SHA1_H4;
 
mv_cesa_ahash_init(req, , false);
 
@@ -936,9 +947,18 @@ struct ahash_alg mv_sha1_alg = {
 
 static int mv_cesa_sha256_init(struct ahash_request *req)
 {
+   struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
struct mv_cesa_op_ctx tmpl = { };
 
mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_SHA256);
+   creq->state[0] = SHA256_H0;
+   creq->state[1] = SHA256_H1;
+   creq->state[2] = SHA256_H2;
+   creq->state[3] = SHA256_H3;
+   creq->state[4] = SHA256_H4;
+   creq->state[5] = SHA256_H5;
+   creq->state[6] = SHA256_H6;
+   creq->state[7] = SHA256_H7;
 
mv_cesa_ahash_init(req, , false);
 
-- 
2.5.0

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