Re: [PATCH] crypto: testmgr - don't DMA map IV from stack in test_skcipher()

2017-03-08 Thread Herbert Xu
On Wed, Mar 08, 2017 at 01:04:14PM +, Horia Geantă wrote:
>
> Since changing the API and converting the users looks pretty lengthy,
> would it be acceptable to fix tcrypt for now?
> Indeed, I've missed updating test_skcipher_speed, I can add this in v2.

Might as well leave it there because at least it reminds us to
fix the problem.  With the API as it is any new kernel user could
potentially provide us with an IV off the stack.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[PATCH v1 3/8] crypto: mediatek - make mtk_sha_xmit() more generic

2017-03-08 Thread Ryder Lee
This is a transitional patch. It merges mtk_sha_xmit() and mtk_sha_xmit2()
to make transmit function more generic.
In addition, res->buf and cryp->tmp_dma in mtk_sha_xmit() are useless, since
crypto engine writes the result digests into ctx->tfm.digest instead of
res->buf. It's better to remove it.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-platform.h |   4 --
 drivers/crypto/mediatek/mtk-sha.c  | 116 ++---
 2 files changed, 34 insertions(+), 86 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-platform.h 
b/drivers/crypto/mediatek/mtk-platform.h
index 3bbe9b0..78ce54e 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -202,8 +202,6 @@ struct mtk_sha_rec {
  * @sha:   pointer to operation record of SHA
  * @aes_list:  device list of AES
  * @sha_list:  device list of SHA
- * @tmp:   pointer to temporary buffer for internal use
- * @tmp_dma:   DMA address of temporary buffer
  * @rec:   it's used to select SHA record for tfm
  *
  * Structure storing cryptographic device information.
@@ -222,8 +220,6 @@ struct mtk_cryp {
struct list_head aes_list;
struct list_head sha_list;
 
-   void *tmp;
-   dma_addr_t tmp_dma;
bool rec;
 };
 
diff --git a/drivers/crypto/mediatek/mtk-sha.c 
b/drivers/crypto/mediatek/mtk-sha.c
index b4f0c62..ef6fb20 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -17,7 +17,6 @@
 
 #define SHA_ALIGN_MSK  (sizeof(u32) - 1)
 #define SHA_QUEUE_SIZE 512
-#define SHA_TMP_BUF_SIZE   512
 #define SHA_BUF_SIZE   ((u32)PAGE_SIZE)
 
 #define SHA_OP_UPDATE  1
@@ -319,7 +318,7 @@ static void mtk_sha_info_init(struct mtk_sha_reqctx *ctx)
  */
 static int mtk_sha_info_update(struct mtk_cryp *cryp,
   struct mtk_sha_rec *sha,
-  size_t len)
+  size_t len1, size_t len2)
 {
struct mtk_sha_reqctx *ctx = ahash_request_ctx(sha->req);
struct mtk_sha_info *info = >info;
@@ -331,11 +330,11 @@ static int mtk_sha_info_update(struct mtk_cryp *cryp,
ct->ctrl[0] &= ~SHA_TFM_START;
 
ctx->ct_hdr &= ~SHA_DATA_LEN_MSK;
-   ctx->ct_hdr |= cpu_to_le32(len);
+   ctx->ct_hdr |= cpu_to_le32(len1 + len2);
ct->cmd[0] &= ~SHA_DATA_LEN_MSK;
-   ct->cmd[0] |= cpu_to_le32(len);
+   ct->cmd[0] |= cpu_to_le32(len1 + len2);
 
-   ctx->digcnt += len;
+   ctx->digcnt += len1;
 
ctx->ct_dma = dma_map_single(cryp->dev, info, sizeof(*info),
 DMA_BIDIRECTIONAL);
@@ -422,67 +421,24 @@ static int mtk_sha_init(struct ahash_request *req)
 }
 
 static int mtk_sha_xmit(struct mtk_cryp *cryp, struct mtk_sha_rec *sha,
-   dma_addr_t addr, size_t len)
+   dma_addr_t addr1, size_t len1,
+   dma_addr_t addr2, size_t len2)
 {
struct mtk_sha_reqctx *ctx = ahash_request_ctx(sha->req);
struct mtk_ring *ring = cryp->ring[sha->id];
struct mtk_desc *cmd = ring->cmd_base + ring->cmd_pos;
struct mtk_desc *res = ring->res_base + ring->res_pos;
-   int err;
-
-   err = mtk_sha_info_update(cryp, sha, len);
-   if (err)
-   return err;
-
-   /* Fill in the command/result descriptors */
-   res->hdr = MTK_DESC_FIRST | MTK_DESC_LAST | MTK_DESC_BUF_LEN(len);
-   res->buf = cpu_to_le32(cryp->tmp_dma);
-
-   cmd->hdr = MTK_DESC_FIRST | MTK_DESC_LAST | MTK_DESC_BUF_LEN(len) |
-  MTK_DESC_CT_LEN(ctx->ct_size);
-
-   cmd->buf = cpu_to_le32(addr);
-   cmd->ct = cpu_to_le32(ctx->ct_dma);
-   cmd->ct_hdr = ctx->ct_hdr;
-   cmd->tfm = cpu_to_le32(ctx->tfm_dma);
-
-   if (++ring->cmd_pos == MTK_DESC_NUM)
-   ring->cmd_pos = 0;
-
-   ring->res_pos = ring->cmd_pos;
-   /*
-* Make sure that all changes to the DMA ring are done before we
-* start engine.
-*/
-   wmb();
-   /* Start DMA transfer */
-   mtk_sha_write(cryp, RDR_PREP_COUNT(sha->id), MTK_DESC_CNT(1));
-   mtk_sha_write(cryp, CDR_PREP_COUNT(sha->id), MTK_DESC_CNT(1));
-
-   return -EINPROGRESS;
-}
-
-static int mtk_sha_xmit2(struct mtk_cryp *cryp,
-struct mtk_sha_rec *sha,
-struct mtk_sha_reqctx *ctx,
-size_t len1, size_t len2)
-{
-   struct mtk_ring *ring = cryp->ring[sha->id];
-   struct mtk_desc *cmd = ring->cmd_base + ring->cmd_pos;
-   struct mtk_desc *res = ring->res_base + ring->res_pos;
-   int err;
+   int err, count = 0;
 
-   err = mtk_sha_info_update(cryp, sha, len1 + len2);
+   err = mtk_sha_info_update(cryp, sha, len1, len2);
if (err)
return err;
 
/* Fill in the command/result descriptors */
-   

[PATCH v1 6/8] crypto: mediatek - fix error handling in mtk_aes_complete()

2017-03-08 Thread Ryder Lee
This patch fixes how errors should be handled by mtk_aes_complete().

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 140e9a3..6a0180d 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -248,6 +248,17 @@ static inline void mtk_aes_restore_sg(const struct 
mtk_aes_dma *dma)
sg->length += dma->remainder;
 }
 
+static inline int mtk_aes_complete(struct mtk_cryp *cryp,
+  struct mtk_aes_rec *aes,
+  int err)
+{
+   aes->flags &= ~AES_FLAGS_BUSY;
+   aes->areq->complete(aes->areq, err);
+   /* Handle new request */
+   tasklet_schedule(>queue_task);
+   return err;
+}
+
 /*
  * Write descriptors for processing. This will configure the engine, load
  * the transform information and then start the packet processing.
@@ -352,7 +363,7 @@ static int mtk_aes_map(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
ctx->ct_dma = dma_map_single(cryp->dev, >ct, sizeof(ctx->ct),
 DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(cryp->dev, ctx->ct_dma)))
-   return -EINVAL;
+   goto exit;
 
ctx->tfm_dma = dma_map_single(cryp->dev, >tfm, sizeof(ctx->tfm),
  DMA_TO_DEVICE);
@@ -389,8 +400,8 @@ static int mtk_aes_map(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
 tfm_map_err:
dma_unmap_single(cryp->dev, ctx->ct_dma, sizeof(ctx->ct),
 DMA_TO_DEVICE);
-
-   return -EINVAL;
+exit:
+   return mtk_aes_complete(cryp, aes, -EINVAL);
 }
 
 /* Initialize transform information of CBC/ECB/CTR mode */
@@ -467,7 +478,7 @@ static int mtk_aes_dma(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes,
padlen = mtk_aes_padlen(len);
 
if (len + padlen > AES_BUF_SIZE)
-   return -ENOMEM;
+   return mtk_aes_complete(cryp, aes, -ENOMEM);
 
if (!src_aligned) {
sg_copy_to_buffer(src, sg_nents(src), aes->buf, len);
@@ -527,14 +538,10 @@ static int mtk_aes_handle_queue(struct mtk_cryp *cryp, u8 
id,
return ctx->start(cryp, aes);
 }
 
-static int mtk_aes_complete(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
+static int mtk_aes_transfer_complete(struct mtk_cryp *cryp,
+struct mtk_aes_rec *aes)
 {
-   aes->flags &= ~AES_FLAGS_BUSY;
-   aes->areq->complete(aes->areq, 0);
-
-   /* Handle new request */
-   tasklet_schedule(>queue_task);
-   return 0;
+   return mtk_aes_complete(cryp, aes, 0);
 }
 
 static int mtk_aes_start(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
@@ -543,7 +550,7 @@ static int mtk_aes_start(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
struct mtk_aes_reqctx *rctx = ablkcipher_request_ctx(req);
 
mtk_aes_set_mode(aes, rctx);
-   aes->resume = mtk_aes_complete;
+   aes->resume = mtk_aes_transfer_complete;
 
return mtk_aes_dma(cryp, aes, req->src, req->dst, req->nbytes);
 }
@@ -568,7 +575,7 @@ static int mtk_aes_ctr_transfer(struct mtk_cryp *cryp, 
struct mtk_aes_rec *aes)
/* Check for transfer completion. */
cctx->offset += aes->total;
if (cctx->offset >= req->nbytes)
-   return mtk_aes_complete(cryp, aes);
+   return mtk_aes_transfer_complete(cryp, aes);
 
/* Compute data length. */
datalen = req->nbytes - cctx->offset;
@@ -602,7 +609,6 @@ static int mtk_aes_ctr_transfer(struct mtk_cryp *cryp, 
struct mtk_aes_rec *aes)
cctx->iv[3] = cpu_to_be32(ctr);
crypto_inc((u8 *)cctx->iv, AES_BLOCK_SIZE);
}
-   aes->resume = mtk_aes_ctr_transfer;
 
return mtk_aes_dma(cryp, aes, src, dst, datalen);
 }
@@ -618,6 +624,7 @@ static int mtk_aes_ctr_start(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
memcpy(cctx->iv, req->info, AES_BLOCK_SIZE);
cctx->offset = 0;
aes->total = 0;
+   aes->resume = mtk_aes_ctr_transfer;
 
return mtk_aes_ctr_transfer(cryp, aes);
 }
@@ -859,7 +866,7 @@ static int mtk_aes_gcm_dma(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes,
 
if (!src_aligned || !dst_aligned) {
if (aes->total > AES_BUF_SIZE)
-   return -ENOMEM;
+   return mtk_aes_complete(cryp, aes, -ENOMEM);
 
if (!src_aligned) {
sg_copy_to_buffer(src, sg_nents(src), aes->buf, len);
@@ -905,7 +912,7 @@ static int mtk_aes_gcm_start(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
aes->total = len;
gctx->textlen = req->cryptlen - gctx->authsize;
}
-   

[PATCH v1 5/8] crypto: mediatek - add queue_task tasklet

2017-03-08 Thread Ryder Lee
This patch adds 'queue_task' to dequeue crypto requset. This will help to
avoid directly calling mtk_aes_handle_queue() / mtk_sha_handle_queue()
from done tasklet or error handler.

In order to avoid confusion, the new code properly renames DMA completion
"task" to "done_task".

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c  | 20 
 drivers/crypto/mediatek/mtk-platform.h | 12 
 drivers/crypto/mediatek/mtk-sha.c  | 19 +++
 3 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 21f3e59..140e9a3 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -533,7 +533,8 @@ static int mtk_aes_complete(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
aes->areq->complete(aes->areq, 0);
 
/* Handle new request */
-   return mtk_aes_handle_queue(cryp, aes->id, NULL);
+   tasklet_schedule(>queue_task);
+   return 0;
 }
 
 static int mtk_aes_start(struct mtk_cryp *cryp, struct mtk_aes_rec *aes)
@@ -1094,6 +1095,13 @@ static void mtk_aes_gcm_exit(struct crypto_aead *aead)
},
 };
 
+static void mtk_aes_queue_task(unsigned long data)
+{
+   struct mtk_aes_rec *aes = (struct mtk_aes_rec *)data;
+
+   mtk_aes_handle_queue(aes->cryp, aes->id, NULL);
+}
+
 static void mtk_aes_done_task(unsigned long data)
 {
struct mtk_aes_rec *aes = (struct mtk_aes_rec *)data;
@@ -1116,7 +1124,7 @@ static irqreturn_t mtk_aes_irq(int irq, void *dev_id)
mtk_aes_write(cryp, RDR_THRESH(aes->id),
  MTK_RDR_PROC_THRESH | MTK_RDR_PROC_MODE);
 
-   tasklet_schedule(>task);
+   tasklet_schedule(>done_task);
} else {
dev_warn(cryp->dev, "AES interrupt when no active requests.\n");
}
@@ -1149,7 +1157,9 @@ static int mtk_aes_record_init(struct mtk_cryp *cryp)
spin_lock_init([i]->lock);
crypto_init_queue([i]->queue, AES_QUEUE_SIZE);
 
-   tasklet_init([i]->task, mtk_aes_done_task,
+   tasklet_init([i]->queue_task, mtk_aes_queue_task,
+(unsigned long)aes[i]);
+   tasklet_init([i]->done_task, mtk_aes_done_task,
 (unsigned long)aes[i]);
}
 
@@ -1173,7 +1183,9 @@ static void mtk_aes_record_free(struct mtk_cryp *cryp)
int i;
 
for (i = 0; i < MTK_REC_NUM; i++) {
-   tasklet_kill(>aes[i]->task);
+   tasklet_kill(>aes[i]->done_task);
+   tasklet_kill(>aes[i]->queue_task);
+
free_page((unsigned long)cryp->aes[i]->buf);
kfree(cryp->aes[i]);
}
diff --git a/drivers/crypto/mediatek/mtk-platform.h 
b/drivers/crypto/mediatek/mtk-platform.h
index 218e30d..cc98c2c 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -128,7 +128,8 @@ struct mtk_aes_dma {
  * @cryp:  pointer to Cryptographic device
  * @queue: crypto request queue
  * @areq:  pointer to async request
- * @task:  the tasklet is use in AES interrupt
+ * @done_task: the tasklet is use in AES interrupt
+ * @queue_task:the tasklet is used to dequeue request
  * @ctx:   pointer to current context
  * @src:   the structure that holds source sg list info
  * @dst:   the structure that holds destination sg list info
@@ -147,7 +148,8 @@ struct mtk_aes_rec {
struct mtk_cryp *cryp;
struct crypto_queue queue;
struct crypto_async_request *areq;
-   struct tasklet_struct task;
+   struct tasklet_struct done_task;
+   struct tasklet_struct queue_task;
struct mtk_aes_base_ctx *ctx;
struct mtk_aes_dma src;
struct mtk_aes_dma dst;
@@ -171,7 +173,8 @@ struct mtk_aes_rec {
  * @cryp:  pointer to Cryptographic device
  * @queue: crypto request queue
  * @req:   pointer to ahash request
- * @task:  the tasklet is use in SHA interrupt
+ * @done_task: the tasklet is use in SHA interrupt
+ * @queue_task:the tasklet is used to dequeue request
  * @id:the current use of ring
  * @flags: it's describing SHA operation state
  * @lock:  the async queue lock
@@ -182,7 +185,8 @@ struct mtk_sha_rec {
struct mtk_cryp *cryp;
struct crypto_queue queue;
struct ahash_request *req;
-   struct tasklet_struct task;
+   struct tasklet_struct done_task;
+   struct tasklet_struct queue_task;
 
u8 id;
unsigned long flags;
diff --git a/drivers/crypto/mediatek/mtk-sha.c 
b/drivers/crypto/mediatek/mtk-sha.c
index 0884d62..dd3582b 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -661,7 +661,7 @@ static void mtk_sha_finish_req(struct mtk_cryp *cryp,
sha->req->base.complete(>req->base, 

[PATCH v1 2/8] crypto: mediatek - add MTK_* prefix and correct annotations.

2017-03-08 Thread Ryder Lee
Dummy patch to add MTK_* prefix to ring enum and fix incorrect annotations.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c  | 12 ++--
 drivers/crypto/mediatek/mtk-platform.c | 12 ++--
 drivers/crypto/mediatek/mtk-platform.h | 26 +-
 drivers/crypto/mediatek/mtk-sha.c  | 14 +++---
 4 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index e67881f..b57b68f 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -1152,8 +1152,8 @@ static int mtk_aes_record_init(struct mtk_cryp *cryp)
}
 
/* Link to ring0 and ring1 respectively */
-   aes[0]->id = RING0;
-   aes[1]->id = RING1;
+   aes[0]->id = MTK_RING0;
+   aes[1]->id = MTK_RING1;
 
return 0;
 
@@ -1221,14 +1221,14 @@ int mtk_cipher_alg_register(struct mtk_cryp *cryp)
if (ret)
goto err_record;
 
-   ret = devm_request_irq(cryp->dev, cryp->irq[RING0], mtk_aes_irq,
+   ret = devm_request_irq(cryp->dev, cryp->irq[MTK_RING0], mtk_aes_irq,
   0, "mtk-aes", cryp->aes[0]);
if (ret) {
dev_err(cryp->dev, "unable to request AES irq.\n");
goto err_res;
}
 
-   ret = devm_request_irq(cryp->dev, cryp->irq[RING1], mtk_aes_irq,
+   ret = devm_request_irq(cryp->dev, cryp->irq[MTK_RING1], mtk_aes_irq,
   0, "mtk-aes", cryp->aes[1]);
if (ret) {
dev_err(cryp->dev, "unable to request AES irq.\n");
@@ -1236,8 +1236,8 @@ int mtk_cipher_alg_register(struct mtk_cryp *cryp)
}
 
/* Enable ring0 and ring1 interrupt */
-   mtk_aes_write(cryp, AIC_ENABLE_SET(RING0), MTK_IRQ_RDR0);
-   mtk_aes_write(cryp, AIC_ENABLE_SET(RING1), MTK_IRQ_RDR1);
+   mtk_aes_write(cryp, AIC_ENABLE_SET(MTK_RING0), MTK_IRQ_RDR0);
+   mtk_aes_write(cryp, AIC_ENABLE_SET(MTK_RING1), MTK_IRQ_RDR1);
 
spin_lock(_aes.lock);
list_add_tail(>aes_list, _aes.dev_list);
diff --git a/drivers/crypto/mediatek/mtk-platform.c 
b/drivers/crypto/mediatek/mtk-platform.c
index a9c713d..50de335 100644
--- a/drivers/crypto/mediatek/mtk-platform.c
+++ b/drivers/crypto/mediatek/mtk-platform.c
@@ -334,7 +334,7 @@ static int mtk_packet_engine_setup(struct mtk_cryp *cryp)
/* Enable the 4 rings for the packet engines. */
mtk_desc_ring_link(cryp, 0xf);
 
-   for (i = 0; i < RING_MAX; i++) {
+   for (i = 0; i < MTK_RING_MAX; i++) {
mtk_cmd_desc_ring_setup(cryp, i, );
mtk_res_desc_ring_setup(cryp, i, );
}
@@ -359,7 +359,7 @@ static int mtk_aic_cap_check(struct mtk_cryp *cryp, int hw)
 {
u32 val;
 
-   if (hw == RING_MAX)
+   if (hw == MTK_RING_MAX)
val = readl(cryp->base + AIC_G_VERSION);
else
val = readl(cryp->base + AIC_VERSION(hw));
@@ -368,7 +368,7 @@ static int mtk_aic_cap_check(struct mtk_cryp *cryp, int hw)
if (val != MTK_AIC_VER11 && val != MTK_AIC_VER12)
return -ENXIO;
 
-   if (hw == RING_MAX)
+   if (hw == MTK_RING_MAX)
val = readl(cryp->base + AIC_G_OPTIONS);
else
val = readl(cryp->base + AIC_OPTIONS(hw));
@@ -389,7 +389,7 @@ static int mtk_aic_init(struct mtk_cryp *cryp, int hw)
return err;
 
/* Disable all interrupts and set initial configuration */
-   if (hw == RING_MAX) {
+   if (hw == MTK_RING_MAX) {
writel(0, cryp->base + AIC_G_ENABLE_CTRL);
writel(0, cryp->base + AIC_G_POL_CTRL);
writel(0, cryp->base + AIC_G_TYPE_CTRL);
@@ -431,7 +431,7 @@ static void mtk_desc_dma_free(struct mtk_cryp *cryp)
 {
int i;
 
-   for (i = 0; i < RING_MAX; i++) {
+   for (i = 0; i < MTK_RING_MAX; i++) {
dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
  cryp->ring[i]->res_base,
  cryp->ring[i]->res_dma);
@@ -447,7 +447,7 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
struct mtk_ring **ring = cryp->ring;
int i, err = ENOMEM;
 
-   for (i = 0; i < RING_MAX; i++) {
+   for (i = 0; i < MTK_RING_MAX; i++) {
ring[i] = kzalloc(sizeof(**ring), GFP_KERNEL);
if (!ring[i])
goto err_cleanup;
diff --git a/drivers/crypto/mediatek/mtk-platform.h 
b/drivers/crypto/mediatek/mtk-platform.h
index d2a1db6..3bbe9b0 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -38,14 +38,14 @@
  * Ring 2/3 are used by SHA.
  */
 enum {
-   RING0 = 0,
-   RING1,
-   RING2,
-   RING3,
-   RING_MAX,
+   MTK_RING0,
+   MTK_RING1,
+   MTK_RING2,
+   MTK_RING3,
+   MTK_RING_MAX
 };
 

[PATCH v1 4/8] crypto: mediatek - simplify descriptor ring management

2017-03-08 Thread Ryder Lee
This patch replaces cmd_pos/res_pos with pointer cmd_next/res_next.

In old code, we must to add one to shift ring to the next segment, and
then use this value to caculate current offset from ring base for each
DMA operation. Now these pointers helps us to simplify flow, so we just
need to move pointers and check the boundaries of ring.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c  | 14 --
 drivers/crypto/mediatek/mtk-platform.c |  3 +++
 drivers/crypto/mediatek/mtk-platform.h |  8 
 drivers/crypto/mediatek/mtk-sha.c  | 35 ++
 4 files changed, 34 insertions(+), 26 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index b57b68f..21f3e59 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -262,7 +262,7 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
 
/* Write command descriptors */
for (nents = 0; nents < slen; ++nents, ssg = sg_next(ssg)) {
-   cmd = ring->cmd_base + ring->cmd_pos;
+   cmd = ring->cmd_next;
cmd->hdr = MTK_DESC_BUF_LEN(ssg->length);
cmd->buf = cpu_to_le32(sg_dma_address(ssg));
 
@@ -274,22 +274,24 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
cmd->tfm = cpu_to_le32(aes->ctx->tfm_dma);
}
 
-   if (++ring->cmd_pos == MTK_DESC_NUM)
-   ring->cmd_pos = 0;
+   /* Shift ring buffer and check boundary */
+   if (++ring->cmd_next == ring->cmd_base + MTK_DESC_NUM)
+   ring->cmd_next = ring->cmd_base;
}
cmd->hdr |= MTK_DESC_LAST;
 
/* Prepare result descriptors */
for (nents = 0; nents < dlen; ++nents, dsg = sg_next(dsg)) {
-   res = ring->res_base + ring->res_pos;
+   res = ring->res_next;
res->hdr = MTK_DESC_BUF_LEN(dsg->length);
res->buf = cpu_to_le32(sg_dma_address(dsg));
 
if (nents == 0)
res->hdr |= MTK_DESC_FIRST;
 
-   if (++ring->res_pos == MTK_DESC_NUM)
-   ring->res_pos = 0;
+   /* Shift ring buffer and check boundary */
+   if (++ring->res_next == ring->res_base + MTK_DESC_NUM)
+   ring->res_next = ring->res_base;
}
res->hdr |= MTK_DESC_LAST;
 
diff --git a/drivers/crypto/mediatek/mtk-platform.c 
b/drivers/crypto/mediatek/mtk-platform.c
index 50de335..b6ecc28 100644
--- a/drivers/crypto/mediatek/mtk-platform.c
+++ b/drivers/crypto/mediatek/mtk-platform.c
@@ -465,6 +465,9 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
   GFP_KERNEL);
if (!ring[i]->res_base)
goto err_cleanup;
+
+   ring[i]->cmd_next = ring[i]->cmd_base;
+   ring[i]->res_next = ring[i]->res_base;
}
return 0;
 
diff --git a/drivers/crypto/mediatek/mtk-platform.h 
b/drivers/crypto/mediatek/mtk-platform.h
index 78ce54e..218e30d 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -84,11 +84,11 @@ struct mtk_desc {
 /**
  * struct mtk_ring - Descriptor ring
  * @cmd_base:  pointer to command descriptor ring base
+ * @cmd_next:  pointer to the next command descriptor
  * @cmd_dma:   DMA address of command descriptor ring
- * @cmd_pos:   current position in the command descriptor ring
  * @res_base:  pointer to result descriptor ring base
+ * @res_next:  pointer to the next result descriptor
  * @res_dma:   DMA address of result descriptor ring
- * @res_pos:   current position in the result descriptor ring
  *
  * A descriptor ring is a circular buffer that is used to manage
  * one or more descriptors. There are two type of descriptor rings;
@@ -96,11 +96,11 @@ struct mtk_desc {
  */
 struct mtk_ring {
struct mtk_desc *cmd_base;
+   struct mtk_desc *cmd_next;
dma_addr_t cmd_dma;
-   u32 cmd_pos;
struct mtk_desc *res_base;
+   struct mtk_desc *res_next;
dma_addr_t res_dma;
-   u32 res_pos;
 };
 
 /**
diff --git a/drivers/crypto/mediatek/mtk-sha.c 
b/drivers/crypto/mediatek/mtk-sha.c
index ef6fb20..0884d62 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -152,6 +152,21 @@ static inline void mtk_sha_write(struct mtk_cryp *cryp,
writel_relaxed(value, cryp->base + offset);
 }
 
+static inline void mtk_sha_ring_shift(struct mtk_ring *ring,
+ struct mtk_desc **cmd_curr,
+ struct mtk_desc **res_curr,
+ int *count)
+{
+   *cmd_curr = ring->cmd_next++;
+   *res_curr = ring->res_next++;
+   (*count)++;
+
+

[PATCH v1 1/8] crypto: mediatek - rework interrupt handler

2017-03-08 Thread Ryder Lee
This patch removes redundant task that used to handle interrupt
from ring manager, so that the same task/handler can be shared.
It also uses aes->id and sha-id to distinguish interrupt sources.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c  | 73 +++---
 drivers/crypto/mediatek/mtk-platform.h |  4 ++
 drivers/crypto/mediatek/mtk-sha.c  | 73 ++
 3 files changed, 49 insertions(+), 101 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 3a47cdb..e67881f 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -1092,55 +1092,26 @@ static void mtk_aes_gcm_exit(struct crypto_aead *aead)
},
 };
 
-static void mtk_aes_enc_task(unsigned long data)
+static void mtk_aes_done_task(unsigned long data)
 {
-   struct mtk_cryp *cryp = (struct mtk_cryp *)data;
-   struct mtk_aes_rec *aes = cryp->aes[0];
+   struct mtk_aes_rec *aes = (struct mtk_aes_rec *)data;
+   struct mtk_cryp *cryp = aes->cryp;
 
mtk_aes_unmap(cryp, aes);
aes->resume(cryp, aes);
 }
 
-static void mtk_aes_dec_task(unsigned long data)
+static irqreturn_t mtk_aes_irq(int irq, void *dev_id)
 {
-   struct mtk_cryp *cryp = (struct mtk_cryp *)data;
-   struct mtk_aes_rec *aes = cryp->aes[1];
+   struct mtk_aes_rec *aes  = (struct mtk_aes_rec *)dev_id;
+   struct mtk_cryp *cryp = aes->cryp;
+   u32 val = mtk_aes_read(cryp, RDR_STAT(aes->id));
 
-   mtk_aes_unmap(cryp, aes);
-   aes->resume(cryp, aes);
-}
-
-static irqreturn_t mtk_aes_enc_irq(int irq, void *dev_id)
-{
-   struct mtk_cryp *cryp = (struct mtk_cryp *)dev_id;
-   struct mtk_aes_rec *aes = cryp->aes[0];
-   u32 val = mtk_aes_read(cryp, RDR_STAT(RING0));
-
-   mtk_aes_write(cryp, RDR_STAT(RING0), val);
-
-   if (likely(AES_FLAGS_BUSY & aes->flags)) {
-   mtk_aes_write(cryp, RDR_PROC_COUNT(RING0), MTK_CNT_RST);
-   mtk_aes_write(cryp, RDR_THRESH(RING0),
- MTK_RDR_PROC_THRESH | MTK_RDR_PROC_MODE);
-
-   tasklet_schedule(>task);
-   } else {
-   dev_warn(cryp->dev, "AES interrupt when no active requests.\n");
-   }
-   return IRQ_HANDLED;
-}
-
-static irqreturn_t mtk_aes_dec_irq(int irq, void *dev_id)
-{
-   struct mtk_cryp *cryp = (struct mtk_cryp *)dev_id;
-   struct mtk_aes_rec *aes = cryp->aes[1];
-   u32 val = mtk_aes_read(cryp, RDR_STAT(RING1));
-
-   mtk_aes_write(cryp, RDR_STAT(RING1), val);
+   mtk_aes_write(cryp, RDR_STAT(aes->id), val);
 
if (likely(AES_FLAGS_BUSY & aes->flags)) {
-   mtk_aes_write(cryp, RDR_PROC_COUNT(RING1), MTK_CNT_RST);
-   mtk_aes_write(cryp, RDR_THRESH(RING1),
+   mtk_aes_write(cryp, RDR_PROC_COUNT(aes->id), MTK_CNT_RST);
+   mtk_aes_write(cryp, RDR_THRESH(aes->id),
  MTK_RDR_PROC_THRESH | MTK_RDR_PROC_MODE);
 
tasklet_schedule(>task);
@@ -1171,14 +1142,18 @@ static int mtk_aes_record_init(struct mtk_cryp *cryp)
if (!aes[i]->buf)
goto err_cleanup;
 
-   aes[i]->id = i;
+   aes[i]->cryp = cryp;
 
spin_lock_init([i]->lock);
crypto_init_queue([i]->queue, AES_QUEUE_SIZE);
+
+   tasklet_init([i]->task, mtk_aes_done_task,
+(unsigned long)aes[i]);
}
 
-   tasklet_init([0]->task, mtk_aes_enc_task, (unsigned long)cryp);
-   tasklet_init([1]->task, mtk_aes_dec_task, (unsigned long)cryp);
+   /* Link to ring0 and ring1 respectively */
+   aes[0]->id = RING0;
+   aes[1]->id = RING1;
 
return 0;
 
@@ -1246,19 +1221,17 @@ int mtk_cipher_alg_register(struct mtk_cryp *cryp)
if (ret)
goto err_record;
 
-   /* Ring0 is use by encryption record */
-   ret = devm_request_irq(cryp->dev, cryp->irq[RING0], mtk_aes_enc_irq,
-  IRQF_TRIGGER_LOW, "mtk-aes", cryp);
+   ret = devm_request_irq(cryp->dev, cryp->irq[RING0], mtk_aes_irq,
+  0, "mtk-aes", cryp->aes[0]);
if (ret) {
-   dev_err(cryp->dev, "unable to request AES encryption irq.\n");
+   dev_err(cryp->dev, "unable to request AES irq.\n");
goto err_res;
}
 
-   /* Ring1 is use by decryption record */
-   ret = devm_request_irq(cryp->dev, cryp->irq[RING1], mtk_aes_dec_irq,
-  IRQF_TRIGGER_LOW, "mtk-aes", cryp);
+   ret = devm_request_irq(cryp->dev, cryp->irq[RING1], mtk_aes_irq,
+  0, "mtk-aes", cryp->aes[1]);
if (ret) {
-   dev_err(cryp->dev, "unable to request AES decryption irq.\n");
+   dev_err(cryp->dev, "unable to request AES irq.\n");
 

[PATCH v1 0/8] improve performances on mediatek crypto driver

2017-03-08 Thread Ryder Lee
Hi all,

Some patches of this series improve the performances whereas others
clean up code and refine data structure to make it more efficient

Changes since v1:
- drop OFB and CFB patch

Ryder Lee (8):
  crypto: mediatek - rework interrupt handler
  crypto: mediatek - add MTK_* prefix and correct annotations.
  crypto: mediatek - make mtk_sha_xmit() more generic
  crypto: mediatek - simplify descriptor ring management
  crypto: mediatek - add queue_task tasklet
  crypto: mediatek - fix error handling in mtk_aes_complete()
  crypto: mediatek - add mtk_aes_gcm_tag_verify()
  crypto: mediatek - make hardware operation flow more efficient

 drivers/crypto/mediatek/mtk-aes.c  | 421 +
 drivers/crypto/mediatek/mtk-platform.c |  15 +-
 drivers/crypto/mediatek/mtk-platform.h |  56 +++--
 drivers/crypto/mediatek/mtk-sha.c  | 309 +---
 4 files changed, 369 insertions(+), 432 deletions(-)

-- 
1.9.1



[PATCH v1 7/8] crypto: mediatek - add mtk_aes_gcm_tag_verify()

2017-03-08 Thread Ryder Lee
This patch adds mtk_aes_gcm_tag_verify() which is used to compare
authenticated tag.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c  | 24 ++--
 drivers/crypto/mediatek/mtk-platform.h |  2 ++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 6a0180d..8f3efa5 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -70,6 +70,8 @@
 #define AES_FLAGS_ENCRYPT  BIT(4)
 #define AES_FLAGS_BUSY BIT(5)
 
+#define AES_AUTH_TAG_ERR   cpu_to_le32(BIT(26))
+
 /**
  * Command token(CT) is a set of hardware instructions that
  * are used to control engine's processing flow of AES.
@@ -306,6 +308,9 @@ static int mtk_aes_xmit(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
}
res->hdr |= MTK_DESC_LAST;
 
+   /* Pointer to current result descriptor */
+   ring->res_prev = res;
+
/* Prepare enough space for authenticated tag */
if (aes->flags & AES_FLAGS_GCM)
res->hdr += AES_BLOCK_SIZE;
@@ -799,6 +804,19 @@ static int mtk_aes_ctr_cra_init(struct crypto_tfm *tfm)
return container_of(ctx, struct mtk_aes_gcm_ctx, base);
 }
 
+/*
+ * Engine will verify and compare tag automatically, so we just need
+ * to check returned status which stored in the result descriptor.
+ */
+static int mtk_aes_gcm_tag_verify(struct mtk_cryp *cryp,
+ struct mtk_aes_rec *aes)
+{
+   u32 status = cryp->ring[aes->id]->res_prev->ct;
+
+   return mtk_aes_complete(cryp, aes, (status & AES_AUTH_TAG_ERR) ?
+   -EBADMSG : 0);
+}
+
 /* Initialize transform information of GCM mode */
 static void mtk_aes_gcm_info_init(struct mtk_cryp *cryp,
  struct mtk_aes_rec *aes,
@@ -902,6 +920,8 @@ static int mtk_aes_gcm_start(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
 
if (aes->flags & AES_FLAGS_ENCRYPT) {
u32 tag[4];
+
+   aes->resume = mtk_aes_transfer_complete;
/* Compute total process length. */
aes->total = len + gctx->authsize;
/* Compute text length. */
@@ -909,10 +929,10 @@ static int mtk_aes_gcm_start(struct mtk_cryp *cryp, 
struct mtk_aes_rec *aes)
/* Hardware will append authenticated tag to output buffer */
scatterwalk_map_and_copy(tag, req->dst, len, gctx->authsize, 1);
} else {
+   aes->resume = mtk_aes_gcm_tag_verify;
aes->total = len;
gctx->textlen = req->cryptlen - gctx->authsize;
}
-   aes->resume = mtk_aes_transfer_complete;
 
return mtk_aes_gcm_dma(cryp, aes, req->src, req->dst, len);
 }
@@ -925,7 +945,7 @@ static int mtk_aes_gcm_crypt(struct aead_request *req, u64 
mode)
rctx->mode = AES_FLAGS_GCM | mode;
 
return mtk_aes_handle_queue(ctx->cryp, !!(mode & AES_FLAGS_ENCRYPT),
-   >base);
+   >base);
 }
 
 static void mtk_gcm_setkey_done(struct crypto_async_request *req, int err)
diff --git a/drivers/crypto/mediatek/mtk-platform.h 
b/drivers/crypto/mediatek/mtk-platform.h
index cc98c2c..303c152 100644
--- a/drivers/crypto/mediatek/mtk-platform.h
+++ b/drivers/crypto/mediatek/mtk-platform.h
@@ -88,6 +88,7 @@ struct mtk_desc {
  * @cmd_dma:   DMA address of command descriptor ring
  * @res_base:  pointer to result descriptor ring base
  * @res_next:  pointer to the next result descriptor
+ * @res_prev:  pointer to the previous result descriptor
  * @res_dma:   DMA address of result descriptor ring
  *
  * A descriptor ring is a circular buffer that is used to manage
@@ -100,6 +101,7 @@ struct mtk_ring {
dma_addr_t cmd_dma;
struct mtk_desc *res_base;
struct mtk_desc *res_next;
+   struct mtk_desc *res_prev;
dma_addr_t res_dma;
 };
 
-- 
1.9.1



[PATCH v1 8/8] crypto: mediatek - make hardware operation flow more efficient

2017-03-08 Thread Ryder Lee
This patch refines data structures, which are used to control engine's
data path, to make it more efficient. Hence current change are:

- gathers the broken pieces of structures 'mtk_aes_ct''mtk_aes_tfm'
into struct mtk_aes_info hence avoiding additional DMA-mapping.

- adds 'keymode' in struct mtk_aes_base_ctx. When .setkey() callback is
called, we store keybit setting in keymode. Doing so, there is no need
to check keylen second time in mtk_aes_info_init() / mtk_aes_gcm_info_init().

Besides, this patch also removes unused macro definitions and adds helper
inline function to write security information(key, IV,...) to info->state.

Signed-off-by: Ryder Lee 
---
 drivers/crypto/mediatek/mtk-aes.c | 263 ++
 drivers/crypto/mediatek/mtk-sha.c |  90 ++---
 2 files changed, 165 insertions(+), 188 deletions(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 8f3efa5..9e845e8 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -19,13 +19,10 @@
 #define AES_BUF_ORDER  2
 #define AES_BUF_SIZE   ((PAGE_SIZE << AES_BUF_ORDER) \
& ~(AES_BLOCK_SIZE - 1))
+#define AES_MAX_STATE_BUF_SIZE SIZE_IN_WORDS(AES_KEYSIZE_256 + \
+   AES_BLOCK_SIZE * 2)
+#define AES_MAX_CT_SIZE6
 
-/* AES command token size */
-#define AES_CT_SIZE_ECB2
-#define AES_CT_SIZE_CBC3
-#define AES_CT_SIZE_CTR3
-#define AES_CT_SIZE_GCM_OUT5
-#define AES_CT_SIZE_GCM_IN 6
 #define AES_CT_CTRL_HDRcpu_to_le32(0x0022)
 
 /* AES-CBC/ECB/CTR command token */
@@ -50,6 +47,8 @@
 #define AES_TFM_128BITScpu_to_le32(0xb << 16)
 #define AES_TFM_192BITScpu_to_le32(0xd << 16)
 #define AES_TFM_256BITScpu_to_le32(0xf << 16)
+#define AES_TFM_GHASH_DIGEST   cpu_to_le32(0x2 << 21)
+#define AES_TFM_GHASH  cpu_to_le32(0x4 << 23)
 /* AES transform information word 1 fields */
 #define AES_TFM_ECBcpu_to_le32(0x0 << 0)
 #define AES_TFM_CBCcpu_to_le32(0x1 << 0)
@@ -59,10 +58,9 @@
 #define AES_TFM_FULL_IVcpu_to_le32(0xf << 5)   /* using IV 0-3 
*/
 #define AES_TFM_IV_CTR_MODEcpu_to_le32(0x1 << 10)
 #define AES_TFM_ENC_HASH   cpu_to_le32(0x1 << 17)
-#define AES_TFM_GHASH_DIG  cpu_to_le32(0x2 << 21)
-#define AES_TFM_GHASH  cpu_to_le32(0x4 << 23)
 
 /* AES flags */
+#define AES_FLAGS_CIPHER_MSK   GENMASK(2, 0)
 #define AES_FLAGS_ECB  BIT(0)
 #define AES_FLAGS_CBC  BIT(1)
 #define AES_FLAGS_CTR  BIT(2)
@@ -73,18 +71,12 @@
 #define AES_AUTH_TAG_ERR   cpu_to_le32(BIT(26))
 
 /**
- * Command token(CT) is a set of hardware instructions that
- * are used to control engine's processing flow of AES.
- *
- * Transform information(TFM) is used to define AES state and
- * contains all keys and initial vectors.
- *
- * The engine requires CT and TFM to do:
- * - Commands decoding and control of the engine's data path.
- * - Coordinating hardware data fetch and store operations.
- * - Result token construction and output.
+ * mtk_aes_info - hardware information of AES
+ * @cmd:   command token, hardware instruction
+ * @tfm:   transform state of cipher algorithm.
+ * @state: contains keys and initial vectors.
  *
- * Memory map of GCM's TFM:
+ * Memory layout of GCM buffer:
  * /---\
  * |  AES KEY  | 128/196/256 bits
  * |---|
@@ -92,14 +84,16 @@
  * |---|
  * |IVs| 4 * 4 bytes
  * \---/
+ *
+ * The engine requires all these info to do:
+ * - Commands decoding and control of the engine's data path.
+ * - Coordinating hardware data fetch and store operations.
+ * - Result token construction and output.
  */
-struct mtk_aes_ct {
-   __le32 cmd[AES_CT_SIZE_GCM_IN];
-};
-
-struct mtk_aes_tfm {
-   __le32 ctrl[2];
-   __le32 state[SIZE_IN_WORDS(AES_KEYSIZE_256 + AES_BLOCK_SIZE * 2)];
+struct mtk_aes_info {
+   __le32 cmd[AES_MAX_CT_SIZE];
+   __le32 tfm[2];
+   __le32 state[AES_MAX_STATE_BUF_SIZE];
 };
 
 struct mtk_aes_reqctx {
@@ -109,11 +103,12 @@ struct mtk_aes_reqctx {
 struct mtk_aes_base_ctx {
struct mtk_cryp *cryp;
u32 keylen;
+   __le32 keymode;
+
mtk_aes_fn start;
 
-   struct mtk_aes_ct ct;
+   struct mtk_aes_info info;
dma_addr_t ct_dma;
-   struct mtk_aes_tfm tfm;
dma_addr_t tfm_dma;
 
__le32 ct_hdr;
@@ -250,6 +245,22 @@ static inline void mtk_aes_restore_sg(const struct 
mtk_aes_dma *dma)
sg->length += dma->remainder;
 }
 
+static inline void mtk_aes_write_state_le(__le32 *dst, const u32 *src, u32 
size)
+{
+   int i;
+
+   for (i = 0; i < SIZE_IN_WORDS(size); i++)
+   dst[i] = cpu_to_le32(src[i]);
+}
+
+static inline void mtk_aes_write_state_be(__be32 *dst, const u32 

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-08 Thread Krzysztof Kozlowski
On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> > OK, I just tried 4.10.0 and the output is looking the same.
> > 
> > I can't say my setup is all that odd. The cryptographic use is only
> > with the swap partition found in my original email (seen in Herbert's
> > reply).
> 
> You have quite specific/customized config and compilation flags.
> I doubt that it causes the issue but at least the config is unusable on
> anything other then XU3/XU4.
> 
> Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10
> and v4.11-rc1, with regular exynos defconfig plus some more crypto
> algorithms:
> 1. Without my patch: the original warning.
> 2. With my patch:

I sent a fix. At least for spin lock recursion in tcrypt.

Could you give it a try?

Best regards,
Krzysztof


[PATCH] crypto: s5p-sss - Fix spinlock recursion on LRW(AES)

2017-03-08 Thread Krzysztof Kozlowski
Running TCRYPT with LRW compiled causes spinlock recursion:

testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds 
(304112 bytes)
tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds 
(1008192 bytes)
tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 
seconds (3659008 bytes)
tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 
seconds (12191744 bytes)
tcrypt: test 4 (256 bit key, 8192 byte blocks):
BUG: spinlock recursion on CPU#1, irq/84-1083/89
 lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-1083/89, 
.owner_cpu: 1
CPU: 1 PID: 89 Comm: irq/84-1083 Not tainted 
4.11.0-rc1-1-g897ca6d0800d #559
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x78/0x8c)
[] (dump_stack) from [] (do_raw_spin_lock+0x11c/0x120)
[] (do_raw_spin_lock) from [] 
(_raw_spin_lock_irqsave+0x20/0x28)
[] (_raw_spin_lock_irqsave) from [] 
(s5p_aes_crypt+0x2c/0xb4)
[] (s5p_aes_crypt) from [] (do_encrypt+0x78/0xb0 [lrw])
[] (do_encrypt [lrw]) from [] (encrypt_done+0x24/0x54 
[lrw])
[] (encrypt_done [lrw]) from [] 
(s5p_aes_complete+0x60/0xcc)
[] (s5p_aes_complete) from [] 
(s5p_aes_interrupt+0x134/0x1a0)
[] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54)
[] (irq_thread_fn) from [] (irq_thread+0x12c/0x1e0)
[] (irq_thread) from [] (kthread+0x108/0x138)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)

Interrupt handling routine was calling req->base.complete() under
spinlock.  In most cases this wasn't fatal but when combined with some
of the cipher modes (like LRW) this caused recursion - starting the new
encryption (s5p_aes_crypt()) while still holding the spinlock from
previous round (s5p_aes_complete()).

Beside that, the s5p_aes_interrupt() error handling path could execute
two completions in case of error for RX and TX blocks.

Rewrite the interrupt handling routine and the completion by:

1. Splitting the operations on scatterlist copies from
   s5p_aes_complete() into separate s5p_sg_done(). This still should be
   done under lock.
   The s5p_aes_complete() now only calls req->base.complete() and it has
   to be called outside of lock.

2. Moving the s5p_aes_complete() out of spinlock critical sections.
   In interrupt service routine s5p_aes_interrupts(), it appeared in few
   places, including error paths inside other functions called from ISR.
   This code was not so obvious to read so simplify it by putting the
   s5p_aes_complete() only within ISR level.

Reported-by: Nathan Royce 
Cc:  # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix 
completing
Cc:  # v4.10.x
Signed-off-by: Krzysztof Kozlowski 

---

I think, along with 07de4bc88c this should be backported to v4.10 as it
happens there.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/crypto/s5p-sss.c | 127 ++-
 1 file changed, 82 insertions(+), 45 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index a668286d62cb..1b9da3dc799b 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -270,7 +270,7 @@ static void s5p_sg_copy_buf(void *buf, struct scatterlist 
*sg,
scatterwalk_done(, out, 0);
 }
 
-static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
+static void s5p_sg_done(struct s5p_aes_dev *dev)
 {
if (dev->sg_dst_cpy) {
dev_dbg(dev->dev,
@@ -281,8 +281,11 @@ static void s5p_aes_complete(struct s5p_aes_dev *dev, int 
err)
}
s5p_free_sg_cpy(dev, >sg_src_cpy);
s5p_free_sg_cpy(dev, >sg_dst_cpy);
+}
 
-   /* holding a lock outside */
+/* Calls the completion. Cannot be called with dev->lock hold. */
+static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
+{
dev->req->base.complete(>req->base, err);
dev->busy = false;
 }
@@ -368,51 +371,44 @@ static int s5p_set_indata(struct s5p_aes_dev *dev, struct 
scatterlist *sg)
 }
 
 /*
- * Returns true if new transmitting (output) data is ready and its
- * address+length have to be written to device (by calling
- * s5p_set_dma_outdata()). False otherwise.
+ * Returns -ERRNO on error (mapping of new data failed).
+ * On success returns:
+ *  - 0 if there is no more data,
+ *  - 1 if new transmitting (output) data is ready and its address+length
+ * have to be written to device (by calling s5p_set_dma_outdata()).
  */
-static bool s5p_aes_tx(struct s5p_aes_dev *dev)
+static int s5p_aes_tx(struct s5p_aes_dev *dev)
 {
-   int err = 0;
-   bool ret = false;
+   int ret = 0;
 
s5p_unset_outdata(dev);
 
if (!sg_is_last(dev->sg_dst)) {
-   err = s5p_set_outdata(dev, 

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-08 Thread Krzysztof Kozlowski
On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> OK, I just tried 4.10.0 and the output is looking the same.
> 
> I can't say my setup is all that odd. The cryptographic use is only
> with the swap partition found in my original email (seen in Herbert's
> reply).

You have quite specific/customized config and compilation flags.
I doubt that it causes the issue but at least the config is unusable on
anything other then XU3/XU4.

Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10
and v4.11-rc1, with regular exynos defconfig plus some more crypto
algorithms:
1. Without my patch: the original warning.
2. With my patch:

[   95.170527] testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
[   95.173990] tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations 
in 1 seconds (304112 bytes)
[   96.175986] tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations 
in 1 seconds (1008192 bytes)
[   97.176099] tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations 
in 1 seconds (3659008 bytes)
[   98.176177] tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations 
in 1 seconds (12191744 bytes)
[   99.176407] tcrypt: test 4 (256 bit key, 8192 byte blocks):
[   99.177235] BUG: spinlock recursion on CPU#1, irq/84-1083/89
[   99.188034]  lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-1083/89, 
.owner_cpu: 1
[   99.196282] CPU: 1 PID: 89 Comm: irq/84-1083 Not tainted 
4.11.0-rc1-1-g897ca6d0800d #559
[   99.205038] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   99.211158] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   99.218863] [] (show_stack) from [] 
(dump_stack+0x78/0x8c)
[   99.226060] [] (dump_stack) from [] 
(do_raw_spin_lock+0x11c/0x120)
[   99.233962] [] (do_raw_spin_lock) from [] 
(_raw_spin_lock_irqsave+0x20/0x28)
[   99.242733] [] (_raw_spin_lock_irqsave) from [] 
(s5p_aes_crypt+0x2c/0xb4)
[   99.251240] [] (s5p_aes_crypt) from [] 
(do_encrypt+0x78/0xb0 [lrw])
[   99.259230] [] (do_encrypt [lrw]) from [] 
(encrypt_done+0x24/0x54 [lrw])
[   99.267628] [] (encrypt_done [lrw]) from [] 
(s5p_aes_complete+0x60/0xcc)
[   99.276046] [] (s5p_aes_complete) from [] 
(s5p_aes_interrupt+0x134/0x1a0)
[   99.284558] [] (s5p_aes_interrupt) from [] 
(irq_thread_fn+0x1c/0x54)
[   99.292624] [] (irq_thread_fn) from [] 
(irq_thread+0x12c/0x1e0)
[   99.300269] [] (irq_thread) from [] (kthread+0x108/0x138)
[   99.307382] [] (kthread) from [] 
(ret_from_fork+0x14/0x3c)

I will take a look into this.

Thanks for the report.

Best regards,
Krzysztof



Re: [RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption

2017-03-08 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:14:25AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> DMA access to memory mapped as encrypted while SEV is active can not be
> encrypted during device write or decrypted during device read. In order
> for DMA to properly work when SEV is active, the swiotlb bounce buffers
> must be used.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/mm/mem_encrypt.c |   77 
> +
>  1 file changed, 77 insertions(+)
> 
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 090419b..7df5f4c 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -197,8 +197,81 @@ void __init sme_early_init(void)
>   /* Update the protection map with memory encryption mask */
>   for (i = 0; i < ARRAY_SIZE(protection_map); i++)
>   protection_map[i] = pgprot_encrypted(protection_map[i]);
> +
> + if (sev_active())
> + swiotlb_force = SWIOTLB_FORCE;
> +}
> +
> +static void *sme_alloc(struct device *dev, size_t size, dma_addr_t 
> *dma_handle,
> +gfp_t gfp, unsigned long attrs)
> +{
> + unsigned long dma_mask;
> + unsigned int order;
> + struct page *page;
> + void *vaddr = NULL;
> +
> + dma_mask = dma_alloc_coherent_mask(dev, gfp);
> + order = get_order(size);
> +
> + gfp &= ~__GFP_ZERO;

Please add a comment around here that swiotlb_alloc_coherent() will
memset(, 0, ) the memory. It took me a while to figure out what the
situation is.

Also, Joerg says the __GFP_ZERO is not absolutely necessary but it has
not been fixed in the other DMA alloc* functions because of fears that
something would break. That bit could also be part of the comment.

> +
> + page = alloc_pages_node(dev_to_node(dev), gfp, order);
> + if (page) {
> + dma_addr_t addr;
> +
> + /*
> +  * Since we will be clearing the encryption bit, check the
> +  * mask with it already cleared.
> +  */
> + addr = phys_to_dma(dev, page_to_phys(page)) & ~sme_me_mask;
> + if ((addr + size) > dma_mask) {
> + __free_pages(page, get_order(size));
> + } else {
> + vaddr = page_address(page);
> + *dma_handle = addr;
> + }
> + }
> +
> + if (!vaddr)
> + vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
> +
> + if (!vaddr)
> + return NULL;
> +
> + /* Clear the SME encryption bit for DMA use if not swiotlb area */
> + if (!is_swiotlb_buffer(dma_to_phys(dev, *dma_handle))) {
> + set_memory_decrypted((unsigned long)vaddr, 1 << order);
> + *dma_handle &= ~sme_me_mask;
> + }
> +
> + return vaddr;
>  }
>  
> +static void sme_free(struct device *dev, size_t size, void *vaddr,
> +  dma_addr_t dma_handle, unsigned long attrs)
> +{
> + /* Set the SME encryption bit for re-use if not swiotlb area */
> + if (!is_swiotlb_buffer(dma_to_phys(dev, dma_handle)))
> + set_memory_encrypted((unsigned long)vaddr,
> +  1 << get_order(size));
> +
> + swiotlb_free_coherent(dev, size, vaddr, dma_handle);
> +}
> +
> +static struct dma_map_ops sme_dma_ops = {

WARNING: struct dma_map_ops should normally be const
#112: FILE: arch/x86/mm/mem_encrypt.c:261:
+static struct dma_map_ops sme_dma_ops = {

Please integrate scripts/checkpatch.pl in your patch creation workflow.
Some of the warnings/errors *actually* make sense.


> + .alloc  = sme_alloc,
> + .free   = sme_free,
> + .map_page   = swiotlb_map_page,
> + .unmap_page = swiotlb_unmap_page,
> + .map_sg = swiotlb_map_sg_attrs,
> + .unmap_sg   = swiotlb_unmap_sg_attrs,
> + .sync_single_for_cpu= swiotlb_sync_single_for_cpu,
> + .sync_single_for_device = swiotlb_sync_single_for_device,
> + .sync_sg_for_cpu= swiotlb_sync_sg_for_cpu,
> + .sync_sg_for_device = swiotlb_sync_sg_for_device,
> + .mapping_error  = swiotlb_dma_mapping_error,
> +};
> +
>  /* Architecture __weak replacement functions */
>  void __init mem_encrypt_init(void)
>  {
> @@ -208,6 +281,10 @@ void __init mem_encrypt_init(void)
>   /* Call into SWIOTLB to update the SWIOTLB DMA buffers */
>   swiotlb_update_mem_attributes();
>  
> + /* Use SEV DMA operations if SEV is active */

That's obvious. The WHY is not.

> + if (sev_active())
> + dma_ops = _dma_ops;
> +
>   pr_info("AMD Secure Memory Encryption (SME) active\n");
>  }
>  
> 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 


Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

2017-03-08 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Provide support for Secure Encyrpted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |   14 +-
>  arch/x86/mm/mem_encrypt.c  |3 +++
>  include/linux/mem_encrypt.h|6 ++
>  3 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/mem_encrypt.h 
> b/arch/x86/include/asm/mem_encrypt.h
> index 1fd5426..9799835 100644
> --- a/arch/x86/include/asm/mem_encrypt.h
> +++ b/arch/x86/include/asm/mem_encrypt.h
> @@ -20,10 +20,16 @@
>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>  
>  extern unsigned long sme_me_mask;
> +extern unsigned int sev_enabled;

So there's a function name sev_enabled() and an int sev_enabled too.

It looks to me like you want to call the function "sev_enable()" -
similar to sme_enable(), convert it to C code - i.e., I don't see what
would speak against it - and rename that sev_enc_bit to sev_enabled and
use it everywhere when testing SEV status.

>  static inline bool sme_active(void)
>  {
> - return (sme_me_mask) ? true : false;
> + return (sme_me_mask && !sev_enabled) ? true : false;
> +}
> +
> +static inline bool sev_active(void)
> +{
> + return (sme_me_mask && sev_enabled) ? true : false;

Then, those read strange: like SME and SEV are mutually exclusive. Why?
I might have an idea but I'd like for you to confirm it :-)

Then, you're calling sev_enabled in startup_32() but we can enter
in arch/x86/boot/compressed/head_64.S::startup_64() too, when we're
loaded by a 64-bit bootloader, which would then theoretically bypass
sev_enabled().

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 


Re: [PATCH] crypto: testmgr - don't DMA map IV from stack in test_skcipher()

2017-03-08 Thread Horia Geantă
On 1/13/2017 10:46 AM, Herbert Xu wrote:
> On Fri, Jan 13, 2017 at 08:59:16AM +0200, Horia Geantă wrote:
>> Fix the "DMA-API: device driver maps memory from stack" warning
>> generated when crypto accelerators map the IV.
>>
>> Signed-off-by: Horia Geantă 
> 
> Hmm, the IV comes in as a pointer.  So you should not assume that
> it can be DMAed at all.
> 
That's correct, thanks for pointing it out.

> Perhaps we should change the API so that it gets passed in as an
> SG list.
> 
Since changing the API and converting the users looks pretty lengthy,
would it be acceptable to fix tcrypt for now?
Indeed, I've missed updating test_skcipher_speed, I can add this in v2.

Thanks,
Horia



Re: [PATCH 9/9] crypto: mediatek - add support to OFB mode and CFB128 mode

2017-03-08 Thread Herbert Xu
On Mon, Feb 20, 2017 at 05:27:02PM +0800, Ryder Lee wrote:
> This patch adds support to OFB mode and CFB128 mode.
> 
> Signed-off-by: Ryder Lee 

In general we do not add any algorithms that

1) have no in-kernel users;
2) and/or have no software implementations.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 0/4] hwrng: omap - fixes and improvements

2017-03-08 Thread Romain Perier
Hello,


Le 07/03/2017 à 15:14, Thomas Petazzoni a écrit :
> Hello,
>
> This small patch series brings a few fixes and improvements to the
> omap_rng driver. The first fix is particularly important, as it fixes
> using the driver built as a module on SoCs that require a clock for
> the IP to work properly.
>
> Thanks,
>
> Thomas
>
> Thomas Petazzoni (4):
>   hwrng: omap - write registers after enabling the clock
>   hwrng: omap - use devm_clk_get() instead of of_clk_get()
>   hwrng: omap - Do not access INTMASK_REG on EIP76
>   hwrng: omap - move clock related code to omap_rng_probe()
>
>  drivers/char/hw_random/omap-rng.c | 36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)

For the whole series,

Reviewed-by: Romain Perier 



Re: [PATCH 5/8] crypto:chcr: Change cra_flags for cipher algos

2017-03-08 Thread Harsh Jain
Hi Herbert

On Fri, Jan 27, 2017 at 4:09 PM, Harsh Jain  wrote:
> Change cipher algos flags to CRYPTO_ALG_TYPE_ABLKCIPHER.
>
> Signed-off-by: Harsh Jain 
> ---
>  drivers/crypto/chelsio/chcr_algo.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/chelsio/chcr_algo.c 
> b/drivers/crypto/chelsio/chcr_algo.c
> index d335943..21fc04c 100644
> --- a/drivers/crypto/chelsio/chcr_algo.c
> +++ b/drivers/crypto/chelsio/chcr_algo.c
> @@ -171,7 +171,7 @@ int chcr_handle_resp(struct crypto_async_request *req, 
> unsigned char *input,
> }
> break;
>
> -   case CRYPTO_ALG_TYPE_BLKCIPHER:
> +   case CRYPTO_ALG_TYPE_ABLKCIPHER:
> ctx_req.req.ablk_req = (struct ablkcipher_request *)req;
> ctx_req.ctx.ablk_ctx =
> ablkcipher_request_ctx(ctx_req.req.ablk_req);
> @@ -2492,7 +2492,7 @@ static int chcr_aead_op(struct aead_request *req,
> .cra_name   = "cbc(aes)",
> .cra_driver_name= "cbc-aes-chcr",
> .cra_priority   = CHCR_CRA_PRIORITY,
> -   .cra_flags  = CRYPTO_ALG_TYPE_BLKCIPHER |
> +   .cra_flags  = CRYPTO_ALG_TYPE_ABLKCIPHER |
> CRYPTO_ALG_ASYNC,
> .cra_blocksize  = AES_BLOCK_SIZE,
> .cra_ctxsize= sizeof(struct chcr_context)
> @@ -2519,7 +2519,7 @@ static int chcr_aead_op(struct aead_request *req,
> .cra_name   = "xts(aes)",
> .cra_driver_name= "xts-aes-chcr",
> .cra_priority   = CHCR_CRA_PRIORITY,
> -   .cra_flags  = CRYPTO_ALG_TYPE_BLKCIPHER |
> +   .cra_flags  = CRYPTO_ALG_TYPE_ABLKCIPHER |
> CRYPTO_ALG_ASYNC,
> .cra_blocksize  = AES_BLOCK_SIZE,
> .cra_ctxsize= sizeof(struct chcr_context) 
> +

If I try above patch on 4.9.13 stable kernel. Kernel  stops executing
tests for cbc(aes), Same is working fine on cryptodev-2.6 latest tree.
It seems below patch set has changed the behavior.


crypto: testmgr - Do not test internal algorithms


diff --git a/crypto/algboss.c b/crypto/algboss.c
index 6e39d9c..ccb85e1 100644
--- a/crypto/algboss.c
+++ b/crypto/algboss.c
@@ -247,12 +247,8 @@ static int cryptomgr_schedule_test(struct crypto_alg *alg)
memcpy(param->alg, alg->cra_name, sizeof(param->alg));
type = alg->cra_flags;
- /* This piece of crap needs to disappear into per-type test hooks. */
- if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
- CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
- ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
- CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
- alg->cra_ablkcipher.ivsize))
+ /* Do not test internal algorithms. */
+ if (type & CRYPTO_ALG_INTERNAL)
type |= CRYPTO_ALG_TESTED;

Its bit confusing for me. Are we supposed to declared it as
"CRYPTO_ALG_TYPE_BLKCIPHER" for older kernels.

Regards
Harsh Jain


Re: [PATCH 5/8] crypto:chcr: Change cra_flags for cipher algos

2017-03-08 Thread Herbert Xu
On Wed, Mar 08, 2017 at 03:28:26PM +0530, Harsh Jain wrote:
>
> If I try above patch on 4.9.13 stable kernel. Kernel  stops executing
> tests for cbc(aes), Same is working fine on cryptodev-2.6 latest tree.
> It seems below patch set has changed the behavior.
> 
> 
> crypto: testmgr - Do not test internal algorithms

On older kernels each ablkcipher gets an geniv instantiated on top
of it.  Therefore the ablkcipher itself is never tested, only the
geniv is tested.

We have since got rid of the geniv and now test the ablkcipher
directly.

There was a period where we didn't generate a geniv but I forgot
to also remove the below chunk which skipped testing the ablkcipher.

> diff --git a/crypto/algboss.c b/crypto/algboss.c
> index 6e39d9c..ccb85e1 100644
> --- a/crypto/algboss.c
> +++ b/crypto/algboss.c
> @@ -247,12 +247,8 @@ static int cryptomgr_schedule_test(struct crypto_alg 
> *alg)
> memcpy(param->alg, alg->cra_name, sizeof(param->alg));
> type = alg->cra_flags;
> - /* This piece of crap needs to disappear into per-type test hooks. */
> - if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
> - CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
> - ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
> - CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
> - alg->cra_ablkcipher.ivsize))
> + /* Do not test internal algorithms. */
> + if (type & CRYPTO_ALG_INTERNAL)
> type |= CRYPTO_ALG_TESTED;
>
> Its bit confusing for me. Are we supposed to declared it as
> "CRYPTO_ALG_TYPE_BLKCIPHER" for older kernels.

It should definitely be ABLKCIPHER in your case.

Even if the test is skipped your driver should still work.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: powerpc - Fix initialisation of crc32c context

2017-03-08 Thread Herbert Xu
Daniel Axtens  wrote:
> Turning on crypto self-tests on a POWER8 shows:
> 
>alg: hash: Test 1 failed for crc32c-vpmsum
>: ff ff ff ff
> 
> Comparing the code with the Intel CRC32c implementation on which
> ours is based shows that we are doing an init with 0, not ~0
> as CRC32c requires.
> 
> This probably wasn't caught because btrfs does its own weird
> open-coded initialisation.
> 
> Initialise our internal context to ~0 on init.
> 
> This makes the self-tests pass, and btrfs continues to work.
> 
> Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
> Cc: Anton Blanchard 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Axtens 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] crypto: s5p-sss - Fix completing crypto request in IRQ handler

2017-03-08 Thread Herbert Xu
On Sun, Mar 05, 2017 at 07:14:07PM +0200, Krzysztof Kozlowski wrote:
> In a regular interrupt handler driver was finishing the crypt/decrypt
> request by calling complete on crypto request.  This is disallowed since
> converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add
> skcipher walk interface") and causes a warning:
>   WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 
> skcipher_walk_first+0x13c/0x14c
> 
> The interrupt is marked shared but in fact there are no other users
> sharing it.  Thus the simplest solution seems to be to just use a
> threaded interrupt handler, after converting it to oneshot.
> 
> Signed-off-by: Krzysztof Kozlowski 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data

2017-03-08 Thread Borislav Petkov
On Thu, Mar 02, 2017 at 10:13:53AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> In order to map BOOT data with the proper encryption bit, the

Btw, what does that all-caps spelling "BOOT" denote? Something I'm
missing?

> early_ioremap() function calls are changed to early_memremap() calls.
> This allows the proper access for both SME and SEV.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/kernel/acpi/boot.c |4 ++--
>  arch/x86/kernel/mpparse.c   |   10 +-
>  drivers/sfi/sfi_core.c  |6 +++---
>  3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 35174c6..468c25a 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -124,7 +124,7 @@ char *__init __acpi_map_table(unsigned long phys, 
> unsigned long size)
>   if (!phys || !size)
>   return NULL;
>  
> - return early_ioremap(phys, size);
> + return early_memremap(phys, size);

Right, the question will keep popping up why we can simply replace
memremap with ioremap and the general difference wrt to SME/SEV. So it
would be a good idea to have a comment in, say, arch/x86/mm/ioremap.c,
explaining the general situation.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 


hmac(crc32)

2017-03-08 Thread Stephan Müller
Hi Herbert,

hmac(crc32) is defined in testmgr.c and tcrypt.c. Yet, when using that cipher, 
I get an ENOENT:

alg: hash: Failed to load transform for hmac(crc32): -2


Is there such a thing as hmac(crc32)?

Ciao
Stephan