* [PATCH 09/11] crypto: caam: move job descriptor initialisation to ahash_edesc_alloc()
From: Russell King @ 2016-08-08 17:05 UTC (permalink / raw)
To: Fabio Estevam, Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <20160808170400.GC1041@n2100.armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/crypto/caam/caamhash.c | 84 +++++++++++++++++-------------------------
1 file changed, 34 insertions(+), 50 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 2c2c15b63059..9c3e74e4088e 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -770,7 +770,9 @@ static void ahash_done_ctx_dst(struct device *jrdev, u32 *desc, u32 err,
* and space for hardware scatter table containing sg_num entries.
*/
static struct ahash_edesc *ahash_edesc_alloc(struct caam_hash_ctx *ctx,
- int sg_num, gfp_t flags)
+ int sg_num, u32 *sh_desc,
+ dma_addr_t sh_desc_dma,
+ gfp_t flags)
{
struct ahash_edesc *edesc;
unsigned int sg_size = sg_num * sizeof(struct sec4_sg_entry);
@@ -781,6 +783,9 @@ static struct ahash_edesc *ahash_edesc_alloc(struct caam_hash_ctx *ctx,
return NULL;
}
+ init_job_desc_shared(edesc->hw_desc, sh_desc_dma, desc_len(sh_desc),
+ HDR_SHARE_DEFER | HDR_REVERSE);
+
return edesc;
}
@@ -799,12 +804,10 @@ static int ahash_update_ctx(struct ahash_request *req)
int *next_buflen = state->current_buf ? &state->buflen_0 :
&state->buflen_1, last_buflen;
int in_len = *buflen + req->nbytes, to_hash;
- u32 *sh_desc = ctx->sh_desc_update, *desc;
- dma_addr_t ptr = ctx->sh_desc_update_dma;
+ u32 *desc;
int src_nents, mapped_nents, sec4_sg_bytes, sec4_sg_src_index;
struct ahash_edesc *edesc;
int ret = 0;
- int sh_len;
last_buflen = *next_buflen;
*next_buflen = in_len & (crypto_tfm_alg_blocksize(&ahash->base) - 1);
@@ -838,7 +841,8 @@ static int ahash_update_ctx(struct ahash_request *req)
* link tables
*/
edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
- flags);
+ ctx->sh_desc_update,
+ ctx->sh_desc_update_dma, flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
@@ -872,10 +876,7 @@ static int ahash_update_ctx(struct ahash_request *req)
state->current_buf = !state->current_buf;
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER |
- HDR_REVERSE);
edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
sec4_sg_bytes,
@@ -936,25 +937,23 @@ static int ahash_final_ctx(struct ahash_request *req)
int buflen = state->current_buf ? state->buflen_1 : state->buflen_0;
int last_buflen = state->current_buf ? state->buflen_0 :
state->buflen_1;
- u32 *sh_desc = ctx->sh_desc_fin, *desc;
- dma_addr_t ptr = ctx->sh_desc_fin_dma;
+ u32 *desc;
int sec4_sg_bytes, sec4_sg_src_index;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
int ret = 0;
- int sh_len;
sec4_sg_src_index = 1 + (buflen ? 1 : 0);
sec4_sg_bytes = sec4_sg_src_index * sizeof(struct sec4_sg_entry);
/* allocate space for base edesc and hw desc commands, link tables */
- edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index, flags);
+ edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index,
+ ctx->sh_desc_fin, ctx->sh_desc_fin_dma,
+ flags);
if (!edesc)
return -ENOMEM;
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->src_nents = 0;
@@ -1018,14 +1017,12 @@ static int ahash_finup_ctx(struct ahash_request *req)
int buflen = state->current_buf ? state->buflen_1 : state->buflen_0;
int last_buflen = state->current_buf ? state->buflen_0 :
state->buflen_1;
- u32 *sh_desc = ctx->sh_desc_finup, *desc;
- dma_addr_t ptr = ctx->sh_desc_finup_dma;
+ u32 *desc;
int sec4_sg_bytes, sec4_sg_src_index;
int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
int ret = 0;
- int sh_len;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1050,15 +1047,14 @@ static int ahash_finup_ctx(struct ahash_request *req)
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
+ ctx->sh_desc_finup, ctx->sh_desc_finup_dma,
flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
}
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
@@ -1118,15 +1114,13 @@ static int ahash_digest(struct ahash_request *req)
struct device *jrdev = ctx->jrdev;
gfp_t flags = (req->base.flags & (CRYPTO_TFM_REQ_MAY_BACKLOG |
CRYPTO_TFM_REQ_MAY_SLEEP)) ? GFP_KERNEL : GFP_ATOMIC;
- u32 *sh_desc = ctx->sh_desc_digest, *desc;
- dma_addr_t ptr = ctx->sh_desc_digest_dma;
+ u32 *desc;
int digestsize = crypto_ahash_digestsize(ahash);
int src_nents, mapped_nents, sec4_sg_bytes;
dma_addr_t src_dma;
struct ahash_edesc *edesc;
int ret = 0;
u32 options;
- int sh_len;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1152,6 +1146,7 @@ static int ahash_digest(struct ahash_request *req)
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, mapped_nents > 1 ? mapped_nents : 0,
+ ctx->sh_desc_digest, ctx->sh_desc_digest_dma,
flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
@@ -1161,9 +1156,7 @@ static int ahash_digest(struct ahash_request *req)
edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->src_nents = src_nents;
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
if (src_nents > 1) {
sg_to_sec4_sg_last(req->src, mapped_nents, edesc->sec4_sg, 0);
@@ -1219,21 +1212,18 @@ static int ahash_final_no_ctx(struct ahash_request *req)
CRYPTO_TFM_REQ_MAY_SLEEP)) ? GFP_KERNEL : GFP_ATOMIC;
u8 *buf = state->current_buf ? state->buf_1 : state->buf_0;
int buflen = state->current_buf ? state->buflen_1 : state->buflen_0;
- u32 *sh_desc = ctx->sh_desc_digest, *desc;
- dma_addr_t ptr = ctx->sh_desc_digest_dma;
+ u32 *desc;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
int ret = 0;
- int sh_len;
/* allocate space for base edesc and hw desc commands, link tables */
- edesc = ahash_edesc_alloc(ctx, 0, flags);
+ edesc = ahash_edesc_alloc(ctx, 0, ctx->sh_desc_digest,
+ ctx->sh_desc_digest_dma, flags);
if (!edesc)
return -ENOMEM;
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
state->buf_dma = dma_map_single(jrdev, buf, buflen, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, state->buf_dma)) {
@@ -1288,10 +1278,8 @@ static int ahash_update_no_ctx(struct ahash_request *req)
int in_len = *buflen + req->nbytes, to_hash;
int sec4_sg_bytes, src_nents, mapped_nents;
struct ahash_edesc *edesc;
- u32 *desc, *sh_desc = ctx->sh_desc_update_first;
- dma_addr_t ptr = ctx->sh_desc_update_first_dma;
+ u32 *desc;
int ret = 0;
- int sh_len;
*next_buflen = in_len & (crypto_tfm_alg_blocksize(&ahash->base) - 1);
to_hash = in_len - *next_buflen;
@@ -1322,7 +1310,10 @@ static int ahash_update_no_ctx(struct ahash_request *req)
* allocate space for base edesc and hw desc commands,
* link tables
*/
- edesc = ahash_edesc_alloc(ctx, 1 + mapped_nents, flags);
+ edesc = ahash_edesc_alloc(ctx, 1 + mapped_nents,
+ ctx->sh_desc_update_first,
+ ctx->sh_desc_update_first_dma,
+ flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
@@ -1345,10 +1336,7 @@ static int ahash_update_no_ctx(struct ahash_request *req)
state->current_buf = !state->current_buf;
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER |
- HDR_REVERSE);
edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
sec4_sg_bytes,
@@ -1414,12 +1402,10 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
int buflen = state->current_buf ? state->buflen_1 : state->buflen_0;
int last_buflen = state->current_buf ? state->buflen_0 :
state->buflen_1;
- u32 *sh_desc = ctx->sh_desc_digest, *desc;
- dma_addr_t ptr = ctx->sh_desc_digest_dma;
+ u32 *desc;
int sec4_sg_bytes, sec4_sg_src_index, src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int sh_len;
int ret = 0;
src_nents = sg_nents_for_len(req->src, req->nbytes);
@@ -1444,15 +1430,15 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
sizeof(struct sec4_sg_entry);
/* allocate space for base edesc and hw desc commands, link tables */
- edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents, flags);
+ edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
+ ctx->sh_desc_digest, ctx->sh_desc_digest_dma,
+ flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
}
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
@@ -1513,14 +1499,12 @@ static int ahash_update_first(struct ahash_request *req)
int *next_buflen = state->current_buf ?
&state->buflen_1 : &state->buflen_0;
int to_hash;
- u32 *sh_desc = ctx->sh_desc_update_first, *desc;
- dma_addr_t ptr = ctx->sh_desc_update_first_dma;
+ u32 *desc;
int sec4_sg_bytes, src_nents, mapped_nents;
dma_addr_t src_dma;
u32 options;
struct ahash_edesc *edesc;
int ret = 0;
- int sh_len;
*next_buflen = req->nbytes & (crypto_tfm_alg_blocksize(&ahash->base) -
1);
@@ -1555,7 +1539,10 @@ static int ahash_update_first(struct ahash_request *req)
* link tables
*/
edesc = ahash_edesc_alloc(ctx, mapped_nents > 1 ?
- mapped_nents : 0, flags);
+ mapped_nents : 0,
+ ctx->sh_desc_update_first,
+ ctx->sh_desc_update_first_dma,
+ flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
@@ -1588,10 +1575,7 @@ static int ahash_update_first(struct ahash_request *req)
scatterwalk_map_and_copy(next_buf, req->src, to_hash,
*next_buflen, 0);
- sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
- init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER |
- HDR_REVERSE);
append_seq_in_ptr(desc, src_dma, to_hash, options);
--
2.1.0
^ permalink raw reply related
* [PATCH 10/11] crypto: caam: add ahash_edesc_add_src()
From: Russell King @ 2016-08-08 17:05 UTC (permalink / raw)
To: Fabio Estevam, Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <20160808170400.GC1041@n2100.armlinux.org.uk>
Add a helper to map the source scatterlist into the descriptor.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/crypto/caam/caamhash.c | 137 +++++++++++++++++------------------------
1 file changed, 57 insertions(+), 80 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 9c3e74e4088e..ea284e3909ef 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -789,6 +789,41 @@ static struct ahash_edesc *ahash_edesc_alloc(struct caam_hash_ctx *ctx,
return edesc;
}
+static int ahash_edesc_add_src(struct caam_hash_ctx *ctx,
+ struct ahash_edesc *edesc,
+ struct ahash_request *req, int nents,
+ unsigned int first_sg,
+ unsigned int first_bytes, size_t to_hash)
+{
+ dma_addr_t src_dma;
+ u32 options;
+
+ if (nents > 1 || first_sg) {
+ struct sec4_sg_entry *sg = edesc->sec4_sg;
+ unsigned int sgsize = sizeof(*sg) * (first_sg + nents);
+
+ sg_to_sec4_sg_last(req->src, nents, sg + first_sg, 0);
+
+ src_dma = dma_map_single(ctx->jrdev, sg, sgsize, DMA_TO_DEVICE);
+ if (dma_mapping_error(ctx->jrdev, src_dma)) {
+ dev_err(ctx->jrdev, "unable to map S/G table\n");
+ return -ENOMEM;
+ }
+
+ edesc->sec4_sg_bytes = sgsize;
+ edesc->sec4_sg_dma = src_dma;
+ options = LDST_SGF;
+ } else {
+ src_dma = sg_dma_address(req->src);
+ options = 0;
+ }
+
+ append_seq_in_ptr(edesc->hw_desc, src_dma, first_bytes + to_hash,
+ options);
+
+ return 0;
+}
+
/* submit update job descriptor */
static int ahash_update_ctx(struct ahash_request *req)
{
@@ -1018,7 +1053,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
int last_buflen = state->current_buf ? state->buflen_0 :
state->buflen_1;
u32 *desc;
- int sec4_sg_bytes, sec4_sg_src_index;
+ int sec4_sg_src_index;
int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
@@ -1042,8 +1077,6 @@ static int ahash_finup_ctx(struct ahash_request *req)
}
sec4_sg_src_index = 1 + (buflen ? 1 : 0);
- sec4_sg_bytes = (sec4_sg_src_index + mapped_nents) *
- sizeof(struct sec4_sg_entry);
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
@@ -1057,7 +1090,6 @@ static int ahash_finup_ctx(struct ahash_request *req)
desc = edesc->hw_desc;
edesc->src_nents = src_nents;
- edesc->sec4_sg_bytes = sec4_sg_bytes;
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_TO_DEVICE);
@@ -1068,19 +1100,11 @@ static int ahash_finup_ctx(struct ahash_request *req)
buf, state->buf_dma, buflen,
last_buflen);
- sg_to_sec4_sg_last(req->src, mapped_nents,
- edesc->sec4_sg + sec4_sg_src_index, 0);
-
- edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
- sec4_sg_bytes, DMA_TO_DEVICE);
- if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
- dev_err(jrdev, "unable to map S/G table\n");
- ret = -ENOMEM;
+ ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents,
+ sec4_sg_src_index, ctx->ctx_len + buflen,
+ req->nbytes);
+ if (ret)
goto err;
- }
-
- append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len +
- buflen + req->nbytes, LDST_SGF);
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
@@ -1116,11 +1140,9 @@ static int ahash_digest(struct ahash_request *req)
CRYPTO_TFM_REQ_MAY_SLEEP)) ? GFP_KERNEL : GFP_ATOMIC;
u32 *desc;
int digestsize = crypto_ahash_digestsize(ahash);
- int src_nents, mapped_nents, sec4_sg_bytes;
- dma_addr_t src_dma;
+ int src_nents, mapped_nents;
struct ahash_edesc *edesc;
int ret = 0;
- u32 options;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1139,11 +1161,6 @@ static int ahash_digest(struct ahash_request *req)
mapped_nents = 0;
}
- if (mapped_nents > 1)
- sec4_sg_bytes = mapped_nents * sizeof(struct sec4_sg_entry);
- else
- sec4_sg_bytes = 0;
-
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, mapped_nents > 1 ? mapped_nents : 0,
ctx->sh_desc_digest, ctx->sh_desc_digest_dma,
@@ -1153,28 +1170,17 @@ static int ahash_digest(struct ahash_request *req)
return -ENOMEM;
}
- edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->src_nents = src_nents;
- desc = edesc->hw_desc;
-
- if (src_nents > 1) {
- sg_to_sec4_sg_last(req->src, mapped_nents, edesc->sec4_sg, 0);
- edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
- sec4_sg_bytes, DMA_TO_DEVICE);
- if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
- dev_err(jrdev, "unable to map S/G table\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
- }
- src_dma = edesc->sec4_sg_dma;
- options = LDST_SGF;
- } else {
- src_dma = sg_dma_address(req->src);
- options = 0;
+ ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents, 0, 0,
+ req->nbytes);
+ if (ret) {
+ ahash_unmap(jrdev, edesc, req, digestsize);
+ kfree(edesc);
+ return ret;
}
- append_seq_in_ptr(desc, src_dma, req->nbytes, options);
+
+ desc = edesc->hw_desc;
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
@@ -1447,20 +1453,15 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
state->buf_dma, buflen,
last_buflen);
- sg_to_sec4_sg_last(req->src, mapped_nents, edesc->sec4_sg + 1, 0);
-
- edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
- sec4_sg_bytes, DMA_TO_DEVICE);
- if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
+ ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents, 1, buflen,
+ req->nbytes);
+ if (ret) {
dev_err(jrdev, "unable to map S/G table\n");
ahash_unmap(jrdev, edesc, req, digestsize);
kfree(edesc);
return -ENOMEM;
}
- append_seq_in_ptr(desc, edesc->sec4_sg_dma, buflen +
- req->nbytes, LDST_SGF);
-
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
@@ -1500,9 +1501,7 @@ static int ahash_update_first(struct ahash_request *req)
&state->buflen_1 : &state->buflen_0;
int to_hash;
u32 *desc;
- int sec4_sg_bytes, src_nents, mapped_nents;
- dma_addr_t src_dma;
- u32 options;
+ int src_nents, mapped_nents;
struct ahash_edesc *edesc;
int ret = 0;
@@ -1528,11 +1527,6 @@ static int ahash_update_first(struct ahash_request *req)
} else {
mapped_nents = 0;
}
- if (mapped_nents > 1)
- sec4_sg_bytes = mapped_nents *
- sizeof(struct sec4_sg_entry);
- else
- sec4_sg_bytes = 0;
/*
* allocate space for base edesc and hw desc commands,
@@ -1549,27 +1543,12 @@ static int ahash_update_first(struct ahash_request *req)
}
edesc->src_nents = src_nents;
- edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->dst_dma = 0;
- if (src_nents > 1) {
- sg_to_sec4_sg_last(req->src, mapped_nents,
- edesc->sec4_sg, 0);
- edesc->sec4_sg_dma = dma_map_single(jrdev,
- edesc->sec4_sg,
- sec4_sg_bytes,
- DMA_TO_DEVICE);
- if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
- dev_err(jrdev, "unable to map S/G table\n");
- ret = -ENOMEM;
- goto err;
- }
- src_dma = edesc->sec4_sg_dma;
- options = LDST_SGF;
- } else {
- src_dma = sg_dma_address(req->src);
- options = 0;
- }
+ ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents, 0, 0,
+ to_hash);
+ if (ret)
+ goto err;
if (*next_buflen)
scatterwalk_map_and_copy(next_buf, req->src, to_hash,
@@ -1577,8 +1556,6 @@ static int ahash_update_first(struct ahash_request *req)
desc = edesc->hw_desc;
- append_seq_in_ptr(desc, src_dma, to_hash, options);
-
ret = map_seq_out_ptr_ctx(desc, jrdev, state, ctx->ctx_len);
if (ret)
goto err;
--
2.1.0
^ permalink raw reply related
* [PATCH 11/11] crypto: caam: get rid of tasklet
From: Russell King @ 2016-08-08 17:05 UTC (permalink / raw)
To: Fabio Estevam, Herbert Xu; +Cc: David S. Miller, linux-crypto
In-Reply-To: <20160808170400.GC1041@n2100.armlinux.org.uk>
Threaded interrupts can perform the function of the tasklet, and much
more safely too - without races when trying to take the tasklet and
interrupt down on device removal.
With the old code, there is a window where we call tasklet_kill(). If
the interrupt handler happens to be running on a different CPU, and
subsequently calls tasklet_schedule(), the tasklet will be re-scheduled
for execution.
Switching to a hardirq/threadirq combination implementation avoids this,
and it also means generic code deals with the teardown sequencing of the
threaded and non-threaded parts.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/crypto/caam/intern.h | 1 -
drivers/crypto/caam/jr.c | 25 +++++++++----------------
2 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index e2bcacc1a921..5d4c05074a5c 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -41,7 +41,6 @@ struct caam_drv_private_jr {
struct device *dev;
int ridx;
struct caam_job_ring __iomem *rregs; /* JobR's register space */
- struct tasklet_struct irqtask;
int irq; /* One per queue */
/* Number of scatterlist crypt transforms active on the JobR */
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index a81f551ac222..320228875e9a 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -73,8 +73,6 @@ static int caam_jr_shutdown(struct device *dev)
ret = caam_reset_hw_jr(dev);
- tasklet_kill(&jrp->irqtask);
-
/* Release interrupt */
free_irq(jrp->irq, dev);
@@ -130,7 +128,7 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
/*
* Check the output ring for ready responses, kick
- * tasklet if jobs done.
+ * the threaded irq if jobs done.
*/
irqstate = rd_reg32(&jrp->rregs->jrintstatus);
if (!irqstate)
@@ -152,18 +150,13 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
/* Have valid interrupt at this point, just ACK and trigger */
wr_reg32(&jrp->rregs->jrintstatus, irqstate);
- preempt_disable();
- tasklet_schedule(&jrp->irqtask);
- preempt_enable();
-
- return IRQ_HANDLED;
+ return IRQ_WAKE_THREAD;
}
-/* Deferred service handler, run as interrupt-fired tasklet */
-static void caam_jr_dequeue(unsigned long devarg)
+static irqreturn_t caam_jr_threadirq(int irq, void *st_dev)
{
int hw_idx, sw_idx, i, head, tail;
- struct device *dev = (struct device *)devarg;
+ struct device *dev = st_dev;
struct caam_drv_private_jr *jrp = dev_get_drvdata(dev);
void (*usercall)(struct device *dev, u32 *desc, u32 status, void *arg);
u32 *userdesc, userstatus;
@@ -237,6 +230,8 @@ static void caam_jr_dequeue(unsigned long devarg)
/* reenable / unmask IRQs */
clrsetbits_32(&jrp->rregs->rconfig_lo, JRCFG_IMSK, 0);
+
+ return IRQ_HANDLED;
}
/**
@@ -394,11 +389,10 @@ static int caam_jr_init(struct device *dev)
jrp = dev_get_drvdata(dev);
- tasklet_init(&jrp->irqtask, caam_jr_dequeue, (unsigned long)dev);
-
/* Connect job ring interrupt handler. */
- error = request_irq(jrp->irq, caam_jr_interrupt, IRQF_SHARED,
- dev_name(dev), dev);
+ error = request_threaded_irq(jrp->irq, caam_jr_interrupt,
+ caam_jr_threadirq, IRQF_SHARED,
+ dev_name(dev), dev);
if (error) {
dev_err(dev, "can't connect JobR %d interrupt (%d)\n",
jrp->ridx, jrp->irq);
@@ -460,7 +454,6 @@ static int caam_jr_init(struct device *dev)
out_free_irq:
free_irq(jrp->irq, dev);
out_kill_deq:
- tasklet_kill(&jrp->irqtask);
return error;
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-08 17:29 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <1830987.VF9l4XmGxv@tauon.atsec.com>
Hi Stephan, Miaoqing Pan,
On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert, the analysis report show the
> > ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> > value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> > so that's why set entropy quality to 320/1024 = 10/32.
Ok, so the relevant commit is:
ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture
Which refers to a previous commit:
6301566e0b2d ath9k: export HW random number generator
> > Also we have explained in the commit message why can't use the HW
> > RNG framework.
>From ed14dc0af7cce:
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable to
> measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a hardware
> RNG that per default and without being able to change it at runtime injects
> data into the input_pool where the noise source cannot be audited. Note, even
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent that it
> does not cause /dev/random to unblock. The reason is that your noise source
> starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts to
> spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng
framework. Interrupt timings were never designed to be a source of entropy
either. We need to grab it where ever we can find it, especially on
embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of
sources under char/hw_random/. I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about
sound cards?
thx,
Jason.
^ permalink raw reply
* Re: AF_ALG broken?
From: Jeffrey Walton @ 2016-08-08 17:47 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-crypto
In-Reply-To: <20160808164427.GB1041@n2100.armlinux.org.uk>
> When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> caam, I get this:
>
> $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 </bin/bash
> ...
> socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> close(3) = 0
> socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL) = 4
> fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fab000
> read(0, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192) = 8192
> send(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192, MSG_MORE) = -1 ENOKEY (Required key not available)
As far as I know from testing on x86, it has never worked as expected.
I believe you have to use 'sendto' and 'recvfrom' because 'send' and
'recv' use default structures, and they configure the object
incorrectly.
Jeff
^ permalink raw reply
* Re: [PATCH 00/11] Further iMX CAAM updates
From: Fabio Estevam @ 2016-08-08 17:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Fabio Estevam, Herbert Xu, David S. Miller, linux-crypto,
horia.geanta
In-Reply-To: <20160808170400.GC1041@n2100.armlinux.org.uk>
Hi Russell,
On Mon, Aug 8, 2016 at 2:04 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> This is a re-post (with hopefully bugs fixed from December's review).
> Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe
> someone can provide some hints how to test using tcrypt please?
>
> Here are further imx-caam updates that I've had since before the
> previous merge window. Please review and (I guess) if Freescale
> folk can provide acks etc that would be nice. Thanks.
I am adding Horia on Cc, who is familiar with the caam driver.
Thanks
^ permalink raw reply
* Re: AF_ALG broken?
From: Russell King - ARM Linux @ 2016-08-08 18:11 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: linux-crypto
In-Reply-To: <CAH8yC8nFhMCfXpdrcz1bJDPfbMHRGQpkV6yOZ7gy4yRHJwXkWw@mail.gmail.com>
On Mon, Aug 08, 2016 at 01:47:33PM -0400, Jeffrey Walton wrote:
> > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> > caam, I get this:
> >
> > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 </bin/bash
> > ...
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > close(3) = 0
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > accept(3, 0, NULL) = 4
> > fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fab000
> > read(0, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192) = 8192
> > send(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192, MSG_MORE) = -1 ENOKEY (Required key not available)
>
> As far as I know from testing on x86, it has never worked as expected.
> I believe you have to use 'sendto' and 'recvfrom' because 'send' and
> 'recv' use default structures, and they configure the object
> incorrectly.
This used to work, because that's how I've tested my previous CAAM
and Marvell CESA patches. So, this is not a case of "never worked"
but is definitely a regression caused by some kernel change.
There's also people's presentations that illustrate example code:
https://events.linuxfoundation.org/sites/events/files/slides/lcj-2014-crypto-user.pdf
which can also be found at:
https://lwn.net/Articles/410833/
and that example code comes from Herbert, so one would assume that
it's tested and was working. Note that it doesn't use any send*,
but uses write().
Testing that code on 4.8-rc (and 4.7 fwiw) gives:
socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
accept(3, 0, NULL) = 4
write(4, "abc", 3) = -1 ENOKEY (Required key not available)
read(4, 0xbec50508, 20) = -1 ENOKEY (Required key not available)
IOW, the same problem - and it seems not to be a recent regression.
Since the last time I tested CESA or CAAM was back in 4.4 times,
it's got to be something between 4.4 and 4.7.
Looking at the history, my guess would be the setkey changes -
crypto: algif_skcipher - Require setkey before accept(2)
crypto: af_alg - Disallow bind/setkey/... after accept(2)
crypto: af_alg - Add nokey compatibility path
crypto: hash - Add crypto_ahash_has_setkey
crypto: algif_hash - Require setkey before accept(2)
--
Rmk's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: AF_ALG broken?
From: Stephan Mueller @ 2016-08-08 18:18 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: Herbert Xu, David S. Miller, linux-crypto
In-Reply-To: <20160808164427.GB1041@n2100.armlinux.org.uk>
Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux:
Hi Russell,
> Hi,
>
> When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> caam, I get this:
>
> $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
> </bin/bash ...
> socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> close(3) = 0
> socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL) = 4
> fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb6fab000 read(0,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192)
> = 8192 send(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192,
> MSG_MORE) = -1 ENOKEY (Required key not available)
>
> This used to work, so something in the kernel AF_ALG API has changed
> which has broken userspace. Any ideas what's up, or where to look?
This seems to be the the change added by Herbert to fix a security issue. This
caused a similar stirr in the cryptsetup user space tool.
I guess you are affected by 6de62f15b581f920ade22d758f4c338311c2f0d4
Ciao
Stephan
^ permalink raw reply
* Re: AF_ALG broken?
From: Stephan Mueller @ 2016-08-08 18:30 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: Herbert Xu, David S. Miller, linux-crypto
In-Reply-To: <5469036.jmYhrDdAzD@positron.chronox.de>
Am Montag, 8. August 2016, 20:18:32 CEST schrieb Stephan Mueller:
Hi Stephan,
> Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux:
>
> Hi Russell,
>
> > Hi,
> >
> > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> > caam, I get this:
> >
> > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
> > </bin/bash ...
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > close(3) = 0
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > accept(3, 0, NULL) = 4
> > fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > =
> > 0xb6fab000 read(0,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"...,
> > 8192)
> > = 8192 send(4,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"...,
> > 8192,
> > MSG_MORE) = -1 ENOKEY (Required key not available)
> >
> > This used to work, so something in the kernel AF_ALG API has changed
> > which has broken userspace. Any ideas what's up, or where to look?
>
> This seems to be the the change added by Herbert to fix a security issue.
> This caused a similar stirr in the cryptsetup user space tool.
>
> I guess you are affected by 6de62f15b581f920ade22d758f4c338311c2f0d4
Just to be clear: the settings on the tfmfd must be completed before an
accept(). If make an operation on the tfmfd after the accept call, you get
the ENOKEY.
This was my change to the issue:
https://github.com/smuellerDD/libkcapi/commit/
1d6c3b1b540caea784a95b1ca6e2cf38c174f585
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-08 22:04 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Ted Tso, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <20160808172930.GD4511@io.lakedaemon.net>
Hi Stephan,
On Mon, Aug 08, 2016 at 05:29:30PM +0000, Jason Cooper wrote:
> On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
...
> > If you think that this patch is a challenge because your driver starts to
> > spin, please help and offer another solution.
>
> Well, I don't buy the reasoning listed above for not using the hwrng
> framework. Interrupt timings were never designed to be a source of entropy
> either. We need to grab it where ever we can find it, especially on
> embedded systems. Documentation/hw_random.txt even says:
>
> """
> This data is NOT CHECKED by any fitness tests, and could potentially be
> bogus (if the hardware is faulty or has been tampered with).
> """
>
> I really don't think there's a problem with adding these sorts of
> sources under char/hw_random/. I think the only thing we would be
> concerned about, other than the already addressed entropy estimation,
> would be constraining the data rate.
Further research yields char/hw_random/timeriomem-rng.c
It could use an update to ->read() vice data_{present,read}(), but it's
functionally exactly what the ath9k rng is doing. :)
thx,
Jason.
^ permalink raw reply
* [PATCH v2] crypto: powerpc - CRYPT_CRC32C_VPMSUM should depend on ALTIVEC
From: Michael Ellerman @ 2016-08-08 22:46 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Anton Blanchard, Herbert Xu
The optimised crc32c implementation depends on VMX (aka. Altivec)
instructions, so the kernel must be built with Altivec support in order
for the crc32c code to build.
Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v2: No change. Send to linux-crypto.
diff --git a/crypto/Kconfig b/crypto/Kconfig
index a9377bef25e3..84d71482bf08 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -439,7 +439,7 @@ config CRYPTO_CRC32C_INTEL
config CRYPT_CRC32C_VPMSUM
tristate "CRC32c CRC algorithm (powerpc64)"
- depends on PPC64
+ depends on PPC64 && ALTIVEC
select CRYPTO_HASH
select CRC32
help
--
2.7.4
^ permalink raw reply related
* Re: AF_ALG broken?
From: Russell King - ARM Linux @ 2016-08-08 22:58 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Herbert Xu, David S. Miller, linux-crypto
In-Reply-To: <5217898.dpPNhAO3PW@tauon.atsec.com>
On Mon, Aug 08, 2016 at 08:30:32PM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 20:18:32 CEST schrieb Stephan Mueller:
>
> Hi Stephan,
>
> > Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux:
> >
> > Hi Russell,
> >
> > > Hi,
> > >
> > > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> > > caam, I get this:
> > >
> > > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
> > > </bin/bash ...
> > > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > > close(3) = 0
> > > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > > accept(3, 0, NULL) = 4
> > > fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > > =
> > > 0xb6fab000 read(0,
> > > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"...,
> > > 8192)
> > > = 8192 send(4,
> > > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"...,
> > > 8192,
> > > MSG_MORE) = -1 ENOKEY (Required key not available)
> > >
> > > This used to work, so something in the kernel AF_ALG API has changed
> > > which has broken userspace. Any ideas what's up, or where to look?
> >
> > This seems to be the the change added by Herbert to fix a security issue.
> > This caused a similar stirr in the cryptsetup user space tool.
> >
> > I guess you are affected by 6de62f15b581f920ade22d758f4c338311c2f0d4
>
> Just to be clear: the settings on the tfmfd must be completed before an
> accept(). If make an operation on the tfmfd after the accept call, you get
> the ENOKEY.
As you can see from the above strace, there's no operations on fd 3
after the accept call. The only operation on the accepted fd (fd 4)
is the send(). So, I'm not sure I follow what you're saying.
I've also checked - there's no updates for af-alg-rr, so everyone
who's using af-alg-rr must have been broken by this change - if there
_are_ any users of AF_ALG with openssl. Maybe everyone just patches
cryptodev into their kernel?
I don't know, but this seems to go completely against Linus' no
userspace regressions, which seems to be an absolute requirement of
all kernel development... Linus flames people for arguing against
that rule!
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: AF_ALG broken?
From: David Miller @ 2016-08-08 23:04 UTC (permalink / raw)
To: linux; +Cc: smueller, herbert, linux-crypto
In-Reply-To: <20160808225851.GE1041@n2100.armlinux.org.uk>
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Mon, 8 Aug 2016 23:58:51 +0100
> I don't know, but this seems to go completely against Linus' no
> userspace regressions, which seems to be an absolute requirement of
> all kernel development... Linus flames people for arguing against
> that rule!
Reading the explanation for the change given to you, it's impossible
for some hash algorithms to function properly without being given the
key first, and would crash.
Therefore the requirement is reasonable, even though it is unfortunate
that a critical piece of userspace infrastructure was coded this way.
^ permalink raw reply
* Re: AF_ALG broken?
From: Herbert Xu @ 2016-08-09 3:18 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: noloader, linux-crypto
In-Reply-To: <20160808181117.GD1041@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> Testing that code on 4.8-rc (and 4.7 fwiw) gives:
>
> socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL) = 4
> write(4, "abc", 3) = -1 ENOKEY (Required key not available)
> read(4, 0xbec50508, 20) = -1 ENOKEY (Required key not available)
>
> IOW, the same problem - and it seems not to be a recent regression.
>
> Since the last time I tested CESA or CAAM was back in 4.4 times,
> it's got to be something between 4.4 and 4.7.
>
> Looking at the history, my guess would be the setkey changes -
> crypto: algif_skcipher - Require setkey before accept(2)
> crypto: af_alg - Disallow bind/setkey/... after accept(2)
> crypto: af_alg - Add nokey compatibility path
> crypto: hash - Add crypto_ahash_has_setkey
> crypto: algif_hash - Require setkey before accept(2)
This is definitely supposed to work. Basically if the algorithm
requires a key (e.g., HMAC) then you must set it. Otherwise it
should never return ENOKEY.
Which algorithm were you testing and what does /proc/crypto say?
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
* RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Pan, Miaoqing @ 2016-08-09 6:30 UTC (permalink / raw)
To: Jason Cooper, Stephan Mueller
Cc: Ted Tso, Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160808172930.GD4511@io.lakedaemon.net>
Hi Jason, Stephan,
Agree with Jason's point, also understand Stephan's concern. The date rate can be roughly estimated by 'cat /dev/random |rngtest -c 1000', the average speed is 1111.294Kibits/s. I will sent the patch to disable ath9k RNG by default.
Thanks,
Miaoqing
-----Original Message-----
From: Jason Cooper [mailto:jason@lakedaemon.net]
Sent: Tuesday, August 09, 2016 1:30 AM
To: Stephan Mueller <smueller@chronox.de>
Cc: Pan, Miaoqing <miaoqing@qti.qualcomm.com>; Ted Tso <tytso@mit.edu>; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>; herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
Hi Stephan, Miaoqing Pan,
On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert, the analysis report
> > show the ADC with at least 10bits and up to 22 bits of min-entropy
> > for a 32 bits value, we conservatively assume the min-entropy is 10
> > bits out of 32 bits, so that's why set entropy quality to 320/1024 = 10/32.
Ok, so the relevant commit is:
ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture
Which refers to a previous commit:
6301566e0b2d ath9k: export HW random number generator
> > Also we have explained in the commit message why can't use the HW
> > RNG framework.
>From ed14dc0af7cce:
"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind it to /dev/hwrng framework directly.
"""
> Where is the description of the RNG, where is the test implementation?
> >
> > Otherwise, your patch will cause high CPU load, as continuously
> > read ADC data if entropy bits under write_wakeup_threshold.
>
> The issue is that although you may have analyzed it, others are unable
> to measure the quality of the RNG and assess the design as well as the
> implementation of the RNG. This RNG is the only implementation of a
> hardware RNG that per default and without being able to change it at
> runtime injects data into the input_pool where the noise source cannot
> be audited. Note, even other respected RNG noise sources like the
> Intel RDRAND will not feed into / dev/random per default in a way that dominates all other noise sources.
>
> I would like to be able to deactivate that noise source to the extent
> that it does not cause /dev/random to unblock. The reason is that your
> noise source starts to dominate all other noise sources.
I think the short-term problem here is the config logic:
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
default y
If you have *any* hwrngs you want to use and you have an ath9k card (HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing out.
Short term, we should just default no here.
> If you think that this patch is a challenge because your driver starts
> to spin, please help and offer another solution.
Well, I don't buy the reasoning listed above for not using the hwrng framework. Interrupt timings were never designed to be a source of entropy either. We need to grab it where ever we can find it, especially on embedded systems. Documentation/hw_random.txt even says:
"""
This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the hardware is faulty or has been tampered with).
"""
I really don't think there's a problem with adding these sorts of sources under char/hw_random/. I think the only thing we would be concerned about, other than the already addressed entropy estimation, would be constraining the data rate.
Is ath9k the only wireless card that exposes ADC registers? What about sound cards?
thx,
Jason.
^ permalink raw reply
* [PATCH 1/2] ath9k: change entropy formula for easier understanding
From: miaoqing @ 2016-08-09 7:02 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
From: Miaoqing Pan <miaoqing@codeaurora.org>
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..568b1c6 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,7 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
+#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 10) >> 5) /* quality: 10/32 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ath9k: disable RNG by default
From: miaoqing @ 2016-08-09 7:02 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing@codeaurora.org>
From: Miaoqing Pan <miaoqing@codeaurora.org>
ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index f68cb00..8f231c6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
- default y
+ default n
---help---
This option incorporates the ADC register output as a source of
randomness into Linux entropy pool (/dev/urandom and /dev/random)
--
1.9.1
^ permalink raw reply related
* Re: AF_ALG broken?
From: Russell King - ARM Linux @ 2016-08-09 7:08 UTC (permalink / raw)
To: Herbert Xu; +Cc: noloader, linux-crypto
In-Reply-To: <20160809031820.GA4142@gondor.apana.org.au>
On Tue, Aug 09, 2016 at 11:18:20AM +0800, Herbert Xu wrote:
> Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> > Testing that code on 4.8-rc (and 4.7 fwiw) gives:
> >
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > accept(3, 0, NULL) = 4
> > write(4, "abc", 3) = -1 ENOKEY (Required key not available)
> > read(4, 0xbec50508, 20) = -1 ENOKEY (Required key not available)
> >
> > IOW, the same problem - and it seems not to be a recent regression.
> >
> > Since the last time I tested CESA or CAAM was back in 4.4 times,
> > it's got to be something between 4.4 and 4.7.
> >
> > Looking at the history, my guess would be the setkey changes -
> > crypto: algif_skcipher - Require setkey before accept(2)
> > crypto: af_alg - Disallow bind/setkey/... after accept(2)
> > crypto: af_alg - Add nokey compatibility path
> > crypto: hash - Add crypto_ahash_has_setkey
> > crypto: algif_hash - Require setkey before accept(2)
>
> This is definitely supposed to work. Basically if the algorithm
> requires a key (e.g., HMAC) then you must set it. Otherwise it
> should never return ENOKEY.
>
> Which algorithm were you testing and what does /proc/crypto say?
Hi Herbert,
I thought I gave the commands and link to your example code. The
openssl case is md5, though sha* also gives the same result. Your
example code was sha1 iirc. I guess none of these would be using
HMAC - the openssl cases used to give results compatible with the
md5sum/ sha1sum etc userspace commands.
/proc/crypto:
name : md5
driver : md5-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 16
name : hmac(md5)
driver : hmac-md5-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 16
name : sha256
driver : sha256-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 32
name : hmac(sha256)
driver : hmac-sha256-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 32
name : sha224
driver : sha224-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 28
name : hmac(sha224)
driver : hmac-sha224-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 28
name : sha1
driver : sha1-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 20
name : hmac(sha1)
driver : hmac-sha1-caam
module : caamhash
priority : 3000
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 20
name : ecb(aes)
driver : ecb(aes-asm)
module : kernel
priority : 200
refcnt : 3
selftest : passed
internal : no
type : blkcipher
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 0
geniv : <default>
name : ghash
driver : ghash-generic
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 16
digestsize : 16
name : jitterentropy_rng
driver : jitterentropy_rng
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_nopr_hmac_sha256
module : kernel
priority : 207
refcnt : 2
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_nopr_hmac_sha512
module : kernel
priority : 206
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_nopr_hmac_sha384
module : kernel
priority : 205
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_nopr_hmac_sha1
module : kernel
priority : 204
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : hmac(sha256)
driver : hmac(sha256-asm)
module : kernel
priority : 150
refcnt : 2
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 32
name : stdrng
driver : drbg_pr_hmac_sha256
module : kernel
priority : 203
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_pr_hmac_sha512
module : kernel
priority : 202
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_pr_hmac_sha384
module : kernel
priority : 201
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : stdrng
driver : drbg_pr_hmac_sha1
module : kernel
priority : 200
refcnt : 1
selftest : passed
internal : no
type : rng
seedsize : 0
name : lzo
driver : lzo-generic
module : kernel
priority : 0
refcnt : 2
selftest : passed
internal : no
type : compression
name : crct10dif
driver : crct10dif-generic
module : kernel
priority : 100
refcnt : 2
selftest : passed
internal : no
type : shash
blocksize : 1
digestsize : 2
name : crc32c
driver : crc32c-generic
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 1
digestsize : 4
name : deflate
driver : deflate-generic
module : kernel
priority : 0
refcnt : 2
selftest : passed
internal : no
type : compression
name : ecb(arc4)
driver : ecb(arc4)-generic
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : blkcipher
blocksize : 1
min keysize : 1
max keysize : 256
ivsize : 0
geniv : <default>
name : arc4
driver : arc4-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : cipher
blocksize : 1
min keysize : 1
max keysize : 256
name : aes
driver : aes-generic
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
name : sha224
driver : sha224-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 28
name : sha256
driver : sha256-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 32
name : sha1
driver : sha1-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 20
name : digest_null
driver : digest_null-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 1
digestsize : 0
name : compress_null
driver : compress_null-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : compression
name : ecb(cipher_null)
driver : ecb-cipher_null
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : blkcipher
blocksize : 1
min keysize : 0
max keysize : 0
ivsize : 0
geniv : <default>
name : cipher_null
driver : cipher_null-generic
module : kernel
priority : 0
refcnt : 1
selftest : passed
internal : no
type : cipher
blocksize : 1
min keysize : 0
max keysize : 0
name : sha512
driver : sha512-arm
module : kernel
priority : 250
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 128
digestsize : 64
name : sha384
driver : sha384-arm
module : kernel
priority : 250
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 128
digestsize : 48
name : sha224
driver : sha224-asm
module : kernel
priority : 150
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 28
name : sha256
driver : sha256-asm
module : kernel
priority : 150
refcnt : 2
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 32
name : sha1
driver : sha1-asm
module : kernel
priority : 150
refcnt : 1
selftest : passed
internal : no
type : shash
blocksize : 64
digestsize : 20
name : aes
driver : aes-asm
module : kernel
priority : 200
refcnt : 2
selftest : passed
internal : no
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: AF_ALG broken?
From: Herbert Xu @ 2016-08-09 7:14 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: noloader, linux-crypto
In-Reply-To: <20160809070859.GF1041@n2100.armlinux.org.uk>
On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
>
> I thought I gave the commands and link to your example code. The
> openssl case is md5, though sha* also gives the same result. Your
> example code was sha1 iirc. I guess none of these would be using
> HMAC - the openssl cases used to give results compatible with the
> md5sum/ sha1sum etc userspace commands.
>
> /proc/crypto:
>
> name : md5
> driver : md5-caam
Right, caam is providing a setkey function for md5, which leads the
API to think that a key is required. We should fix it so that setkey
is only set for the HMAC-variant.
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
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 7:14 UTC (permalink / raw)
To: miaoqing-sgV2jX0FEOL9JmXXK+q4OQ
Cc: kvalo-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, jason-NLaQJdtUoK4Be96aLqz0jA,
pouyans-Rm6X0d1/PG5y9aJCnZT0Uw
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org:
Hi Miaoqing,
> From: Miaoqing Pan <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
As a short term solution:
Acked-by: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
But as Jason outlined, there should be nothing that prevents using this code
with the HW Random framework. This framework also has logic to limit the rate
of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
> config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: AF_ALG broken?
From: Russell King - ARM Linux @ 2016-08-09 7:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: noloader, linux-crypto
In-Reply-To: <20160809071402.GA5466@gondor.apana.org.au>
On Tue, Aug 09, 2016 at 03:14:02PM +0800, Herbert Xu wrote:
> On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
> >
> > I thought I gave the commands and link to your example code. The
> > openssl case is md5, though sha* also gives the same result. Your
> > example code was sha1 iirc. I guess none of these would be using
> > HMAC - the openssl cases used to give results compatible with the
> > md5sum/ sha1sum etc userspace commands.
> >
> > /proc/crypto:
> >
> > name : md5
> > driver : md5-caam
>
> Right, caam is providing a setkey function for md5, which leads the
> API to think that a key is required. We should fix it so that setkey
> is only set for the HMAC-variant.
Thanks, that works nicely again, and passes my tests.
8<====
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] crypto: caam - fix non-hmac hashes
Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
accept(2)"), the AF_ALG interface requires userspace to provide a key
to any algorithm that has a setkey method. However, the non-HMAC
algorithms are not keyed, so setting a key is unnecessary.
Fix this by removing the setkey method from the non-keyed hash
algorithms.
Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)")
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/crypto/caam/caamhash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index ea284e3909ef..9d7fc9ec0b7e 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1950,6 +1950,7 @@ caam_hash_alloc(struct caam_hash_template *template,
template->name);
snprintf(alg->cra_driver_name, CRYPTO_MAX_ALG_NAME, "%s",
template->driver_name);
+ t_alg->ahash_alg.setkey = NULL;
}
alg->cra_module = THIS_MODULE;
alg->cra_init = caam_hash_cra_init;
--
2.1.0
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH] crypto: caam - avoid kernel warnings on probe failure
From: Russell King @ 2016-08-09 7:30 UTC (permalink / raw)
To: Herbert Xu, Fabio Estevam, horia.geanta; +Cc: linux-crypto
While debugging setkey issues, the following warnings were found while
trying to reinsert the caam module. Fix this by avoiding the duplicated
cleanup in the probe path after caam_remove(), which has already cleaned
up the resources.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2346 at /home/rmk/git/linux-rmk/mm/vmalloc.c:1490 __vunmap+0xcc/0xf4
Trying to vfree() nonexistent vm area (f2400000)
Modules linked in: caam(+) cbc rfcomm bnep bluetooth nfsd em28xx_rc si2157 si2168 em28xx_dvb uvcvideo snd_soc_imx_sgtl5000 em28xx snd_soc_imx_spdif tveeprom snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_sgtl5000 imx_sdma imx2_wdt coda v4l2_mem2mem videobuf2_dma_contig snd_soc_fsl_ssi rc_cec snd_soc_fsl_spdif imx_pcm_dma videobuf2_vmalloc videobuf2_memops imx_thermal dw_hdmi_ahb_audio dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd [last unloaded: caam]
CPU: 0 PID: 2346 Comm: modprobe Tainted: G W 4.8.0-rc1+ #2014
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c0013bb0>] (dump_backtrace) from [<c0013d4c>] (show_stack+0x18/0x1c)
[<c0013d34>] (show_stack) from [<c0357c00>] (dump_stack+0xa4/0xdc)
[<c0357b5c>] (dump_stack) from [<c002e650>] (__warn+0xdc/0x108)
[<c002e574>] (__warn) from [<c002e734>] (warn_slowpath_fmt+0x40/0x48)
[<c002e6f8>] (warn_slowpath_fmt) from [<c0151708>] (__vunmap+0xcc/0xf4)
[<c015163c>] (__vunmap) from [<c015177c>] (vunmap+0x4c/0x54)
[<c0151730>] (vunmap) from [<c001f48c>] (__iounmap+0x2c/0x30)
[<c001f460>] (__iounmap) from [<c001f118>] (iounmap+0x1c/0x20)
[<c001f0fc>] (iounmap) from [<bf247ae4>] (caam_probe+0x3dc/0x1498 [caam])
[<bf247708>] (caam_probe [caam]) from [<c042da8c>] (platform_drv_probe+0x58/0xb8)
[<c042da34>] (platform_drv_probe) from [<c042bb4c>] (driver_probe_device+0x1fc/0x2b8)
[<c042b950>] (driver_probe_device) from [<c042bcc4>] (__driver_attach+0xbc/0xc0) r10:00000000 r8:bf24b000 r7:00000000 r6:ef215844 r5:bf2490c4 r4:ef215810
[<c042bc08>] (__driver_attach) from [<c0429f14>] (bus_for_each_dev+0x5c/0x90)
[<c0429eb8>] (bus_for_each_dev) from [<c042b358>] (driver_attach+0x24/0x28)
[<c042b334>] (driver_attach) from [<c042b058>] (bus_add_driver+0xf4/0x200)
[<c042af64>] (bus_add_driver) from [<c042cadc>] (driver_register+0x80/0xfc)
[<c042ca5c>] (driver_register) from [<c042d960>] (__platform_driver_register+0x48/0x4c)
[<c042d918>] (__platform_driver_register) from [<bf24b018>] (caam_driver_init+0x18/0x24 [caam])
[<bf24b000>] (caam_driver_init [caam]) from [<c00098ac>] (do_one_initcall+0x44/0x178)
[<c0009868>] (do_one_initcall) from [<c010e034>] (do_init_module+0x68/0x1d8)
[<c010dfcc>] (do_init_module) from [<c00c8fbc>] (load_module+0x1974/0x20b0)
[<c00c7648>] (load_module) from [<c00c98d0>] (SyS_finit_module+0x94/0xa0)
[<c00c983c>] (SyS_finit_module) from [<c000fda0>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 34e3370d88bb1786 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2346 at /home/rmk/git/linux-rmk/drivers/clk/clk.c:594 clk_core_disable+0xe4/0x26c
Modules linked in: caam(+) cbc rfcomm bnep bluetooth nfsd em28xx_rc si2157 si2168 em28xx_dvb uvcvideo snd_soc_imx_sgtl5000 em28xx snd_soc_imx_spdif tveeprom snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_sgtl5000 imx_sdma imx2_wdt coda v4l2_mem2mem videobuf2_dma_contig snd_soc_fsl_ssi rc_cec snd_soc_fsl_spdif imx_pcm_dma videobuf2_vmalloc videobuf2_memops imx_thermal dw_hdmi_ahb_audio dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd [last unloaded: caam]
CPU: 0 PID: 2346 Comm: modprobe Tainted: G W 4.8.0-rc1+ #2014
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c0013bb0>] (dump_backtrace) from [<c0013d4c>] (show_stack+0x18/0x1c)
[<c0013d34>] (show_stack) from [<c0357c00>] (dump_stack+0xa4/0xdc)
[<c0357b5c>] (dump_stack) from [<c002e650>] (__warn+0xdc/0x108)
[<c002e574>] (__warn) from [<c002e6a4>] (warn_slowpath_null+0x28/0x30)
[<c002e67c>] (warn_slowpath_null) from [<c05b113c>] (clk_core_disable+0xe4/0x26c)
[<c05b1058>] (clk_core_disable) from [<c05b2e3c>] (clk_core_disable_lock+0x20/0x2c)
[<c05b2e1c>] (clk_core_disable_lock) from [<c05b2e6c>] (clk_disable+0x24/0x28)
[<c05b2e48>] (clk_disable) from [<bf247b04>] (caam_probe+0x3fc/0x1498 [caam])
[<bf247708>] (caam_probe [caam]) from [<c042da8c>] (platform_drv_probe+0x58/0xb8)
[<c042da34>] (platform_drv_probe) from [<c042bb4c>] (driver_probe_device+0x1fc/0x2b8)
[<c042b950>] (driver_probe_device) from [<c042bcc4>] (__driver_attach+0xbc/0xc0) r10:00000000 r8:bf24b000 r7:00000000 r6:ef215844 r5:bf2490c4 r4:ef215810
[<c042bc08>] (__driver_attach) from [<c0429f14>] (bus_for_each_dev+0x5c/0x90)
[<c0429eb8>] (bus_for_each_dev) from [<c042b358>] (driver_attach+0x24/0x28)
[<c042b334>] (driver_attach) from [<c042b058>] (bus_add_driver+0xf4/0x200)
[<c042af64>] (bus_add_driver) from [<c042cadc>] (driver_register+0x80/0xfc)
[<c042ca5c>] (driver_register) from [<c042d960>] (__platform_driver_register+0x48/0x4c)
[<c042d918>] (__platform_driver_register) from [<bf24b018>] (caam_driver_init+0x18/0x24 [caam])
[<bf24b000>] (caam_driver_init [caam]) from [<c00098ac>] (do_one_initcall+0x44/0x178)
[<c0009868>] (do_one_initcall) from [<c010e034>] (do_init_module+0x68/0x1d8)
[<c010dfcc>] (do_init_module) from [<c00c8fbc>] (load_module+0x1974/0x20b0)
[<c00c7648>] (load_module) from [<c00c98d0>] (SyS_finit_module+0x94/0xa0)
[<c00c983c>] (SyS_finit_module) from [<c000fda0>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 34e3370d88bb1787 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2346 at /home/rmk/git/linux-rmk/drivers/clk/clk.c:476 clk_core_unprepare+0x204/0x388
Modules linked in: caam(+) cbc rfcomm bnep bluetooth nfsd em28xx_rc si2157 si2168 em28xx_dvb uvcvideo snd_soc_imx_sgtl5000 em28xx snd_soc_imx_spdif tveeprom snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_sgtl5000 imx_sdma imx2_wdt coda v4l2_mem2mem videobuf2_dma_contig snd_soc_fsl_ssi rc_cec snd_soc_fsl_spdif imx_pcm_dma videobuf2_vmalloc videobuf2_memops imx_thermal dw_hdmi_ahb_audio dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd [last unloaded: caam]
CPU: 0 PID: 2346 Comm: modprobe Tainted: G W 4.8.0-rc1+ #2014
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<c0013bb0>] (dump_backtrace) from [<c0013d4c>] (show_stack+0x18/0x1c)
[<c0013d34>] (show_stack) from [<c0357c00>] (dump_stack+0xa4/0xdc)
[<c0357b5c>] (dump_stack) from [<c002e650>] (__warn+0xdc/0x108)
[<c002e574>] (__warn) from [<c002e6a4>] (warn_slowpath_null+0x28/0x30)
[<c002e67c>] (warn_slowpath_null) from [<c05b0834>] (clk_core_unprepare+0x204/0x388)
[<c05b0630>] (clk_core_unprepare) from [<c05b4c0c>] (clk_unprepare+0x2c/0x34)
[<c05b4be0>] (clk_unprepare) from [<bf247b0c>] (caam_probe+0x404/0x1498 [caam])
[<bf247708>] (caam_probe [caam]) from [<c042da8c>] (platform_drv_probe+0x58/0xb8)
[<c042da34>] (platform_drv_probe) from [<c042bb4c>] (driver_probe_device+0x1fc/0x2b8)
[<c042b950>] (driver_probe_device) from [<c042bcc4>] (__driver_attach+0xbc/0xc0) r10:00000000 r8:bf24b000 r7:00000000 r6:ef215844 r5:bf2490c4 r4:ef215810
[<c042bc08>] (__driver_attach) from [<c0429f14>] (bus_for_each_dev+0x5c/0x90)
[<c0429eb8>] (bus_for_each_dev) from [<c042b358>] (driver_attach+0x24/0x28)
[<c042b334>] (driver_attach) from [<c042b058>] (bus_add_driver+0xf4/0x200)
[<c042af64>] (bus_add_driver) from [<c042cadc>] (driver_register+0x80/0xfc)
[<c042ca5c>] (driver_register) from [<c042d960>] (__platform_driver_register+0x48/0x4c)
[<c042d918>] (__platform_driver_register) from [<bf24b018>] (caam_driver_init+0x18/0x24 [caam])
[<bf24b000>] (caam_driver_init [caam]) from [<c00098ac>] (do_one_initcall+0x44/0x178)
[<c0009868>] (do_one_initcall) from [<c010e034>] (do_init_module+0x68/0x1d8)
[<c010dfcc>] (do_init_module) from [<c00c8fbc>] (load_module+0x1974/0x20b0)
[<c00c7648>] (load_module) from [<c00c98d0>] (SyS_finit_module+0x94/0xa0)
[<c00c983c>] (SyS_finit_module) from [<c000fda0>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 34e3370d88bb1788 ]---
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/crypto/caam/ctrl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112ee5204..f4c044f5bcb2 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -826,6 +826,8 @@ static int caam_probe(struct platform_device *pdev)
caam_remove:
caam_remove(pdev);
+ return ret;
+
iounmap_ctrl:
iounmap(ctrl);
disable_caam_emi_slow:
--
2.1.0
^ permalink raw reply related
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-09 7:35 UTC (permalink / raw)
To: Stephan Mueller, miaoqing@codeaurora.org
Cc: Valo, Kalle, linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <4627645.oz3l49ICL3@tauon.atsec.com>
Hi Stephan,
So your suggestion is to use HW Random framework ? Actually, which was done by the commit 6301566e0b2d ("ath9k: export HW random number generator"), but it was reverted, you can refer to https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html for more information.
--
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Tuesday, August 09, 2016 3:15 PM
To: miaoqing@codeaurora.org
Cc: Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoqing@codeaurora.org:
Hi Miaoqing,
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW RNG,
> disable it by default. But we strongly recommand to enable it if the
> system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
As a short term solution:
Acked-by: Stephan Mueller <smueller@chronox.de>
But as Jason outlined, there should be nothing that prevents using this code with the HW Random framework. This framework also has logic to limit the rate of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-09 8:07 UTC (permalink / raw)
To: Pan, Miaoqing, herbert, Matt Mackall
Cc: miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <69af156ac93a4fe6ab1844dfcc35c266@aptaiexm02f.ap.qualcomm.com>
Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing:
Hi Miaoqing, Herbert, Matt,
> Hi Stephan,
>
> So your suggestion is to use HW Random framework ? Actually, which was
> done by the commit 6301566e0b2d ("ath9k: export HW random number
> generator"), but it was reverted, you can refer to
> https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html
> for more information.
I see, it is the same RNG we talked about earlier. The issue is that the
suggested rngd per default assumes one bit of entropy with every data bit.
This is not given with this noise source. This is the basis of my reply last
time.
Herbert, Matt, should such noise sources be added to the HW random framework?
The thing is that the in-kernel HW random to input_pool link per default uses
a more conservative entropy estimate than the user space rngd. I would think
that the in-kernel link would appropriate for that rng. But the user space
rngd tool with its default behavior is not really suited here.
Thanks
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Herbert Xu @ 2016-08-09 8:58 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <4731753.YZZKimtrHM@tauon.atsec.com>
On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
>
> Herbert, Matt, should such noise sources be added to the HW random framework?
> The thing is that the in-kernel HW random to input_pool link per default uses
> a more conservative entropy estimate than the user space rngd. I would think
> that the in-kernel link would appropriate for that rng. But the user space
> rngd tool with its default behavior is not really suited here.
Yes hwrng would be the best fit, with a quality of zero to be safe.
Contrary to the quoted thread, there is no need to whiten the output
/dev/hw_random. It was always meant to go through some intermediate
processing such as rngd before it is used.
Cheers,
--
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
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