* [PATCH v2 1/2] crypto: cbc - Propagate NEED_FALLBACK bit
From: Marcelo Henrique Cerri @ 2017-02-27 12:38 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, linux-crypto, linux-kernel,
Marcelo Henrique Cerri
In-Reply-To: <1488199106-16061-1-git-send-email-marcelo.cerri@canonical.com>
When requesting a fallback algorithm, we should propagate the
NEED_FALLBACK bit when search for the underlying algorithm.
This will prevents drivers from allocating unnecessary fallbacks that
are never called. For instance, currently the vmx-crypto driver will use
the following chain of calls when calling the fallback implementation:
p8_aes_cbc -> cbc(p8_aes) -> aes-generic
However p8_aes will always delegate its calls to aes-generic. With this
patch, p8_aes_cbc will be able to use cbc(aes-generic) directly as its
fallback. The same applies to aes_s390.
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
---
crypto/cbc.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/crypto/cbc.c b/crypto/cbc.c
index bc160a3..b761b1f 100644
--- a/crypto/cbc.c
+++ b/crypto/cbc.c
@@ -10,6 +10,7 @@
*
*/
+#include <crypto/algapi.h>
#include <crypto/cbc.h>
#include <crypto/internal/skcipher.h>
#include <linux/err.h>
@@ -108,8 +109,10 @@ static void crypto_cbc_free(struct skcipher_instance *inst)
static int crypto_cbc_create(struct crypto_template *tmpl, struct rtattr **tb)
{
struct skcipher_instance *inst;
+ struct crypto_attr_type *algt;
struct crypto_spawn *spawn;
struct crypto_alg *alg;
+ u32 mask;
int err;
err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_SKCIPHER);
@@ -120,8 +123,16 @@ static int crypto_cbc_create(struct crypto_template *tmpl, struct rtattr **tb)
if (!inst)
return -ENOMEM;
- alg = crypto_get_attr_alg(tb, CRYPTO_ALG_TYPE_CIPHER,
- CRYPTO_ALG_TYPE_MASK);
+ algt = crypto_get_attr_type(tb);
+ err = PTR_ERR(algt);
+ if (IS_ERR(algt))
+ goto err_free_inst;
+
+ mask = CRYPTO_ALG_TYPE_MASK |
+ crypto_requires_off(algt->type, algt->mask,
+ CRYPTO_ALG_NEED_FALLBACK);
+
+ alg = crypto_get_attr_alg(tb, CRYPTO_ALG_TYPE_CIPHER, mask);
err = PTR_ERR(alg);
if (IS_ERR(alg))
goto err_free_inst;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] crypto: ctr - Propagate NEED_FALLBACK bit
From: Marcelo Henrique Cerri @ 2017-02-27 12:38 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, linux-crypto, linux-kernel,
Marcelo Henrique Cerri
In-Reply-To: <1488199106-16061-1-git-send-email-marcelo.cerri@canonical.com>
When requesting a fallback algorithm, we should propagate the
NEED_FALLBACK bit when search for the underlying algorithm.
This will prevents drivers from allocating unnecessary fallbacks that
are never called. For instance, currently the vmx-crypto driver will use
the following chain of calls when calling the fallback implementation:
p8_aes_ctr -> ctr(p8_aes) -> aes-generic
However p8_aes will always delegate its calls to aes-generic. With this
patch, p8_aes_ctr will be able to use ctr(aes-generic) directly as its
fallback. The same applies to aes_s390.
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
---
crypto/ctr.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/crypto/ctr.c b/crypto/ctr.c
index a4f4a89..477d922 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -181,15 +181,24 @@ static void crypto_ctr_exit_tfm(struct crypto_tfm *tfm)
static struct crypto_instance *crypto_ctr_alloc(struct rtattr **tb)
{
struct crypto_instance *inst;
+ struct crypto_attr_type *algt;
struct crypto_alg *alg;
+ u32 mask;
int err;
err = crypto_check_attr_type(tb, CRYPTO_ALG_TYPE_BLKCIPHER);
if (err)
return ERR_PTR(err);
- alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
- CRYPTO_ALG_TYPE_MASK);
+ algt = crypto_get_attr_type(tb);
+ if (IS_ERR(algt))
+ return ERR_CAST(algt);
+
+ mask = CRYPTO_ALG_TYPE_MASK |
+ crypto_requires_off(algt->type, algt->mask,
+ CRYPTO_ALG_NEED_FALLBACK);
+
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, mask);
if (IS_ERR(alg))
return ERR_CAST(alg);
@@ -350,6 +359,8 @@ static int crypto_rfc3686_create(struct crypto_template *tmpl,
struct skcipher_alg *alg;
struct crypto_skcipher_spawn *spawn;
const char *cipher_name;
+ u32 mask;
+
int err;
algt = crypto_get_attr_type(tb);
@@ -367,12 +378,14 @@ static int crypto_rfc3686_create(struct crypto_template *tmpl,
if (!inst)
return -ENOMEM;
+ mask = crypto_requires_sync(algt->type, algt->mask) |
+ crypto_requires_off(algt->type, algt->mask,
+ CRYPTO_ALG_NEED_FALLBACK);
+
spawn = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher(spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(spawn, cipher_name, 0, mask);
if (err)
goto err_free_inst;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
From: Neil Armstrong @ 2017-02-27 13:28 UTC (permalink / raw)
To: Heiner Kallweit, Jerome Brunet, Kevin Hilman, Herbert Xu,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette
Cc: linux-clk, devicetree
In-Reply-To: <4e2d12e5-f75b-3ac6-a3f7-18e8a8b7283b@gmail.com>
On 02/21/2017 10:55 PM, Heiner Kallweit wrote:
> Expose clock CLKID_RNG0 which is needed for the HW random number generator.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - added clk and DT maintainers
> - split exposing the clock and using it in DT into two patches
> - comment out clock definition in drivers/clk/meson/gxbb.h
> - silently move CLKID_SPI to the right place
> v3:
> - no changes
> ---
> drivers/clk/meson/gxbb.h | 2 +-
> include/dt-bindings/clock/gxbb-clkc.h | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
Hi Heiner,
This looks all good to me, but you should always send a cover letter for each revisions
of the patchset.
Using "git send-email" along the "--cover-letter" of "get format-patch" feature would
also help send them in a row with a up-to-date cover letter.
For the third patch, it may be good to also add the same to the GXL dtsi, no ?
Anyway :
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v5 4/4] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver
From: Rob Herring @ 2017-02-27 14:47 UTC (permalink / raw)
To: Anup Patel
Cc: Mark Rutland, devicetree, Herbert Xu, Scott Branden, Vinod Koul,
Ray Jui, Jassi Brar, linux-kernel, linux-raid, Jon Mason,
bcm-kernel-feedback-list, linux-crypto, Rob Rice, dmaengine,
Dan Williams, David S . Miller, linux-arm-kernel
In-Reply-To: <1487227695-965-5-git-send-email-anup.patel@broadcom.com>
On Thu, Feb 16, 2017 at 12:18:15PM +0530, Anup Patel wrote:
> This patch adds the DT bindings document for newly added Broadcom
> SBA RAID driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> ---
> .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] crypto: ccm - move cbcmac input off the stack
From: Ard Biesheuvel @ 2017-02-27 15:30 UTC (permalink / raw)
To: linux-crypto, herbert; +Cc: johannes, Ard Biesheuvel
Commit f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver")
refactored the CCM driver to allow separate implementations of the
underlying MAC to be provided by a platform. However, in doing so, it
moved some data from the linear region to the stack, which violates the
SG constraints when the stack is virtually mapped.
So move idata/odata back to the request ctx struct, of which we can
reasonably expect that it has been allocated using kmalloc() et al.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/ccm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 442848807a52..1ce37ae0ce56 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -45,6 +45,7 @@ struct crypto_rfc4309_req_ctx {
struct crypto_ccm_req_priv_ctx {
u8 odata[16];
+ u8 idata[16];
u8 auth_tag[16];
u32 flags;
struct scatterlist src[3];
@@ -183,8 +184,8 @@ static int crypto_ccm_auth(struct aead_request *req, struct scatterlist *plain,
AHASH_REQUEST_ON_STACK(ahreq, ctx->mac);
unsigned int assoclen = req->assoclen;
struct scatterlist sg[3];
- u8 odata[16];
- u8 idata[16];
+ u8 *odata = pctx->odata;
+ u8 *idata = pctx->idata;
int ilen, err;
/* format control data for input */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] crypto: ccm - move cbcmac input off the stack
From: Johannes Berg @ 2017-02-27 16:04 UTC (permalink / raw)
To: Ard Biesheuvel, linux-crypto, herbert
In-Reply-To: <1488209456-7653-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, 2017-02-27 at 15:30 +0000, Ard Biesheuvel wrote:
> Commit f15f05b0a5de ("crypto: ccm - switch to separate cbcmac
> driver")
> refactored the CCM driver to allow separate implementations of the
> underlying MAC to be provided by a platform. However, in doing so, it
> moved some data from the linear region to the stack, which violates
> the
> SG constraints when the stack is virtually mapped.
>
> So move idata/odata back to the request ctx struct, of which we can
> reasonably expect that it has been allocated using kmalloc() et al.
>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac
> driver")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Johannes Berg <johannes@sipsolutions.net>
Thanks for the quick fix!
johannes
^ permalink raw reply
* [PATCH] crypto: ccp - Reference the correct structure member
From: Gary R Hook @ 2017-02-27 17:10 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
Fix a build break by referencing the proper structure member
name when invoking functions. Remove unneeded akcipher
structure.
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/Makefile | 1 -
drivers/crypto/ccp/ccp-crypto-main.c | 8 --------
drivers/crypto/ccp/ccp-ops.c | 10 +++++-----
3 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 563594a..60919a3 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -12,7 +12,6 @@ ccp-crypto-objs := ccp-crypto-main.o \
ccp-crypto-aes.o \
ccp-crypto-aes-cmac.o \
ccp-crypto-aes-xts.o \
- ccp-crypto-rsa.o \
ccp-crypto-aes-galois.o \
ccp-crypto-des3.o \
ccp-crypto-sha.o
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c b/drivers/crypto/ccp/ccp-crypto-main.c
index 228210c..8dccbdd 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -40,7 +40,6 @@
/* List heads for the supported algorithms */
static LIST_HEAD(hash_algs);
static LIST_HEAD(cipher_algs);
-static LIST_HEAD(akcipher_algs);
static LIST_HEAD(aead_algs);
/* For any tfm, requests for that tfm must be returned on the order
@@ -366,7 +365,6 @@ static void ccp_unregister_algs(void)
{
struct ccp_crypto_ahash_alg *ahash_alg, *ahash_tmp;
struct ccp_crypto_ablkcipher_alg *ablk_alg, *ablk_tmp;
- struct ccp_crypto_akcipher_alg *ak_alg, *ak_tmp;
struct ccp_crypto_aead *aead_alg, *aead_tmp;
list_for_each_entry_safe(ahash_alg, ahash_tmp, &hash_algs, entry) {
@@ -381,12 +379,6 @@ static void ccp_unregister_algs(void)
kfree(ablk_alg);
}
- list_for_each_entry_safe(ak_alg, ak_tmp, &akcipher_algs, entry) {
- crypto_unregister_akcipher(&ak_alg->alg);
- list_del(&ak_alg->entry);
- kfree(ak_alg);
- }
-
list_for_each_entry_safe(aead_alg, aead_tmp, &aead_algs, entry) {
crypto_unregister_aead(&aead_alg->alg);
list_del(&aead_alg->entry);
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index 6e2aa2c..7ae7f14 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -709,7 +709,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue *cmd_q,
while (aad.sg_wa.bytes_left) {
ccp_prepare_data(&aad, NULL, &op, AES_BLOCK_SIZE, true);
- ret = cmd_q->ccp->vdata->ccp_act->aes(&op);
+ ret = cmd_q->ccp->vdata->perform->aes(&op);
if (ret) {
cmd->engine_error = cmd_q->cmd_error;
goto e_aad;
@@ -758,7 +758,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue *cmd_q,
}
}
- ret = cmd_q->ccp->vdata->ccp_act->aes(&op);
+ ret = cmd_q->ccp->vdata->perform->aes(&op);
if (ret) {
cmd->engine_error = cmd_q->cmd_error;
goto e_dst;
@@ -807,7 +807,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue *cmd_q,
op.dst.u.dma.length = AES_BLOCK_SIZE;
op.eom = 1;
op.u.aes.size = 0;
- ret = cmd_q->ccp->vdata->ccp_act->aes(&op);
+ ret = cmd_q->ccp->vdata->perform->aes(&op);
if (ret)
goto e_dst;
@@ -1197,7 +1197,7 @@ static int ccp_run_des3_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd)
int ret;
/* Error checks */
- if (!cmd_q->ccp->vdata->ccp_act->des3)
+ if (!cmd_q->ccp->vdata->perform->des3)
return -EINVAL;
if (des3->key_len != DES3_EDE_KEY_SIZE)
@@ -1335,7 +1335,7 @@ static int ccp_run_des3_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd)
op.soc = 0;
}
- ret = cmd_q->ccp->vdata->ccp_act->des3(&op);
+ ret = cmd_q->ccp->vdata->perform->des3(&op);
if (ret) {
cmd->engine_error = cmd_q->cmd_error;
goto e_dst;
^ permalink raw reply related
* Re: [PATCH 0/3] Support new function in the newer CCP
From: Gary R Hook @ 2017-02-27 17:41 UTC (permalink / raw)
To: Gary R Hook, linux-crypto@vger.kernel.org
Cc: Lendacky, Thomas, herbert@gondor.apana.org.au,
davem@davemloft.net
In-Reply-To: <20170215214954.26536.76736.stgit@taos>
On 02/15/2017 03:55 PM, Gary R Hook wrote:
> The following series implements new function in a version 5
> coprocessor. New features are:
> - Support for SHA-2 384-bit and 512-bit hashing
> - Support for AES GCM encryption
> - Support for 3DES encryption
Please ignore. This patchset introduces build breaks. Will send a V2
shortly.
>
> ---
>
> Gary R Hook (3):
> crypto: ccp - Add SHA-2 384-/512-/bit support
> crypto: ccp - Add support for AES GCM on v5 CCPs
> crypto: ccp - Add 3DES function on v5 CCPs
>
>
> drivers/crypto/ccp/Makefile | 3
> drivers/crypto/ccp/ccp-crypto-aes-galois.c | 257 ++++++++++++++
> drivers/crypto/ccp/ccp-crypto-des3.c | 254 ++++++++++++++
> drivers/crypto/ccp/ccp-crypto-main.c | 30 ++
> drivers/crypto/ccp/ccp-crypto-sha.c | 22 +
> drivers/crypto/ccp/ccp-crypto.h | 44 ++
> drivers/crypto/ccp/ccp-dev-v3.c | 1
> drivers/crypto/ccp/ccp-dev-v5.c | 54 +++
> drivers/crypto/ccp/ccp-dev.h | 14 +
> drivers/crypto/ccp/ccp-ops.c | 522
> ++++++++++++++++++++++++++++
> include/linux/ccp.h | 68 ++++
> 11 files changed, 1263 insertions(+), 6 deletions(-)
> create mode 100644 drivers/crypto/ccp/ccp-crypto-aes-galois.c
> create mode 100644 drivers/crypto/ccp/ccp-crypto-des3.c
>
> --
> I'm pretty sure donuts would help.
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Reference the correct structure member
From: Gary R Hook @ 2017-02-27 17:40 UTC (permalink / raw)
To: Gary R Hook, linux-crypto@vger.kernel.org
Cc: Lendacky, Thomas, herbert@gondor.apana.org.au,
davem@davemloft.net
In-Reply-To: <20170227171045.28039.10586.stgit@taos>
On 02/27/2017 11:10 AM, Gary R Hook wrote:
> Fix a build break by referencing the proper structure member
> name when invoking functions. Remove unneeded akcipher
> structure.
Please ignore. I was mistakenly under the impression that the referenced
patchset had been accepted.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.com>
> ---
> drivers/crypto/ccp/Makefile | 1 -
> drivers/crypto/ccp/ccp-crypto-main.c | 8 --------
> drivers/crypto/ccp/ccp-ops.c | 10 +++++-----
> 3 files changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
> index 563594a..60919a3 100644
> --- a/drivers/crypto/ccp/Makefile
> +++ b/drivers/crypto/ccp/Makefile
> @@ -12,7 +12,6 @@ ccp-crypto-objs := ccp-crypto-main.o \
> ccp-crypto-aes.o \
> ccp-crypto-aes-cmac.o \
> ccp-crypto-aes-xts.o \
> - ccp-crypto-rsa.o \
> ccp-crypto-aes-galois.o \
> ccp-crypto-des3.o \
> ccp-crypto-sha.o
> diff --git a/drivers/crypto/ccp/ccp-crypto-main.c
> b/drivers/crypto/ccp/ccp-crypto-main.c
> index 228210c..8dccbdd 100644
> --- a/drivers/crypto/ccp/ccp-crypto-main.c
> +++ b/drivers/crypto/ccp/ccp-crypto-main.c
> @@ -40,7 +40,6 @@
> /* List heads for the supported algorithms */
> static LIST_HEAD(hash_algs);
> static LIST_HEAD(cipher_algs);
> -static LIST_HEAD(akcipher_algs);
> static LIST_HEAD(aead_algs);
>
> /* For any tfm, requests for that tfm must be returned on the order
> @@ -366,7 +365,6 @@ static void ccp_unregister_algs(void)
> {
> struct ccp_crypto_ahash_alg *ahash_alg, *ahash_tmp;
> struct ccp_crypto_ablkcipher_alg *ablk_alg, *ablk_tmp;
> - struct ccp_crypto_akcipher_alg *ak_alg, *ak_tmp;
> struct ccp_crypto_aead *aead_alg, *aead_tmp;
>
> list_for_each_entry_safe(ahash_alg, ahash_tmp, &hash_algs, entry) {
> @@ -381,12 +379,6 @@ static void ccp_unregister_algs(void)
> kfree(ablk_alg);
> }
>
> - list_for_each_entry_safe(ak_alg, ak_tmp, &akcipher_algs, entry) {
> - crypto_unregister_akcipher(&ak_alg->alg);
> - list_del(&ak_alg->entry);
> - kfree(ak_alg);
> - }
> -
> list_for_each_entry_safe(aead_alg, aead_tmp, &aead_algs, entry) {
> crypto_unregister_aead(&aead_alg->alg);
> list_del(&aead_alg->entry);
> diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
> index 6e2aa2c..7ae7f14 100644
> --- a/drivers/crypto/ccp/ccp-ops.c
> +++ b/drivers/crypto/ccp/ccp-ops.c
> @@ -709,7 +709,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue
> *cmd_q,
> while (aad.sg_wa.bytes_left) {
> ccp_prepare_data(&aad, NULL, &op,
> AES_BLOCK_SIZE, true);
>
> - ret = cmd_q->ccp->vdata->ccp_act->aes(&op);
> + ret = cmd_q->ccp->vdata->perform->aes(&op);
> if (ret) {
> cmd->engine_error = cmd_q->cmd_error;
> goto e_aad;
> @@ -758,7 +758,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue
> *cmd_q,
> }
> }
>
> - ret = cmd_q->ccp->vdata->ccp_act->aes(&op);
> + ret = cmd_q->ccp->vdata->perform->aes(&op);
> if (ret) {
> cmd->engine_error = cmd_q->cmd_error;
> goto e_dst;
> @@ -807,7 +807,7 @@ static int ccp_run_aes_gcm_cmd(struct ccp_cmd_queue
> *cmd_q,
> op.dst.u.dma.length = AES_BLOCK_SIZE;
> op.eom = 1;
> op.u.aes.size = 0;
> - ret = cmd_q->ccp->vdata->ccp_act->aes(&op);
> + ret = cmd_q->ccp->vdata->perform->aes(&op);
> if (ret)
> goto e_dst;
>
> @@ -1197,7 +1197,7 @@ static int ccp_run_des3_cmd(struct ccp_cmd_queue
> *cmd_q, struct ccp_cmd *cmd)
> int ret;
>
> /* Error checks */
> - if (!cmd_q->ccp->vdata->ccp_act->des3)
> + if (!cmd_q->ccp->vdata->perform->des3)
> return -EINVAL;
>
> if (des3->key_len != DES3_EDE_KEY_SIZE)
> @@ -1335,7 +1335,7 @@ static int ccp_run_des3_cmd(struct ccp_cmd_queue
> *cmd_q, struct ccp_cmd *cmd)
> op.soc = 0;
> }
>
> - ret = cmd_q->ccp->vdata->ccp_act->des3(&op);
> + ret = cmd_q->ccp->vdata->perform->des3(&op);
> if (ret) {
> cmd->engine_error = cmd_q->cmd_error;
> goto e_dst;
>
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node
From: Rob Herring @ 2017-02-27 22:16 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette,
linux-clk, devicetree
In-Reply-To: <8bf052e3-de8f-dbdf-be76-369a7bb1ed15@gmail.com>
On Tue, Feb 21, 2017 at 09:18:16PM +0100, Heiner Kallweit wrote:
> Add clock CLKID_RNG0 to HW randon number generator node and
> extend the DT binding documentation accordingly.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - splitted first version of patch into two
> - add DT binding documentation
> - mention that clock is optional
> - replace spaces with tabs in DT binding example
> ---
> Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt | 8 ++++++--
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +++++
> 3 files changed, 12 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM64: dts: meson-gx: add clock to DT binding documentation for hwrng
From: Rob Herring @ 2017-02-27 22:34 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette,
linux-clk, devicetree
In-Reply-To: <86db7397-8355-0d07-5180-c78d6cd06c84@gmail.com>
On Wed, Feb 22, 2017 at 07:59:08AM +0100, Heiner Kallweit wrote:
> Add clock to DT binding documentation.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - splitted first version of patch into two
> - add DT binding documentation
> - mention that clock is optional
> - replace spaces with tabs in DT binding example
> v3:
> - splitted DT extension and binding documentation update into two patches
> ---
> Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Now the subject should really be: "dt-bindings: rng: ..."
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] crypto: ccm - move cbcmac input off the stack
From: Herbert Xu @ 2017-02-28 9:33 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, johannes
In-Reply-To: <1488209456-7653-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Feb 27, 2017 at 03:30:56PM +0000, Ard Biesheuvel wrote:
> Commit f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver")
> refactored the CCM driver to allow separate implementations of the
> underlying MAC to be provided by a platform. However, in doing so, it
> moved some data from the linear region to the stack, which violates the
> SG constraints when the stack is virtually mapped.
>
> So move idata/odata back to the request ctx struct, of which we can
> reasonably expect that it has been allocated using kmalloc() et al.
>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Fixes: f15f05b0a5de ("crypto: ccm - switch to separate cbcmac driver")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/2] crypto: arm/crc32 - fix build error with outdated binutils
From: Ard Biesheuvel @ 2017-02-28 14:36 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, arnd; +Cc: herbert, jonathanh, Ard Biesheuvel
Annotate a vmov instruction with an explicit element size of 32 bits.
This is inferred by recent toolchains, but apparently, older versions
need some help figuring this out.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/crc32-ce-core.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/crypto/crc32-ce-core.S b/arch/arm/crypto/crc32-ce-core.S
index e63d400dc5c1..5cbd4a6fedad 100644
--- a/arch/arm/crypto/crc32-ce-core.S
+++ b/arch/arm/crypto/crc32-ce-core.S
@@ -135,7 +135,7 @@ ENTRY(crc32c_pmull_le)
vld1.8 {q3-q4}, [BUF, :128]!
vmov.i8 qzr, #0
vmov.i8 qCONSTANT, #0
- vmov dCONSTANTl[0], CRC
+ vmov.32 dCONSTANTl[0], CRC
veor.8 d2, d2, dCONSTANTl
sub LEN, LEN, #0x40
cmp LEN, #0x40
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] crypto: arm - add build time test for CRC instruction support
From: Ard Biesheuvel @ 2017-02-28 14:36 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, arnd; +Cc: herbert, jonathanh, Ard Biesheuvel
In-Reply-To: <1488292617-27317-1-git-send-email-ard.biesheuvel@linaro.org>
The accelerated CRC32 module for ARM may use either the scalar CRC32
instructions, the NEON 64x64 to 128 bit polynomial multiplication
(vmull.p64) instruction, or both, depending on what the current CPU
supports.
However, this also requires support in binutils, and as it turns out,
versions of binutils exist that support the vmull.p64 instruction but
not the crc32 instructions.
So refactor the Makefile logic so that this module only gets built if
binutils has support for both.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/Makefile | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 1822c4697278..f2215fbeed13 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -15,7 +15,17 @@ ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_GHASH_ARM_CE) += ghash-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_CRCT10DIF_ARM_CE) += crct10dif-arm-ce.o
-ce-obj-$(CONFIG_CRYPTO_CRC32_ARM_CE) += crc32-arm-ce.o
+crc-obj-$(CONFIG_CRYPTO_CRC32_ARM_CE) += crc32-arm-ce.o
+
+ifneq ($(crc-obj-y)$(crc-obj-m),)
+ifeq ($(call as-instr,.arch armv8-a\n.arch_extension crc,y,n),y)
+ce-obj-y += $(crc-obj-y)
+ce-obj-m += $(crc-obj-m)
+else
+$(warning These CRC Extensions modules need binutils 2.23 or higher)
+$(warning $(crc-obj-y) $(crc-obj-m))
+endif
+endif
ifneq ($(ce-obj-y)$(ce-obj-m),)
ifeq ($(call as-instr,.fpu crypto-neon-fp-armv8,y,n),y)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] crypto: arm - add build time test for CRC instruction support
From: Jon Hunter @ 2017-02-28 15:54 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel, linux-crypto, arnd; +Cc: herbert
In-Reply-To: <1488292617-27317-2-git-send-email-ard.biesheuvel@linaro.org>
On 28/02/17 14:36, Ard Biesheuvel wrote:
> The accelerated CRC32 module for ARM may use either the scalar CRC32
> instructions, the NEON 64x64 to 128 bit polynomial multiplication
> (vmull.p64) instruction, or both, depending on what the current CPU
> supports.
>
> However, this also requires support in binutils, and as it turns out,
> versions of binutils exist that support the vmull.p64 instruction but
> not the crc32 instructions.
>
> So refactor the Makefile logic so that this module only gets built if
> binutils has support for both.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Thanks!
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Problem with RSA test from testmgr
From: Corentin Labbe @ 2017-02-28 15:59 UTC (permalink / raw)
To: herbert, linux-crypto; +Cc: linux-kernel
hello
I work on the sun8i-ce crypto accelerator and I have some problem with the RSA part.
The RSA register fail at the first RSA test (encrypt 512bit) with this output:
[ 8480.146843] alg: akcipher: encrypt test failed. Invalid output
[ 8480.146871] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
[ 8480.146897] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
[ 8480.146921] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
[ 8480.146946] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
[ 8480.146995] alg: akcipher: test 1 failed for rsa-sun8i-ce, err=-22
But with the same parameters (msg, n, e) openssl give me exactly this output.
So what I miss for made it work ?
In which format testmgr expect the output data ?
Thanks
Regards
Corentin Labbe
^ permalink raw reply
* Re: Problem with RSA test from testmgr
From: Stephan Müller @ 2017-02-28 16:08 UTC (permalink / raw)
To: Corentin Labbe; +Cc: herbert, linux-crypto, linux-kernel
In-Reply-To: <20170228155953.GA1732@Red>
Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe:
Hi Corentin,
> hello
>
> I work on the sun8i-ce crypto accelerator and I have some problem with the
> RSA part.
>
> The RSA register fail at the first RSA test (encrypt 512bit) with this
> output: [ 8480.146843] alg: akcipher: encrypt test failed. Invalid output
> [ 8480.146871] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> [ 8480.146897] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> [ 8480.146921] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> [ 8480.146946] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> [ 8480.146995] alg: akcipher: test 1 failed for rsa-sun8i-ce, err=-22
>
> But with the same parameters (msg, n, e) openssl give me exactly this
> output.
>
> So what I miss for made it work ?
> In which format testmgr expect the output data ?
The output should be simply the binary string from the modular exponentiation
operation.
What I am wondering is: the output logged above is not found in the expected
values of testmgr.h. Which input data or test vectors do you use?
Ciao
Stephan
^ permalink raw reply
* Re: Problem with RSA test from testmgr
From: Corentin Labbe @ 2017-02-28 16:45 UTC (permalink / raw)
To: Stephan Müller; +Cc: herbert, linux-crypto, linux-kernel
In-Reply-To: <1836837.jAzr4JNxJu@tauon.atsec.com>
On Tue, Feb 28, 2017 at 05:08:35PM +0100, Stephan Müller wrote:
> Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe:
>
> Hi Corentin,
>
> > hello
> >
> > I work on the sun8i-ce crypto accelerator and I have some problem with the
> > RSA part.
> >
> > The RSA register fail at the first RSA test (encrypt 512bit) with this
> > output: [ 8480.146843] alg: akcipher: encrypt test failed. Invalid output
> > [ 8480.146871] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> > [ 8480.146897] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> > [ 8480.146921] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> > [ 8480.146946] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> > [ 8480.146995] alg: akcipher: test 1 failed for rsa-sun8i-ce, err=-22
> >
> > But with the same parameters (msg, n, e) openssl give me exactly this
> > output.
> >
> > So what I miss for made it work ?
> > In which format testmgr expect the output data ?
>
> The output should be simply the binary string from the modular exponentiation
> operation.
>
> What I am wondering is: the output logged above is not found in the expected
> values of testmgr.h. Which input data or test vectors do you use?
>
> Ciao
> Stephan
I use the first test from rsa_tv_template in crypto/testmgr.h
The test fail on the encrypt operation.
I have put below the openssl program that give me the same output than my hardware accelerator with the same parameters.
Regards
#include <stdio.h>
#include <string.h>
#include <openssl/crypto.h>
#include <openssl/err.h>
#include <openssl/bn.h>
#include <openssl/rsa.h>
static const unsigned char n[] =
"\x00\xAA\x36\xAB\xCE\x88\xAC\xFD\xFF\x55\x52\x3C\x7F\xC4\x52\x3F"
"\x90\xEF\xA0\x0D\xF3\x77\x4A\x25\x9F\x2E\x62\xB4\xC5\xD9\x9C\xB5"
"\xAD\xB3\x00\xA0\x28\x5E\x53\x01\x93\x0E\x0C\x70\xFB\x68\x76\x93"
"\x9C\xE6\x16\xCE\x62\x4A\x11\xE0\x08\x6D\x34\x1E\xBC\xAC\xA0\xA1"
"\xF5";
static const unsigned char e[] = "\x11";
int main(int argc, char *argv[])
{
static unsigned char ptext_ex[] = "\x54\x85\x9b\x34\x2c\x49\xea\x2a";
RSA *key;
int num, i;
int plen = sizeof(ptext_ex) - 1;
unsigned char *ctext = malloc(256);
unsigned char *ptext = malloc(256);
unsigned char *ptextp = malloc(256);
CRYPTO_malloc_debug_init();
CRYPTO_dbg_set_options(V_CRYPTO_MDEBUG_ALL);
CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
memset(ptextp, 0, 256);
memcpy(ptextp, ptext_ex, plen);
key = RSA_new();
key->n = BN_bin2bn(n, sizeof(n)-1, key->n);
key->e = BN_bin2bn(e, sizeof(e)-1, key->e);
num = RSA_public_encrypt(RSA_size(key), ptextp, ctext, key, RSA_NO_PADDING);
printf("Result %d plen=%d\n", num, plen);
for (i = 0; i < num; i++)
printf("%02x ", ctext[i]);
printf("\n");
return 0;
}
^ permalink raw reply
* Re: [PATCH v4 0/3] Add Broadcom SPU Crypto Driver
From: Florian Fainelli @ 2017-02-28 20:14 UTC (permalink / raw)
To: Jon Mason, Herbert Xu, Florian Fainelli
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Rice, Will Deacon, open list, Rob Herring,
BCM Kernel Feedback, linux-crypto, Catalin Marinas,
David S. Miller, linux-arm-kernel
In-Reply-To: <CAC3K-4orafSfvi-1E5+sS_c7_2nbU3tzk-QMaJg555q40a-GGg@mail.gmail.com>
On 02/13/2017 07:11 AM, Jon Mason wrote:
> On Sat, Feb 11, 2017 at 5:54 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Fri, Feb 03, 2017 at 12:55:31PM -0500, Rob Rice wrote:
>>> Changes in v4:
>>> - Added Rob Herring's Acked-by to patch 1/3 for bindings doc
>>> - In response to Herbert's comment, in ahash_export() and
>>> ahash_import(), only copy the hash state, not state params
>>> related to cipher or aead algos.
>>> - Noticed that hmac_offset in iproc_reqctx_s and spu_hash_params
>>> wasn't really used. So removed.
>>
>> Patches 1-2 applied. Thanks.
>
> Thanks Herbert!
>
> Florian, could you please include patch #3 in your DT branch?
Applied, thanks!
--
Florian
^ permalink raw reply
* KASAN errors after 21c8e72037fb ("crypto: testmgr - use calculated count for number of test vectors")
From: Laura Abbott @ 2017-02-28 20:17 UTC (permalink / raw)
To: Ard Biesheuvel, Herbert Xu; +Cc: linux-crypto, Linux Kernel Mailing List
Hi,
While attempting to debug something else, I saw KASAN errors
from the crypto test with ccm:
[ 28.231615] ==================================================================
[ 28.232007] BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0
[ 28.232007] Read of size 16 by task cryptomgr_test/1107
[ 28.232007] Address belongs to variable 0xffffffff8212fca0
[ 28.232007] CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
[ 28.232007] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
[ 28.232007] Call Trace:
[ 28.232007] dump_stack+0x63/0x8a
[ 28.232007] kasan_report.part.1+0x4a7/0x4e0
[ 28.232007] ? __test_aead+0x9d9/0x2200
[ 28.232007] ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
[ 28.232007] kasan_report+0x20/0x30
[ 28.232007] check_memory_region+0x13c/0x1a0
[ 28.232007] memcpy+0x23/0x50
[ 28.232007] __test_aead+0x9d9/0x2200
[ 28.232007] ? kasan_unpoison_shadow+0x35/0x50
[ 28.232007] ? alg_test_akcipher+0xf0/0xf0
[ 28.232007] ? crypto_skcipher_init_tfm+0x2e3/0x310
[ 28.232007] ? crypto_spawn_tfm2+0x37/0x60
[ 28.232007] ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
[ 28.232007] ? crypto_aead_init_tfm+0x7b/0x90
[ 28.232007] ? crypto_alloc_tfm+0xc4/0x190
[ 28.232007] test_aead+0x28/0xc0
[ 28.232007] alg_test_aead+0x54/0xd0
[ 28.232007] alg_test+0x1eb/0x3d0
[ 28.232007] ? alg_find_test+0x90/0x90
[ 28.232007] ? __sched_text_start+0x8/0x8
[ 28.232007] ? __wake_up_common+0x70/0xb0
[ 28.232007] cryptomgr_test+0x4d/0x60
[ 28.232007] kthread+0x173/0x1c0
[ 28.232007] ? crypto_acomp_scomp_free_ctx+0x60/0x60
[ 28.232007] ? kthread_create_on_node+0xa0/0xa0
[ 28.232007] ret_from_fork+0x2c/0x40
[ 28.232007] Memory state around the buggy address:
[ 28.232007] ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
[ 28.232007] ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
[ 28.232007] >ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
[ 28.232007] ^
[ 28.232007] ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
[ 28.232007] ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa
[ 28.232007] ==================================================================
This seems to be caused by 21c8e72037fb ("crypto: testmgr -
use calculated count for number of test vectors") but I think
it's because it now exposes this test vector which always causes the failure.
{
.key = "\x7c\xc8\x18\x3b\x8d\x99\xe0\x7c"
"\x45\x41\xb8\xbd\x5c\xa7\xc2\x32"
"\x8a\xb8\x02\x59\xa4\xfe\xa9\x2c"
"\x09\x75\x9a\x9b\x3c\x9b\x27\x39",
.klen = 32,
.iv = "\x03\xf9\xd9\x4e\x63\xb5\x3d\x9d"
"\x43\xf6\x1e\x50",
.assoc = "\x57\xf5\x6b\x8b\x57\x5c\x3d\x3b"
"\x13\x02\x01\x0c\x83\x4c\x96\x35"
"\x8e\xd6\x39\xcf\x7d\x14\x9b\x94"
"\xb0\x39\x36\xe6\x8f\x57\xe0\x13",
.alen = 32,
.input = "\x3b\x6c\x29\x36\xb6\xef\x07\xa6"
"\x83\x72\x07\x4f\xcf\xfa\x66\x89"
"\x5f\xca\xb1\xba\xd5\x8f\x2c\x27"
"\x30\xdb\x75\x09\x93\xd4\x65\xe4",
.ilen = 32,
.result = "\xb0\x88\x5a\x33\xaa\xe5\xc7\x1d"
"\x85\x23\xc7\xc6\x2f\xf4\x1e\x3d"
"\xcc\x63\x44\x25\x07\x78\x4f\x9e"
"\x96\xb8\x88\xeb\xbc\x48\x1f\x06"
"\x39\xaf\x39\xac\xd8\x4a\x80\x39"
"\x7b\x72\x8a\xf7",
.rlen = 44,
},
If I pad iv with extra NULL bytes the KASAN error goes away.
Thoughts?
Thanks,
Laura
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi
From: Florian Fainelli @ 2017-02-28 20:31 UTC (permalink / raw)
To: Steve Lin, herbert, robh+dt, linux, ray.jui, scott.branden,
jon.mason, f.fainelli, mark.rutland
Cc: devicetree, rob.rice, linux-kernel, bcm-kernel-feedback-list,
linux-crypto, linux-arm-kernel
In-Reply-To: <1487798543-34229-1-git-send-email-steven.lin1@broadcom.com>
On 02/22/2017 01:22 PM, Steve Lin wrote:
> Adds crypto hardware (SPU) to Northstar Plus device tree file.
>
> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
Applied, thanks!
--
Florian
^ permalink raw reply
* Re: KASAN errors after 21c8e72037fb ("crypto: testmgr - use calculated count for number of test vectors")
From: Ard Biesheuvel @ 2017-02-28 20:37 UTC (permalink / raw)
To: Laura Abbott
Cc: Herbert Xu, linux-crypto@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <d4b417e1-f34b-f706-8806-4dd3814d1f1f@redhat.com>
On 28 February 2017 at 20:17, Laura Abbott <labbott@redhat.com> wrote:
> Hi,
>
> While attempting to debug something else, I saw KASAN errors
> from the crypto test with ccm:
>
> [ 28.231615] ==================================================================
> [ 28.232007] BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0
> [ 28.232007] Read of size 16 by task cryptomgr_test/1107
> [ 28.232007] Address belongs to variable 0xffffffff8212fca0
> [ 28.232007] CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
> [ 28.232007] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
> [ 28.232007] Call Trace:
> [ 28.232007] dump_stack+0x63/0x8a
> [ 28.232007] kasan_report.part.1+0x4a7/0x4e0
> [ 28.232007] ? __test_aead+0x9d9/0x2200
> [ 28.232007] ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
> [ 28.232007] kasan_report+0x20/0x30
> [ 28.232007] check_memory_region+0x13c/0x1a0
> [ 28.232007] memcpy+0x23/0x50
> [ 28.232007] __test_aead+0x9d9/0x2200
> [ 28.232007] ? kasan_unpoison_shadow+0x35/0x50
> [ 28.232007] ? alg_test_akcipher+0xf0/0xf0
> [ 28.232007] ? crypto_skcipher_init_tfm+0x2e3/0x310
> [ 28.232007] ? crypto_spawn_tfm2+0x37/0x60
> [ 28.232007] ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
> [ 28.232007] ? crypto_aead_init_tfm+0x7b/0x90
> [ 28.232007] ? crypto_alloc_tfm+0xc4/0x190
> [ 28.232007] test_aead+0x28/0xc0
> [ 28.232007] alg_test_aead+0x54/0xd0
> [ 28.232007] alg_test+0x1eb/0x3d0
> [ 28.232007] ? alg_find_test+0x90/0x90
> [ 28.232007] ? __sched_text_start+0x8/0x8
> [ 28.232007] ? __wake_up_common+0x70/0xb0
> [ 28.232007] cryptomgr_test+0x4d/0x60
> [ 28.232007] kthread+0x173/0x1c0
> [ 28.232007] ? crypto_acomp_scomp_free_ctx+0x60/0x60
> [ 28.232007] ? kthread_create_on_node+0xa0/0xa0
> [ 28.232007] ret_from_fork+0x2c/0x40
> [ 28.232007] Memory state around the buggy address:
> [ 28.232007] ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
> [ 28.232007] ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
> [ 28.232007] >ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
> [ 28.232007] ^
> [ 28.232007] ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
> [ 28.232007] ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa
> [ 28.232007] ==================================================================
>
> This seems to be caused by 21c8e72037fb ("crypto: testmgr -
> use calculated count for number of test vectors") but I think
> it's because it now exposes this test vector which always causes the failure.
>
> {
> .key = "\x7c\xc8\x18\x3b\x8d\x99\xe0\x7c"
> "\x45\x41\xb8\xbd\x5c\xa7\xc2\x32"
> "\x8a\xb8\x02\x59\xa4\xfe\xa9\x2c"
> "\x09\x75\x9a\x9b\x3c\x9b\x27\x39",
> .klen = 32,
> .iv = "\x03\xf9\xd9\x4e\x63\xb5\x3d\x9d"
> "\x43\xf6\x1e\x50",
> .assoc = "\x57\xf5\x6b\x8b\x57\x5c\x3d\x3b"
> "\x13\x02\x01\x0c\x83\x4c\x96\x35"
> "\x8e\xd6\x39\xcf\x7d\x14\x9b\x94"
> "\xb0\x39\x36\xe6\x8f\x57\xe0\x13",
> .alen = 32,
> .input = "\x3b\x6c\x29\x36\xb6\xef\x07\xa6"
> "\x83\x72\x07\x4f\xcf\xfa\x66\x89"
> "\x5f\xca\xb1\xba\xd5\x8f\x2c\x27"
> "\x30\xdb\x75\x09\x93\xd4\x65\xe4",
> .ilen = 32,
> .result = "\xb0\x88\x5a\x33\xaa\xe5\xc7\x1d"
> "\x85\x23\xc7\xc6\x2f\xf4\x1e\x3d"
> "\xcc\x63\x44\x25\x07\x78\x4f\x9e"
> "\x96\xb8\x88\xeb\xbc\x48\x1f\x06"
> "\x39\xaf\x39\xac\xd8\x4a\x80\x39"
> "\x7b\x72\x8a\xf7",
> .rlen = 44,
> },
>
>
> If I pad iv with extra NULL bytes the KASAN error goes away.
>
> Thoughts?
>
CCM IVs are 16 bytes, but due to the way they are constructed
internally, the final couple of bytes of input IV are dont-cares.
Apparently, we do read all 16 bytes, which triggers the KASAN errors.
So adding any kind of padding bytes to pad to length 16 should fix the
issue, and so your proposed fix is correct.
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
^ permalink raw reply
* Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
From: Milan Broz @ 2017-02-28 21:05 UTC (permalink / raw)
To: Binoy Jayan
Cc: Rajendra, Herbert Xu, Oded, Mike Snitzer,
Linux kernel mailing list, Ondrej Mosnacek, linux-raid,
Gilad Ben-Yossef, dm-devel, Mark Brown, Arnd Bergmann,
linux-crypto, Shaohua Li, David S. Miller, Alasdair Kergon, Ofir
In-Reply-To: <CAHv-k_8rgArzV2uQ64h1ZTNRpssX1jMf=RwuPoBmsjQ0FhCsWA@mail.gmail.com>
On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>
> I was wondering if this is near to be ready for submission (apart from
> the testmgr.c
> changes) or I need to make some changes to make it similar to the IPSec offload?
I just tried this and except it registers the IV for every new device again, it works...
(After a while you have many duplicate entries in /proc/crypto.)
But I would like to see some summary why such a big patch is needed in the first place.
(During an internal discussions seems that people are already lost in mails and
patches here, so Ondra promised me to send some summary mail soon here.)
IIRC the first initial problem was dmcrypt performance on some embedded
crypto processors that are not able to cope with small crypto requests effectively.
Do you have some real performance numbers that proves that such a patch is adequate?
I would really like to see the performance issue fixed but I am really not sure
this approach works for everyone. It would be better to avoid repeating this exercise later.
IIRC Ondra's "bulk" mode, despite rejected, shows that there is a potential
to speedup things even for crypt drivers that do not support own IV generators.
I like the patch is now contained inside dmcrypt, but it still exposes IVs that
are designed just for old, insecure, compatibility-only containers.
I really do not think every compatible crap must be accessible through crypto API.
(I wrote the dmcrypt lrw and tcw compatibility IVs and I would never do that this way
if I know it is accessible outside of dmcrypt internals...)
Even the ESSIV is something that was born to fix predictive IVs (CBC watermarking
attacks) for disk encryption only, no reason to expose it outside of disk encryption.
Milan
^ permalink raw reply
* [PATCH] crypto: Pad aes_ccm_enc_tv_template vector
From: Laura Abbott @ 2017-02-28 22:07 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: Laura Abbott, linux-crypto, linux-kernel, Ard Biesheuvel
Running with KASAN and crypto tests currently gives
BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0
Read of size 16 by task cryptomgr_test/1107
Address belongs to variable 0xffffffff8212fca0
CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
Call Trace:
dump_stack+0x63/0x8a
kasan_report.part.1+0x4a7/0x4e0
? __test_aead+0x9d9/0x2200
? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
kasan_report+0x20/0x30
check_memory_region+0x13c/0x1a0
memcpy+0x23/0x50
__test_aead+0x9d9/0x2200
? kasan_unpoison_shadow+0x35/0x50
? alg_test_akcipher+0xf0/0xf0
? crypto_skcipher_init_tfm+0x2e3/0x310
? crypto_spawn_tfm2+0x37/0x60
? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
? crypto_aead_init_tfm+0x7b/0x90
? crypto_alloc_tfm+0xc4/0x190
test_aead+0x28/0xc0
alg_test_aead+0x54/0xd0
alg_test+0x1eb/0x3d0
? alg_find_test+0x90/0x90
? __sched_text_start+0x8/0x8
? __wake_up_common+0x70/0xb0
cryptomgr_test+0x4d/0x60
kthread+0x173/0x1c0
? crypto_acomp_scomp_free_ctx+0x60/0x60
? kthread_create_on_node+0xa0/0xa0
ret_from_fork+0x2c/0x40
Memory state around the buggy address:
ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
>ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
^
ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa
This always happens on the same IV which is less than 16 bytes.
Per Ard,
"CCM IVs are 16 bytes, but due to the way they are constructed
internally, the final couple of bytes of input IV are dont-cares.
Apparently, we do read all 16 bytes, which triggers the KASAN errors."
Fix this by padding the IV with null bytes to be at least 16 bytes.
Fixes: 0bc5a6c5c79a ("crypto: testmgr - Disable rfc4309 test and convert
test vectors")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
crypto/testmgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 006ecc4..03f4731 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -22691,7 +22691,7 @@ static struct aead_testvec aes_ccm_enc_tv_template[] = {
"\x09\x75\x9a\x9b\x3c\x9b\x27\x39",
.klen = 32,
.iv = "\x03\xf9\xd9\x4e\x63\xb5\x3d\x9d"
- "\x43\xf6\x1e\x50",
+ "\x43\xf6\x1e\x50\0\0\0\0",
.assoc = "\x57\xf5\x6b\x8b\x57\x5c\x3d\x3b"
"\x13\x02\x01\x0c\x83\x4c\x96\x35"
"\x8e\xd6\x39\xcf\x7d\x14\x9b\x94"
--
2.7.4
^ permalink raw reply related
* Re: Problem with RSA test from testmgr
From: Stephan Müller @ 2017-02-28 22:35 UTC (permalink / raw)
To: Corentin Labbe; +Cc: herbert, linux-crypto, linux-kernel
In-Reply-To: <20170228164553.GA2155@Red>
Am Dienstag, 28. Februar 2017, 17:45:53 CET schrieb Corentin Labbe:
Hi Corentin,
> On Tue, Feb 28, 2017 at 05:08:35PM +0100, Stephan Müller wrote:
> > Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe:
> >
> > Hi Corentin,
> >
> > > hello
> > >
> > > I work on the sun8i-ce crypto accelerator and I have some problem with
> > > the
> > > RSA part.
> > >
> > > The RSA register fail at the first RSA test (encrypt 512bit) with this
> > > output: [ 8480.146843] alg: akcipher: encrypt test failed. Invalid
> > > output
> > > [ 8480.146871] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> > > [ 8480.146897] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> > > [ 8480.146921] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> > > [ 8480.146946] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> > > [ 8480.146995] alg: akcipher: test 1 failed for rsa-sun8i-ce, err=-22
> > >
> > > But with the same parameters (msg, n, e) openssl give me exactly this
> > > output.
> > >
> > > So what I miss for made it work ?
> > > In which format testmgr expect the output data ?
> >
> > The output should be simply the binary string from the modular
> > exponentiation operation.
> >
> > What I am wondering is: the output logged above is not found in the
> > expected values of testmgr.h. Which input data or test vectors do you
> > use?
> >
> > Ciao
> > Stephan
>
> I use the first test from rsa_tv_template in crypto/testmgr.h
> The test fail on the encrypt operation.
>
> I have put below the openssl program that give me the same output than my
> hardware accelerator with the same parameters.
I would think the issue is that the OpenSSL BIGNUM lib has some issues: when
calculating m^e mod n, m has to be equal to the key size. The kernel's MPI
code handles the case where m is smaller than the key size.
Note, in your code below, ptext is the 8 bytes from ptext_ex plus trailing
zeroes whereas the kernel uses just the 8 bytes.
It seems that your implementation has the same issue.
What about the following test: change vector->m to be 64 bytes (i.e.
RSA_size(key) in size in testmgr.h and check the output of crypto/rsa.c,
openssl's output with the app below and your RSA hardware.
>
> Regards
>
>
> #include <stdio.h>
> #include <string.h>
> #include <openssl/crypto.h>
> #include <openssl/err.h>
> #include <openssl/bn.h>
> #include <openssl/rsa.h>
>
> static const unsigned char n[] =
> "\x00\xAA\x36\xAB\xCE\x88\xAC\xFD\xFF\x55\x52\x3C\x7F\xC4\x52\x3F"
> "\x90\xEF\xA0\x0D\xF3\x77\x4A\x25\x9F\x2E\x62\xB4\xC5\xD9\x9C\xB5"
> "\xAD\xB3\x00\xA0\x28\x5E\x53\x01\x93\x0E\x0C\x70\xFB\x68\x76\x93"
> "\x9C\xE6\x16\xCE\x62\x4A\x11\xE0\x08\x6D\x34\x1E\xBC\xAC\xA0\xA1"
> "\xF5";
> static const unsigned char e[] = "\x11";
>
> int main(int argc, char *argv[])
> {
> static unsigned char ptext_ex[] = "\x54\x85\x9b\x34\x2c\x49\xea\x2a";
> RSA *key;
> int num, i;
> int plen = sizeof(ptext_ex) - 1;
> unsigned char *ctext = malloc(256);
> unsigned char *ptext = malloc(256);
> unsigned char *ptextp = malloc(256);
>
> CRYPTO_malloc_debug_init();
> CRYPTO_dbg_set_options(V_CRYPTO_MDEBUG_ALL);
> CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
>
> memset(ptextp, 0, 256);
> memcpy(ptextp, ptext_ex, plen);
>
> key = RSA_new();
>
> key->n = BN_bin2bn(n, sizeof(n)-1, key->n);
> key->e = BN_bin2bn(e, sizeof(e)-1, key->e);
>
> num = RSA_public_encrypt(RSA_size(key), ptextp, ctext, key,
> RSA_NO_PADDING);
>
> printf("Result %d plen=%d\n", num, plen);
> for (i = 0; i < num; i++)
> printf("%02x ", ctext[i]);
> printf("\n");
> return 0;
> }
Ciao
Stephan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox