* Re: [PATCH 5/7] crypto: marvell: Adding a complete operation for async requests
From: Boris Brezillon @ 2016-06-15 20:55 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <1466018134-10779-6-git-send-email-romain.perier@free-electrons.com>
On Wed, 15 Jun 2016 21:15:32 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> So far, the 'process' operation was used to check if the current request
> was correctly handled by the engine, if it was the case it copied
> information from the SRAM to the main memory. Now, we split this
> operation. We keep the 'process' operation, which still checks if the
> request was correctly handled by the engine or not, then we add a new
> operation for completion. The 'complete' method copies the content of
> the SRAM to memory. This will soon become useful if we want to call
> the process and the complete operations from different locations
> depending on the type of the request (different cleanup logic).
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> drivers/crypto/marvell/cesa.c | 1 +
> drivers/crypto/marvell/cesa.h | 3 +++
> drivers/crypto/marvell/cipher.c | 47 ++++++++++++++++++++++++-----------------
> drivers/crypto/marvell/hash.c | 22 ++++++++++---------
> 4 files changed, 44 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index fe04d1b..af96426 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -98,6 +98,7 @@ static irqreturn_t mv_cesa_int(int irq, void *priv)
> engine->req = NULL;
> mv_cesa_dequeue_req_unlocked(engine);
> spin_unlock_bh(&engine->lock);
> + ctx->ops->complete(req);
> ctx->ops->cleanup(req);
> local_bh_disable();
> req->complete(req, res);
> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
> index 158ff82..32de08b 100644
> --- a/drivers/crypto/marvell/cesa.h
> +++ b/drivers/crypto/marvell/cesa.h
> @@ -456,6 +456,8 @@ struct mv_cesa_engine {
> * code)
> * @step: launch the crypto operation on the next chunk
> * @cleanup: cleanup the crypto request (release associated data)
> + * @complete: complete the request, i.e copy result from sram or contexts
> + * when it is needed.
> */
> struct mv_cesa_req_ops {
> void (*prepare)(struct crypto_async_request *req,
> @@ -463,6 +465,7 @@ struct mv_cesa_req_ops {
> int (*process)(struct crypto_async_request *req, u32 status);
> void (*step)(struct crypto_async_request *req);
> void (*cleanup)(struct crypto_async_request *req);
> + void (*complete)(struct crypto_async_request *req);
> };
>
> /**
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 15d2c5a..fbaae2f 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -118,7 +118,6 @@ static int mv_cesa_ablkcipher_std_process(struct ablkcipher_request *req,
> struct mv_cesa_ablkcipher_std_req *sreq = &creq->req.std;
> struct mv_cesa_engine *engine = sreq->base.engine;
> size_t len;
> - unsigned int ivsize;
>
> len = sg_pcopy_from_buffer(req->dst, creq->dst_nents,
> engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> @@ -128,10 +127,6 @@ static int mv_cesa_ablkcipher_std_process(struct ablkcipher_request *req,
> if (sreq->offset < req->nbytes)
> return -EINPROGRESS;
>
> - ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req));
> - memcpy_fromio(req->info,
> - engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET, ivsize);
> -
> return 0;
> }
>
> @@ -141,21 +136,9 @@ static int mv_cesa_ablkcipher_process(struct crypto_async_request *req,
> struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
>
> - if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ) {
> - int ret;
> - struct mv_cesa_req *basereq;
> - unsigned int ivsize;
> -
> - ret = mv_cesa_dma_process(&creq->req.base, status);
> - if (ret)
> - return ret;
> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
> + return mv_cesa_dma_process(&creq->req.base, status);
>
> - basereq = &creq->req.base;
> - ivsize = crypto_ablkcipher_ivsize(
> - crypto_ablkcipher_reqtfm(ablkreq));
> - memcpy_fromio(ablkreq->info, basereq->chain.last->data, ivsize);
> - return ret;
> - }
> return mv_cesa_ablkcipher_std_process(ablkreq, status);
> }
>
> @@ -197,6 +180,7 @@ static inline void mv_cesa_ablkcipher_prepare(struct crypto_async_request *req,
> {
> struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
> +
Nit: not sure you should mix this cosmetic change with the other
changes.
> creq->req.base.engine = engine;
>
> if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
> @@ -213,11 +197,36 @@ mv_cesa_ablkcipher_req_cleanup(struct crypto_async_request *req)
> mv_cesa_ablkcipher_cleanup(ablkreq);
> }
>
> +static void
> +mv_cesa_ablkcipher_complete(struct crypto_async_request *req)
> +{
> + struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
> + struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
> + struct mv_cesa_engine *engine = creq->req.base.engine;
> + unsigned int ivsize;
> +
> + ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq));
> +
> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ) {
> + struct mv_cesa_req *basereq;
> +
> + basereq = &creq->req.base;
> + ivsize = crypto_ablkcipher_ivsize(
> + crypto_ablkcipher_reqtfm(ablkreq));
You already have ivsize initialized.
> + memcpy_fromio(ablkreq->info, basereq->chain.last->data, ivsize);
Use memcpy() here.
> + } else {
> + memcpy_fromio(ablkreq->info,
> + engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
> + ivsize);
> + }
> +}
> +
> static const struct mv_cesa_req_ops mv_cesa_ablkcipher_req_ops = {
> .step = mv_cesa_ablkcipher_step,
> .process = mv_cesa_ablkcipher_process,
> .prepare = mv_cesa_ablkcipher_prepare,
> .cleanup = mv_cesa_ablkcipher_req_cleanup,
> + .complete = mv_cesa_ablkcipher_complete,
> };
>
> static int mv_cesa_ablkcipher_cra_init(struct crypto_tfm *tfm)
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index cc7c5b0..f7f84cc 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -287,17 +287,20 @@ static int mv_cesa_ahash_process(struct crypto_async_request *req, u32 status)
> {
> struct ahash_request *ahashreq = ahash_request_cast(req);
> struct mv_cesa_ahash_req *creq = ahash_request_ctx(ahashreq);
> - struct mv_cesa_engine *engine = creq->req.base.engine;
> - unsigned int digsize;
> - int ret, i;
>
> if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
> - ret = mv_cesa_dma_process(&creq->req.base, status);
> - else
> - ret = mv_cesa_ahash_std_process(ahashreq, status);
> + return mv_cesa_dma_process(&creq->req.base, status);
>
> - if (ret == -EINPROGRESS)
> - return ret;
> + return mv_cesa_ahash_std_process(ahashreq, status);
> +}
> +
> +static void mv_cesa_ahash_complete(struct crypto_async_request *req)
> +{
> + struct ahash_request *ahashreq = ahash_request_cast(req);
> + struct mv_cesa_ahash_req *creq = ahash_request_ctx(ahashreq);
> + struct mv_cesa_engine *engine = creq->req.base.engine;
> + unsigned int digsize;
> + int i;
>
> digsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(ahashreq));
> for (i = 0; i < digsize / 4; i++)
> @@ -326,8 +329,6 @@ static int mv_cesa_ahash_process(struct crypto_async_request *req, u32 status)
> result[i] = cpu_to_be32(creq->state[i]);
> }
> }
> -
> - return ret;
> }
>
> static void mv_cesa_ahash_prepare(struct crypto_async_request *req,
> @@ -366,6 +367,7 @@ static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops = {
> .process = mv_cesa_ahash_process,
> .prepare = mv_cesa_ahash_prepare,
> .cleanup = mv_cesa_ahash_req_cleanup,
> + .complete = mv_cesa_ahash_complete,
> };
>
> static int mv_cesa_ahash_init(struct ahash_request *req,
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 6/7] crypto: marvell: Adding load balancing between engines
From: Boris Brezillon @ 2016-06-15 21:13 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <1466018134-10779-7-git-send-email-romain.perier@free-electrons.com>
On Wed, 15 Jun 2016 21:15:33 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> This commits adds support for fine grained load balancing on
> multi-engine IPs. The engine is pre-selected based on its current load
> and on the weight of the crypto request that is about to be processed.
> The global crypto queue is also moved to each engine. These changes are
to the mv_cesa_engine object.
> useful for preparing the code to support TDMA chaining between crypto
> requests, because each tdma chain will be handled per engine.
These changes are required to allow chaining crypto requests at the DMA
level.
> By using
> a crypto queue per engine, we make sure that we keep the state of the
> tdma chain synchronized with the crypto queue. We also reduce contention
> on 'cesa_dev->lock' and improve parallelism.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> drivers/crypto/marvell/cesa.c | 30 +++++++++----------
> drivers/crypto/marvell/cesa.h | 26 +++++++++++++++--
> drivers/crypto/marvell/cipher.c | 59 ++++++++++++++++++-------------------
> drivers/crypto/marvell/hash.c | 65 +++++++++++++++++++----------------------
> 4 files changed, 97 insertions(+), 83 deletions(-)
>
[...]
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index fbaae2f..02aa38f 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -89,6 +89,9 @@ static void mv_cesa_ablkcipher_std_step(struct ablkcipher_request *req)
> size_t len = min_t(size_t, req->nbytes - sreq->offset,
> CESA_SA_SRAM_PAYLOAD_SIZE);
>
> + mv_cesa_adjust_op(engine, &sreq->op);
> + memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op));
> +
> len = sg_pcopy_to_buffer(req->src, creq->src_nents,
> engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> len, sreq->offset);
> @@ -167,12 +170,9 @@ mv_cesa_ablkcipher_std_prepare(struct ablkcipher_request *req)
> {
> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(req);
> struct mv_cesa_ablkcipher_std_req *sreq = &creq->req.std;
> - struct mv_cesa_engine *engine = sreq->base.engine;
>
> sreq->size = 0;
> sreq->offset = 0;
> - mv_cesa_adjust_op(engine, &sreq->op);
> - memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op));
Are these changes really related to this load balancing support?
AFAICT, it's something that could have been done earlier, and is not
dependent on the changes your introducing here, but maybe I'm missing
something.
> }
[...]
> static int mv_cesa_ecb_aes_encrypt(struct ablkcipher_request *req)
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index f7f84cc..5946a69 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -162,6 +162,15 @@ static void mv_cesa_ahash_std_step(struct ahash_request *req)
> unsigned int new_cache_ptr = 0;
> u32 frag_mode;
> size_t len;
> + unsigned int digsize;
> + int i;
> +
> + mv_cesa_adjust_op(engine, &creq->op_tmpl);
> + memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
> +
> + digsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(req));
> + for (i = 0; i < digsize / 4; i++)
> + writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
>
> if (creq->cache_ptr)
> memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> @@ -265,11 +274,8 @@ static void mv_cesa_ahash_std_prepare(struct ahash_request *req)
> {
> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
> struct mv_cesa_ahash_std_req *sreq = &creq->req.std;
> - struct mv_cesa_engine *engine = sreq->base.engine;
>
> sreq->offset = 0;
> - mv_cesa_adjust_op(engine, &creq->op_tmpl);
> - memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
Same as above: it doesn't seem related to the load balancing stuff.
> }
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 7/7] crypto: marvell: Add support for chaining crypto requests in TDMA mode
From: Boris Brezillon @ 2016-06-15 21:43 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <1466018134-10779-8-git-send-email-romain.perier@free-electrons.com>
On Wed, 15 Jun 2016 21:15:34 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> The Cryptographic Engines and Security Accelerators (CESA) supports the
> Multi-Packet Chain Mode. With this mode enabled, multiple tdma requests
> can be chained and processed by the hardware without software
> interferences.
intervention.
> This mode was already activated, however the crypto
> requests were not chained together. By doing so, we reduce significantly
significantly reduce
> the number of IRQs. Instead of being interrupted at the end of each
> crypto request, we are interrupted at the end of the last cryptographic
> request processed by the engine.
>
> This commits re-factorizes the code, changes the code architecture and
> adds the required data structures to chain cryptographic requests
> together before sending them to an engine.
Not necessarily before sending them to the engine, it can be done while
the engine is running.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> drivers/crypto/marvell/cesa.c | 117 +++++++++++++++++++++++++++++++---------
> drivers/crypto/marvell/cesa.h | 38 ++++++++++++-
> drivers/crypto/marvell/cipher.c | 3 +-
> drivers/crypto/marvell/hash.c | 9 +++-
> drivers/crypto/marvell/tdma.c | 81 ++++++++++++++++++++++++++++
> 5 files changed, 218 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index f9e6688..33411f6 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -32,7 +32,7 @@
> #include "cesa.h"
>
> /* Limit of the crypto queue before reaching the backlog */
> -#define CESA_CRYPTO_DEFAULT_MAX_QLEN 50
> +#define CESA_CRYPTO_DEFAULT_MAX_QLEN 128
>
> static int allhwsupport = !IS_ENABLED(CONFIG_CRYPTO_DEV_MV_CESA);
> module_param_named(allhwsupport, allhwsupport, int, 0444);
> @@ -40,23 +40,83 @@ MODULE_PARM_DESC(allhwsupport, "Enable support for all hardware (even it if over
>
> struct mv_cesa_dev *cesa_dev;
>
> -static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
> +struct crypto_async_request *mv_cesa_dequeue_req_locked(
> + struct mv_cesa_engine *engine, struct crypto_async_request **backlog)
Coding style issue:
struct crypto_async_request *
mv_cesa_dequeue_req_locked(struct mv_cesa_engine *engine,
struct crypto_async_request **backlog)
> +{
> + struct crypto_async_request *req;
> +
> + *backlog = crypto_get_backlog(&engine->queue);
> + req = crypto_dequeue_request(&engine->queue);
> +
> + if (!req)
> + return NULL;
> +
> + return req;
> +}
> +
> +static void mv_cesa_rearm_engine(struct mv_cesa_engine *engine)
> {
> struct crypto_async_request *req, *backlog;
> struct mv_cesa_ctx *ctx;
>
> - backlog = crypto_get_backlog(&engine->queue);
> - req = crypto_dequeue_request(&engine->queue);
> - engine->req = req;
>
> + spin_lock_bh(&engine->lock);
> + if (engine->req)
> + goto out_unlock;
> +
> + req = mv_cesa_dequeue_req_locked(engine, &backlog);
> if (!req)
> - return;
> + goto out_unlock;
> +
> + engine->req = req;
> + spin_unlock_bh(&engine->lock);
I'm not a big fan of those multiple 'unlock() locations', and since
your code is pretty simple I'd prefer seeing something like.
spin_lock_bh(&engine->lock);
if (!engine->req) {
req = mv_cesa_dequeue_req_locked(engine, &backlog);
engine->req = req;
}
spin_unlock_bh(&engine->lock);
if (!req)
return;
With req and backlog initialized to NULL at the beginning of the
function.
>
> if (backlog)
> backlog->complete(backlog, -EINPROGRESS);
>
> ctx = crypto_tfm_ctx(req->tfm);
> ctx->ops->step(req);
> + return;
Missing blank line.
> +out_unlock:
> + spin_unlock_bh(&engine->lock);
> +}
> +
> +static int mv_cesa_std_process(struct mv_cesa_engine *engine, u32 status)
> +{
> + struct crypto_async_request *req;
> + struct mv_cesa_ctx *ctx;
> + int res;
> +
> + req = engine->req;
> + ctx = crypto_tfm_ctx(req->tfm);
> + res = ctx->ops->process(req, status);
> +
> + if (res == 0) {
> + ctx->ops->complete(req);
> + mv_cesa_engine_enqueue_complete_request(engine, req);
> + } else if (res == -EINPROGRESS) {
> + ctx->ops->step(req);
> + } else {
> + ctx->ops->complete(req);
Do we really have to call ->complete() in this case?
> + }
> +
> + return res;
> +}
> +
> +static int mv_cesa_int_process(struct mv_cesa_engine *engine, u32 status)
> +{
> + if (engine->chain.first && engine->chain.last)
> + return mv_cesa_tdma_process(engine, status);
Missing blank line.
> + return mv_cesa_std_process(engine, status);
> +}
> +
> +static inline void mv_cesa_complete_req(struct mv_cesa_ctx *ctx,
> + struct crypto_async_request *req, int res)
Align parameters to the open parenthesis.
> +{
> + ctx->ops->cleanup(req);
> + local_bh_disable();
> + req->complete(req, res);
> + local_bh_enable();
> }
>
> static irqreturn_t mv_cesa_int(int irq, void *priv)
> @@ -83,26 +143,31 @@ static irqreturn_t mv_cesa_int(int irq, void *priv)
> writel(~status, engine->regs + CESA_SA_FPGA_INT_STATUS);
> writel(~status, engine->regs + CESA_SA_INT_STATUS);
>
> + /* Process fetched requests */
> + res = mv_cesa_int_process(engine, status & mask);
> ret = IRQ_HANDLED;
> +
> spin_lock_bh(&engine->lock);
> req = engine->req;
> + if (res != -EINPROGRESS)
> + engine->req = NULL;
> spin_unlock_bh(&engine->lock);
> - if (req) {
> - ctx = crypto_tfm_ctx(req->tfm);
> - res = ctx->ops->process(req, status & mask);
> - if (res != -EINPROGRESS) {
> - spin_lock_bh(&engine->lock);
> - engine->req = NULL;
> - mv_cesa_dequeue_req_unlocked(engine);
> - spin_unlock_bh(&engine->lock);
> - ctx->ops->complete(req);
> - ctx->ops->cleanup(req);
> - local_bh_disable();
> - req->complete(req, res);
> - local_bh_enable();
> - } else {
> - ctx->ops->step(req);
> - }
> +
> + ctx = crypto_tfm_ctx(req->tfm);
> +
> + if (res && res != -EINPROGRESS)
> + mv_cesa_complete_req(ctx, req, res);
> +
> + /* Launch the next pending request */
> + mv_cesa_rearm_engine(engine);
> +
> + /* Iterate over the complete queue */
> + while (true) {
> + req = mv_cesa_engine_dequeue_complete_request(engine);
> + if (!req)
> + break;
> +
> + mv_cesa_complete_req(ctx, req, 0);
> }
> }
>
> @@ -116,16 +181,15 @@ int mv_cesa_queue_req(struct crypto_async_request *req,
> struct mv_cesa_engine *engine = creq->engine;
>
> spin_lock_bh(&engine->lock);
> + if (mv_cesa_req_get_type(creq) == CESA_DMA_REQ)
> + mv_cesa_tdma_chain(engine, creq);
Missing blank line.
> ret = crypto_enqueue_request(&engine->queue, req);
> spin_unlock_bh(&engine->lock);
>
> if (ret != -EINPROGRESS)
> return ret;
>
> - spin_lock_bh(&engine->lock);
> - if (!engine->req)
> - mv_cesa_dequeue_req_unlocked(engine);
> - spin_unlock_bh(&engine->lock);
> + mv_cesa_rearm_engine(engine);
>
> return -EINPROGRESS;
> }
> @@ -496,6 +560,7 @@ static int mv_cesa_probe(struct platform_device *pdev)
>
> crypto_init_queue(&engine->queue, CESA_CRYPTO_DEFAULT_MAX_QLEN);
> atomic_set(&engine->load, 0);
> + INIT_LIST_HEAD(&engine->complete_queue);
> }
>
> cesa_dev = cesa;
> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
> index 5626aa7..e0fee1f 100644
> --- a/drivers/crypto/marvell/cesa.h
> +++ b/drivers/crypto/marvell/cesa.h
> @@ -271,7 +271,9 @@ struct mv_cesa_op_ctx {
> /* TDMA descriptor flags */
> #define CESA_TDMA_DST_IN_SRAM BIT(31)
> #define CESA_TDMA_SRC_IN_SRAM BIT(30)
> -#define CESA_TDMA_TYPE_MSK GENMASK(29, 0)
> +#define CESA_TDMA_END_OF_REQ BIT(29)
> +#define CESA_TDMA_NOT_CHAIN BIT(28)
I would name it CESA_TDMA_BREAK_CHAIN.
> +#define CESA_TDMA_TYPE_MSK GENMASK(27, 0)
> #define CESA_TDMA_DUMMY 0
> #define CESA_TDMA_DATA 1
> #define CESA_TDMA_OP 2
> @@ -431,6 +433,9 @@ struct mv_cesa_dev {
> * SRAM
> * @queue: fifo of the pending crypto requests
> * @load: engine load counter, useful for load balancing
> + * @chain: list of the current tdma descriptors being processed
> + * by this engine.
> + * @complete_queue: fifo of the processed requests by the engine
> *
> * Structure storing CESA engine information.
> */
> @@ -448,6 +453,8 @@ struct mv_cesa_engine {
> struct gen_pool *pool;
> struct crypto_queue queue;
> atomic_t load;
> + struct mv_cesa_tdma_chain chain;
> + struct list_head complete_queue;
> };
>
> /**
> @@ -618,6 +625,28 @@ struct mv_cesa_ahash_req {
>
> extern struct mv_cesa_dev *cesa_dev;
>
> +
> +static inline void mv_cesa_engine_enqueue_complete_request(
> + struct mv_cesa_engine *engine, struct crypto_async_request *req)
Coding style issue (see my previous comments).
> +{
> + list_add_tail(&req->list, &engine->complete_queue);
> +}
> +
> +static inline struct crypto_async_request *
> +mv_cesa_engine_dequeue_complete_request(struct mv_cesa_engine *engine)
> +{
> + struct crypto_async_request *req;
> +
> + req = list_first_entry_or_null(&engine->complete_queue,
> + struct crypto_async_request,
> + list);
> + if (req)
> + list_del(&req->list);
> +
> + return req;
> +}
> +
> +
> static inline enum mv_cesa_req_type
> mv_cesa_req_get_type(struct mv_cesa_req *req)
> {
> @@ -699,6 +728,10 @@ static inline bool mv_cesa_mac_op_is_first_frag(const struct mv_cesa_op_ctx *op)
> int mv_cesa_queue_req(struct crypto_async_request *req,
> struct mv_cesa_req *creq);
>
> +struct crypto_async_request *mv_cesa_dequeue_req_locked(
> + struct mv_cesa_engine *engine,
> + struct crypto_async_request **backlog);
Ditto.
> +
> static inline struct mv_cesa_engine *mv_cesa_select_engine(int weight)
> {
> int i;
> @@ -804,6 +837,9 @@ static inline int mv_cesa_dma_process(struct mv_cesa_req *dreq,
> void mv_cesa_dma_prepare(struct mv_cesa_req *dreq,
> struct mv_cesa_engine *engine);
> void mv_cesa_dma_cleanup(struct mv_cesa_req *dreq);
> +void mv_cesa_tdma_chain(struct mv_cesa_engine *engine,
> + struct mv_cesa_req *dreq);
> +int mv_cesa_tdma_process(struct mv_cesa_engine *engine, u32 status);
>
>
> static inline void
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 02aa38f..9033191 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -225,7 +225,6 @@ mv_cesa_ablkcipher_complete(struct crypto_async_request *req)
> static const struct mv_cesa_req_ops mv_cesa_ablkcipher_req_ops = {
> .step = mv_cesa_ablkcipher_step,
> .process = mv_cesa_ablkcipher_process,
> - .prepare = mv_cesa_ablkcipher_prepare,
> .cleanup = mv_cesa_ablkcipher_req_cleanup,
> .complete = mv_cesa_ablkcipher_complete,
> };
> @@ -384,6 +383,7 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
> goto err_free_tdma;
>
> dreq->chain = chain;
> + dreq->chain.last->flags |= CESA_TDMA_END_OF_REQ;
>
> return 0;
>
> @@ -441,7 +441,6 @@ static int mv_cesa_ablkcipher_req_init(struct ablkcipher_request *req,
> mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_OP_CRYPT_ONLY,
> CESA_SA_DESC_CFG_OP_MSK);
>
> - /* TODO: add a threshold for DMA usage */
> if (cesa_dev->caps->has_tdma)
> ret = mv_cesa_ablkcipher_dma_req_init(req, tmpl);
> else
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index 5946a69..c2ff353 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -172,6 +172,9 @@ static void mv_cesa_ahash_std_step(struct ahash_request *req)
> for (i = 0; i < digsize / 4; i++)
> writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
>
> + mv_cesa_adjust_op(engine, &creq->op_tmpl);
> + memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
> +
> if (creq->cache_ptr)
> memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> creq->cache, creq->cache_ptr);
> @@ -282,6 +285,9 @@ static void mv_cesa_ahash_step(struct crypto_async_request *req)
> {
> struct ahash_request *ahashreq = ahash_request_cast(req);
> struct mv_cesa_ahash_req *creq = ahash_request_ctx(ahashreq);
> + struct mv_cesa_engine *engine = creq->req.base.engine;
> + unsigned int digsize;
> + int i;
>
> if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
> mv_cesa_dma_step(&creq->req.base);
> @@ -367,7 +373,6 @@ static void mv_cesa_ahash_req_cleanup(struct crypto_async_request *req)
> static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops = {
> .step = mv_cesa_ahash_step,
> .process = mv_cesa_ahash_process,
> - .prepare = mv_cesa_ahash_prepare,
Why are you doing that?
> .cleanup = mv_cesa_ahash_req_cleanup,
> .complete = mv_cesa_ahash_complete,
> };
> @@ -648,6 +653,8 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req)
> else
> creq->cache_ptr = 0;
>
> + dreq->chain.last->flags |= (CESA_TDMA_END_OF_REQ | CESA_TDMA_NOT_CHAIN);
> +
> return 0;
>
> err_free_tdma:
> diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c
> index 9a424f9..ae50545 100644
> --- a/drivers/crypto/marvell/tdma.c
> +++ b/drivers/crypto/marvell/tdma.c
> @@ -98,6 +98,87 @@ void mv_cesa_dma_prepare(struct mv_cesa_req *dreq,
> }
> }
>
> +void
> +mv_cesa_tdma_chain(struct mv_cesa_engine *engine, struct mv_cesa_req *dreq)
> +{
> + if (engine->chain.first == NULL && engine->chain.last == NULL) {
> + engine->chain.first = dreq->chain.first;
> + engine->chain.last = dreq->chain.last;
> + } else {
> + struct mv_cesa_tdma_desc *last;
> +
> + last = engine->chain.last;
> + last->next = dreq->chain.first;
> + engine->chain.last = dreq->chain.last;
Missing blank line.
> + if (!(last->flags & CESA_TDMA_NOT_CHAIN))
> + last->next_dma = dreq->chain.first->cur_dma;
> + }
> +}
> +
> +int
> +mv_cesa_tdma_process(struct mv_cesa_engine *engine, u32 status)
> +{
> + struct crypto_async_request *req = NULL;
> + struct mv_cesa_tdma_desc *tdma = NULL, *next = NULL;
> + dma_addr_t tdma_cur;
> + int res = 0;
> +
> + tdma_cur = readl(engine->regs + CESA_TDMA_CUR);
> +
> + for (tdma = engine->chain.first; tdma; tdma = next) {
> + spin_lock_bh(&engine->lock);
> + next = tdma->next;
> + spin_unlock_bh(&engine->lock);
> +
> + if (tdma->flags & CESA_TDMA_END_OF_REQ) {
> + struct crypto_async_request *backlog = NULL;
> + struct mv_cesa_ctx *ctx;
> +
> + spin_lock_bh(&engine->lock);
> + /*
> + * if req is NULL, this means we're processing the
> + * request in engine->req.
> + */
> + if (!req)
> + req = engine->req;
> + else
> + req = mv_cesa_dequeue_req_locked(engine,
> + &backlog);
> +
> + /* Re-chaining to the next request */
> + engine->chain.first = tdma->next;
> + tdma->next = NULL;
> +
> + /* If this is the last request, clear the chain */
> + if (engine->chain.first == NULL)
> + engine->chain.last = NULL;
> + spin_unlock_bh(&engine->lock);
> +
> + ctx = crypto_tfm_ctx(req->tfm);
> + res = ctx->ops->process(req, status);
Hm, that's not exactly true. The status you're passing here is only
valid for the last request that has been processed. Say you queued 3
requests. 2 of them were correctly processed, but the last one
triggered an error. You don't want the first 2 requests to be
considered bad.
A solution would be to pass a 'fake' valid status, until we reach the
last request (IOW, tdma->cur_dma == tdma_cur).
> + ctx->ops->complete(req);
> +
> + if (res == 0)
> + mv_cesa_engine_enqueue_complete_request(engine,
> + req);
> +
> + if (backlog)
> + backlog->complete(backlog, -EINPROGRESS);
> + }
Missing blank line.
> + if (res || tdma->cur_dma == tdma_cur)
> + break;
> + }
> +
> + if (res) {
> + spin_lock_bh(&engine->lock);
> + engine->req = req;
> + spin_unlock_bh(&engine->lock);
> + }
Maybe you can add a comment explaining that you are actually setting
the last processed request into engine->req, so that the core can know
which request was faulty.
> +
> + return res;
> +}
> +
> +
> static struct mv_cesa_tdma_desc *
> mv_cesa_dma_add_desc(struct mv_cesa_tdma_chain *chain, gfp_t flags)
> {
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
From: Stephan Mueller @ 2016-06-16 8:05 UTC (permalink / raw)
To: Andrew Zaborowski
Cc: Mat Martineau, Tadeusz Struk, David Howells, Herbert Xu,
linux-api, marcel, linux-kernel, keyrings,
Linux Crypto Mailing List, David Woodhouse, davem
In-Reply-To: <CAOq732+ZyjD2Wv3Pt7x+jfurvgVq5pcUA--+G6VQM5t861n-fQ@mail.gmail.com>
Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski:
Hi Andrew,
> >
> > I think we have agreed on dropping the length enforcement at the interface
> > level.
>
> Separately from this there's a problem with the user being unable to
> know if the algorithm is going to fail because of destination buffer
> size != key size (including kernel users). For RSA, the qat
> implementation will fail while the software implementation won't. For
> pkcs1pad(...) there's currently just one implementation but the user
> can't assume that.
If I understand your issue correctly, my initial code requiring the caller to
provide sufficient memory would have covered the issue, right? If so, we seem
to have implementations which can handle shorter buffer sizes and some which
do not. Should a caller really try to figure the right buffer size out? Why
not requiring a mandatory buffer size and be done with it? I.e. what is the
gain to allow shorter buffer sizes (as pointed out by Mat)? So, bottom line, I
am wondering whether we should keep the algif_akcipher code to require a
minimum buffer size.
If there is really a good argument to allow shorter buffers, then I guess we
need an in-kernel API call (which should be reported to user space) which
gives us the smallest usable buffer size. I guess that call would only be
valid after a setkey operation as the output size depends on the key size.
Instead of inventing a complete new API call, shouldn't the call
crypto_akcipher_maxsize() be converted for this purpose? I requested that API
call during the time the akcipher API was developed explicitly for getting the
minimum buffer size the caller needs to provide.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/7] crypto: marvell: Check engine is not already running when enabling a req
From: Romain Perier @ 2016-06-16 8:18 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <20160615213709.3a060ff4@bbrezillon>
Hello,
Le 15/06/2016 21:37, Boris Brezillon a écrit :
>
> "
> Add a BUG_ON() call when the driver tries to launch a crypto request
> while the engine is still processing the previous one. This replaces
> a silent system hang by a verbose kernel panic with the associated
> backtrace to let the user know that something went wrong in the CESA
> driver.
> "
thanks
>
>> ---
>> drivers/crypto/marvell/cipher.c | 2 ++
>> drivers/crypto/marvell/hash.c | 2 ++
>> drivers/crypto/marvell/tdma.c | 2 ++
>> 3 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
>> index dcf1fce..8d0fabb 100644
>> --- a/drivers/crypto/marvell/cipher.c
>> +++ b/drivers/crypto/marvell/cipher.c
>> @@ -106,6 +106,8 @@ static void mv_cesa_ablkcipher_std_step(struct ablkcipher_request *req)
>>
>> mv_cesa_set_int_mask(engine, CESA_SA_INT_ACCEL0_DONE);
>> writel_relaxed(CESA_SA_CFG_PARA_DIS, engine->regs + CESA_SA_CFG);
>> + BUG_ON(readl(engine->regs + CESA_SA_CMD)
>> + & CESA_SA_CMD_EN_CESA_SA_ACCL0);
>
> Nit: please put the '&' operator at the end of the first line and
> align CESA_SA_CMD_EN_CESA_SA_ACCL0 on the open parenthesis.
Arf, ok I will fix this.
>
> BUG_ON(readl(engine->regs + CESA_SA_CMD) &
> CESA_SA_CMD_EN_CESA_SA_ACCL0);
>
>> writel(CESA_SA_CMD_EN_CESA_SA_ACCL0, engine->regs + CESA_SA_CMD);
>> }
>>
>> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
>> index 7ca2e0f..0fae351 100644
>> --- a/drivers/crypto/marvell/hash.c
>> +++ b/drivers/crypto/marvell/hash.c
>> @@ -237,6 +237,8 @@ static void mv_cesa_ahash_std_step(struct ahash_request *req)
>>
>> mv_cesa_set_int_mask(engine, CESA_SA_INT_ACCEL0_DONE);
>> writel_relaxed(CESA_SA_CFG_PARA_DIS, engine->regs + CESA_SA_CFG);
>> + BUG_ON(readl(engine->regs + CESA_SA_CMD)
>> + & CESA_SA_CMD_EN_CESA_SA_ACCL0);
>
> Ditto.
ack
>
>> writel(CESA_SA_CMD_EN_CESA_SA_ACCL0, engine->regs + CESA_SA_CMD);
>> }
>>
>> diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c
>> index 7642798..d493714 100644
>> --- a/drivers/crypto/marvell/tdma.c
>> +++ b/drivers/crypto/marvell/tdma.c
>> @@ -53,6 +53,8 @@ void mv_cesa_dma_step(struct mv_cesa_tdma_req *dreq)
>> engine->regs + CESA_SA_CFG);
>> writel_relaxed(dreq->chain.first->cur_dma,
>> engine->regs + CESA_TDMA_NEXT_ADDR);
>> + BUG_ON(readl(engine->regs + CESA_SA_CMD)
>> + & CESA_SA_CMD_EN_CESA_SA_ACCL0);
>
> Ditto.
ack
Regards,
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests
From: Romain Perier @ 2016-06-16 8:29 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <20160615220716.6ad3b856@bbrezillon>
Hello,
Le 15/06/2016 22:07, Boris Brezillon a écrit :
> On Wed, 15 Jun 2016 21:15:30 +0200
> Romain Perier <romain.perier@free-electrons.com> wrote:
>
>> Adding a TDMA descriptor at the end of the request for copying the
>> output IV vector via a DMA transfer. This is required for processing
>> cipher requests asynchroniously in chained mode, otherwise the content
>
> asynchronously
>
>> of the IV vector will be overwriten for each new finished request.
>
> BTW, Not sure the term 'asynchronously' is appropriate here. The
> standard (AKA non-DMA) processing is also asynchronous. The real reason
> here is that you want to chain the requests and offload as much
> processing as possible to the DMA and crypto engine. And as you
> explained, this is only possible if we retrieve the updated IV using
> DMA.
>
What do you think of the following description ?
"
Adding a TDMA descriptor at the end of the request for copying the
output IV vector via a DMA transfer. This is a good way for offloading
as much as processing as possible to the DMA and the crypto engine.
This is also required for processing multiple cipher requests
in chained mode, otherwise the content of the IV vector would be
overwritten by the last processed request.
"
This point is true if multiple chained requests are processed via TDMA,
the content of the "global" IV output vector would be overwritten
by the last request.
>> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
>> index 74071e4..74b84bd 100644
>> --- a/drivers/crypto/marvell/cesa.h
>> +++ b/drivers/crypto/marvell/cesa.h
>> @@ -275,6 +275,7 @@ struct mv_cesa_op_ctx {
>> #define CESA_TDMA_DUMMY 0
>> #define CESA_TDMA_DATA 1
>> #define CESA_TDMA_OP 2
>> +#define CESA_TDMA_IV 4
>
> Should be 3 and not 4: TDMA_TYPE is an enum, not a bit field.
Ok
>
> Sometime it's better to offend the < 80 characters rule than doing
> funky stuff ;).
I just wanted to make checkpatch happy :D
Yeah, that's ugly, I agree. I will fix this.
>
>> + memcpy_fromio(ablkreq->info, dreq->chain.last->data, ivsize);
>> return ret;
>> -
>> - memcpy_fromio(ablkreq->info,
>> - engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
>> - crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq)));
>> -
>> - return 0;
>> + }
>
> Missing blank line.
ack
>
>> + return mv_cesa_ablkcipher_std_process(ablkreq, status);
>
> This version is more readable IMHO:
>
> struct mv_cesa_tdma_req *dreq;
> unsigned int ivsize;
> int ret;
>
> if (creq->req.base.type == CESA_STD_REQ)
> return mv_cesa_ablkcipher_std_process(ablkreq, status);
>
> ret = mv_cesa_dma_process(&creq->req.dma, status);
> if (ret)
> return ret;
>
> dreq = &creq->req.dma;
> ivsize =
> crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq));
> memcpy_fromio(ablkreq->info, dreq->chain.last->data, ivsize);
>
> return 0;
>
>>
>> static void mv_cesa_ablkcipher_step(struct crypto_async_request *req)
>> @@ -302,6 +307,7 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
>> struct mv_cesa_tdma_chain chain;
>> bool skip_ctx = false;
>> int ret;
>> + unsigned int ivsize;
>>
>> dreq->base.type = CESA_DMA_REQ;
>> dreq->chain.first = NULL;
>> @@ -360,6 +366,14 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
>>
>> } while (mv_cesa_ablkcipher_req_iter_next_op(&iter));
>>
>> + /* Add output data for IV */
>> + ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req));
>> + ret = mv_cesa_dma_add_iv_op(&chain, CESA_SA_CRYPT_IV_SRAM_OFFSET,
>> + ivsize, CESA_TDMA_SRC_IN_SRAM, flags);
>> +
>> + if (ret)
>> + goto err_free_tdma;
>> +
>> dreq->chain = chain;
>>
>> return 0;
>> diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c
>> index d493714..88c87be 100644
>> --- a/drivers/crypto/marvell/tdma.c
>> +++ b/drivers/crypto/marvell/tdma.c
>> @@ -68,6 +68,9 @@ void mv_cesa_dma_cleanup(struct mv_cesa_tdma_req *dreq)
>> if (tdma->flags & CESA_TDMA_OP)
>
> I realize this test is wrong.
>
> It should be
> type = tdma->flags & CESA_TDMA_TYPE_MSK;
> if (type == CESA_TDMA_OP)
>
>> dma_pool_free(cesa_dev->dma->op_pool, tdma->op,
>> le32_to_cpu(tdma->src));
>> + else if (tdma->flags & CESA_TDMA_IV)
>
> and here
I propose a separated commit to fix this problem. What do you think ?
> else if (type == CESA_TDMA_IV)
>
>> + dma_pool_free(cesa_dev->dma->iv_pool, tdma->data,
>> + le32_to_cpu(tdma->dst));
>>
>> tdma = tdma->next;
>> dma_pool_free(cesa_dev->dma->tdma_desc_pool, old_tdma,
>> @@ -120,6 +123,32 @@ mv_cesa_dma_add_desc(struct mv_cesa_tdma_chain *chain, gfp_t flags)
>> return new_tdma;
>> }
>>
>> +int mv_cesa_dma_add_iv_op(struct mv_cesa_tdma_chain *chain, dma_addr_t src,
>> + u32 size, u32 flags, gfp_t gfp_flags)
>> +{
>> +
>> + struct mv_cesa_tdma_desc *tdma;
>> + u8 *cache;
>
> Why do you name that one cache? iv would be a better name.
ok
>
>> + dma_addr_t dma_handle;
>> +
>> + tdma = mv_cesa_dma_add_desc(chain, gfp_flags);
>> + if (IS_ERR(tdma))
>> + return PTR_ERR(tdma);
>> +
>> + cache = dma_pool_alloc(cesa_dev->dma->iv_pool, flags, &dma_handle);
>> + if (!cache)
>> + return -ENOMEM;
>> +
>> + tdma->byte_cnt = cpu_to_le32(size | BIT(31));
>> + tdma->src = src;
>> + tdma->dst = cpu_to_le32(dma_handle);
>> + tdma->data = cache;
>> +
>> + flags &= (CESA_TDMA_DST_IN_SRAM | CESA_TDMA_SRC_IN_SRAM);
>> + tdma->flags = flags | CESA_TDMA_DATA | CESA_TDMA_IV;
>
> You should not mix 2 different types, it's either CESA_TDMA_DATA or
> CESA_TDMA_IV, and in this case it should be CESA_TDMA_IV.
good catch.
>
>> + return 0;
>> +}
>> +
>> struct mv_cesa_op_ctx *mv_cesa_dma_add_op(struct mv_cesa_tdma_chain *chain,
>> const struct mv_cesa_op_ctx *op_templ,
>> bool skip_ctx,
>
>
>
Thanks,
Regards,
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests
From: Gregory CLEMENT @ 2016-06-16 8:32 UTC (permalink / raw)
To: Romain Perier
Cc: Boris Brezillon, Arnaud Ebalard, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <5762636A.2020800@free-electrons.com>
Hi Romain,
On jeu., juin 16 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
>
>>> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
>>> index 74071e4..74b84bd 100644
>>> --- a/drivers/crypto/marvell/cesa.h
>>> +++ b/drivers/crypto/marvell/cesa.h
>>> @@ -275,6 +275,7 @@ struct mv_cesa_op_ctx {
>>> #define CESA_TDMA_DUMMY 0
>>> #define CESA_TDMA_DATA 1
>>> #define CESA_TDMA_OP 2
>>> +#define CESA_TDMA_IV 4
>>
>> Should be 3 and not 4: TDMA_TYPE is an enum, not a bit field.
>
> Ok
>
>>
>> Sometime it's better to offend the < 80 characters rule than doing
>> funky stuff ;).
>
> I just wanted to make checkpatch happy :D
In this case you can use a temporary variable.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] crypto: caam: fix misspelled upper_32_bits
From: Arnd Bergmann @ 2016-06-16 9:05 UTC (permalink / raw)
To: Herbert Xu
Cc: Arnd Bergmann, David S. Miller, Horia Geantă, linux-crypto,
linux-kernel
An endianess fix mistakenly used higher_32_bits() instead of
upper_32_bits(), and that doesn't exist:
drivers/crypto/caam/desc_constr.h: In function 'append_ptr':
drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of function 'higher_32_bits' [-Werror=implicit-function-declaration]
*offset = cpu_to_caam_dma(ptr);
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness")
---
drivers/crypto/caam/regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 8c766cf9202c..b3c5016f6458 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -183,10 +183,10 @@ static inline u64 rd_reg64(void __iomem *reg)
#ifdef CONFIG_SOC_IMX7D
#define cpu_to_caam_dma(value) \
(((u64)cpu_to_caam32(lower_32_bits(value)) << 32) | \
- (u64)cpu_to_caam32(higher_32_bits(value)))
+ (u64)cpu_to_caam32(upper_32_bits(value)))
#define caam_dma_to_cpu(value) \
(((u64)caam32_to_cpu(lower_32_bits(value)) << 32) | \
- (u64)caam32_to_cpu(higher_32_bits(value)))
+ (u64)caam32_to_cpu(upper_32_bits(value)))
#else
#define cpu_to_caam_dma(value) cpu_to_caam64(value)
#define caam_dma_to_cpu(value) caam64_to_cpu(value)
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm
From: Raveendra Padasalagi @ 2016-06-16 9:14 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik
In-Reply-To: <8163378.RZGaC46RvE@tauon.atsec.com>
Hi Stephan,
Thanks for the review comments. I will address it in the next patch.
Please look at my reply below against each comment.
Regards,
Raveendra
On Wed, Jun 15, 2016 at 5:12 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Mittwoch, 15. Juni 2016, 15:11:58 schrieb Raveendra Padasalagi:
>
> Hi Raveendra,
>
>> From: Jeff Garzik <jeff@garzik.org>
>>
>> This patch adds the implementation of SHA3 algorithm
>> in software and it's based on original implementation
>> pushed in patch https://lwn.net/Articles/518415/ with
>> additional changes to match the padding rules specified
>> in SHA-3 specification.
>>
>> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
>> ---
>> crypto/Kconfig | 10 ++
>> crypto/Makefile | 1 +
>> crypto/sha3_generic.c | 296
>> ++++++++++++++++++++++++++++++++++++++++++++++++++ include/crypto/sha3.h |
>> 29 +++++
>> 4 files changed, 336 insertions(+)
>> create mode 100644 crypto/sha3_generic.c
>> create mode 100644 include/crypto/sha3.h
>>
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index 1d33beb..83ee8cb 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -750,6 +750,16 @@ config CRYPTO_SHA512_SPARC64
>> SHA-512 secure hash standard (DFIPS 180-2) implemented
>> using sparc64 crypto instructions, when available.
>>
>> +config CRYPTO_SHA3
>> + tristate "SHA3 digest algorithm"
>> + select CRYPTO_HASH
>> + help
>> + SHA-3 secure hash standard (DFIPS 202). It's based on
>
> Typo DFIPS?
It's not typo, DFIPS mean here Draft FIPS 202.
Do you want me to put it in another way ?
>> + cryptographic sponge function family called Keccak.
>> +
>> + References:
>> + http://keccak.noekeon.org/
>> +
>> config CRYPTO_TGR192
>> tristate "Tiger digest algorithms"
>> select CRYPTO_HASH
>> diff --git a/crypto/Makefile b/crypto/Makefile
>> index 4f4ef7e..0b82c47 100644
>> --- a/crypto/Makefile
>> +++ b/crypto/Makefile
>> @@ -61,6 +61,7 @@ obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
>> obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
>> obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
>> obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
>> +obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
>> obj-$(CONFIG_CRYPTO_WP512) += wp512.o
>> obj-$(CONFIG_CRYPTO_TGR192) += tgr192.o
>> obj-$(CONFIG_CRYPTO_GF128MUL) += gf128mul.o
>> diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
>> new file mode 100644
>> index 0000000..162dfc3
>> --- /dev/null
>> +++ b/crypto/sha3_generic.c
>> @@ -0,0 +1,296 @@
>> +/*
>> + * Cryptographic API.
>> + *
>> + * SHA-3, as specified in
>> + * http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
>> + *
>> + * SHA-3 code by Jeff Garzik <jeff@garzik.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> Free + * Software Foundation; either version 2 of the License, or (at your
>> option)• + * any later version.
>> + *
>> + */
>> +#include <crypto/internal/hash.h>
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <crypto/sha3.h>
>> +#include <asm/byteorder.h>
>> +
>> +#define KECCAK_ROUNDS 24
>> +
>> +#define ROTL64(x, y) (((x) << (y)) | ((x) >> (64 - (y))))
>> +
>> +static const u64 keccakf_rndc[24] = {
>> + 0x0000000000000001, 0x0000000000008082, 0x800000000000808a,
>> + 0x8000000080008000, 0x000000000000808b, 0x0000000080000001,
>> + 0x8000000080008081, 0x8000000000008009, 0x000000000000008a,
>> + 0x0000000000000088, 0x0000000080008009, 0x000000008000000a,
>> + 0x000000008000808b, 0x800000000000008b, 0x8000000000008089,
>> + 0x8000000000008003, 0x8000000000008002, 0x8000000000000080,
>> + 0x000000000000800a, 0x800000008000000a, 0x8000000080008081,
>> + 0x8000000000008080, 0x0000000080000001, 0x8000000080008008
>> +};
>> +
>> +static const int keccakf_rotc[24] = {
>> + 1, 3, 6, 10, 15, 21, 28, 36, 45, 55, 2, 14,
>> + 27, 41, 56, 8, 25, 43, 62, 18, 39, 61, 20, 44
>> +};
>> +
>> +static const int keccakf_piln[24] = {
>> + 10, 7, 11, 17, 18, 3, 5, 16, 8, 21, 24, 4,
>> + 15, 23, 19, 13, 12, 2, 20, 14, 22, 9, 6, 1
>> +};
>> +
>> +/* update the state with given number of rounds */
>> +
>> +static void keccakf(u64 st[25])
>> +{
>> + int i, j, round;
>> + u64 t, bc[5];
>> +
>> + for (round = 0; round < KECCAK_ROUNDS; round++) {
>> +
>> + /* Theta */
>> + for (i = 0; i < 5; i++)
>> + bc[i] = st[i] ^ st[i + 5] ^ st[i + 10] ^ st[i + 15]
>> + ^ st[i + 20];
>> +
>> + for (i = 0; i < 5; i++) {
>> + t = bc[(i + 4) % 5] ^ ROTL64(bc[(i + 1) % 5], 1);
>> + for (j = 0; j < 25; j += 5)
>> + st[j + i] ^= t;
>> + }
>> +
>> + /* Rho Pi */
>> + t = st[1];
>> + for (i = 0; i < 24; i++) {
>> + j = keccakf_piln[i];
>> + bc[0] = st[j];
>> + st[j] = ROTL64(t, keccakf_rotc[i]);
>> + t = bc[0];
>> + }
>> +
>> + /* Chi */
>> + for (j = 0; j < 25; j += 5) {
>> + for (i = 0; i < 5; i++)
>> + bc[i] = st[j + i];
>> + for (i = 0; i < 5; i++)
>> + st[j + i] ^= (~bc[(i + 1) % 5]) &
>> + bc[(i + 2) % 5];
>> + }
>> +
>> + /* Iota */
>> + st[0] ^= keccakf_rndc[round];
>> + }
>> +}
>> +
>> +static void sha3_init(struct sha3_state *sctx, unsigned int digest_sz)
>> +{
>> + memset(sctx, 0, sizeof(*sctx));
>> + sctx->md_len = digest_sz;
>> + sctx->rsiz = 200 - 2 * digest_sz;
>> + sctx->rsizw = sctx->rsiz / 8;
>> +}
>> +
>> +static int sha3_224_init(struct shash_desc *desc)
>> +{
>> + struct sha3_state *sctx = shash_desc_ctx(desc);
>> +
>> + sha3_init(sctx, SHA3_224_DIGEST_SIZE);
>> + return 0;
>> +}
>> +
>> +static int sha3_256_init(struct shash_desc *desc)
>> +{
>> + struct sha3_state *sctx = shash_desc_ctx(desc);
>> +
>> + sha3_init(sctx, SHA3_256_DIGEST_SIZE);
>> + return 0;
>> +}
>> +
>> +static int sha3_384_init(struct shash_desc *desc)
>> +{
>> + struct sha3_state *sctx = shash_desc_ctx(desc);
>> +
>> + sha3_init(sctx, SHA3_384_DIGEST_SIZE);
>> + return 0;
>> +}
>> +
>> +static int sha3_512_init(struct shash_desc *desc)
>> +{
>> + struct sha3_state *sctx = shash_desc_ctx(desc);
>> +
>> + sha3_init(sctx, SHA3_512_DIGEST_SIZE);
>> + return 0;
>> +}
>> +
>> +static int sha3_update(struct shash_desc *desc, const u8 *data,
>> + unsigned int len)
>> +{
>> + struct sha3_state *sctx = shash_desc_ctx(desc);
>> + unsigned int done;
>> + const u8 *src;
>> +
>> + done = 0;
>> + src = data;
>> +
>> + if ((sctx->partial + len) > (sctx->rsiz - 1)) {
>> + if (sctx->partial) {
>> + done = -sctx->partial;
>> + memcpy(sctx->buf + sctx->partial, data,
>> + done + sctx->rsiz);
>> + src = sctx->buf;
>> + }
>> +
>> + do {
>> + unsigned int i;
>> +
>> + for (i = 0; i < sctx->rsizw; i++)
>> + sctx->st[i] ^= ((u64 *) src)[i];
>> + keccakf(sctx->st);
>> +
>> + done += sctx->rsiz;
>> + src = data + done;
>> + } while (done + (sctx->rsiz - 1) < len);
>> +
>> + sctx->partial = 0;
>> + }
>> + memcpy(sctx->buf + sctx->partial, src, len - done);
>> + sctx->partial += (len - done);
>> +
>> + return 0;
>> +}
>> +
>> +static int sha3_final(struct shash_desc *desc, u8 *out)
>> +{
>> + struct sha3_state *sctx = shash_desc_ctx(desc);
>> + unsigned int i, inlen = sctx->partial;
>> +
>> + sctx->buf[inlen++] = 0x06;
>> + memset(sctx->buf + inlen, 0, sctx->rsiz - inlen);
>> + sctx->buf[sctx->rsiz - 1] |= 0x80;
>> +
>> + for (i = 0; i < sctx->rsizw; i++)
>> + sctx->st[i] ^= ((u64 *) sctx->buf)[i];
>> +
>> + keccakf(sctx->st);
>> +
>> + for (i = 0; i < sctx->rsizw; i++)
>> + sctx->st[i] = cpu_to_le64(sctx->st[i]);
>> +
>> + memcpy(out, sctx->st, sctx->md_len);
>> +
>> + memset(sctx, 0, sizeof(*sctx));
>> + return 0;
>> +}
>> +
>> +static struct shash_alg sha3_224 = {
>> + .digestsize = SHA3_224_DIGEST_SIZE,
>> + .init = sha3_224_init,
>> + .update = sha3_update,
>> + .final = sha3_final,
>> + .descsize = sizeof(struct sha3_state),
>> + .base = {
>> + .cra_name = "sha3-224",
>> + .cra_driver_name = "sha3-224-generic",
>> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
>> + .cra_blocksize = SHA3_224_BLOCK_SIZE,
>> + .cra_module = THIS_MODULE,
>> + }
>> +};
>> +
>> +static struct shash_alg sha3_256 = {
>> + .digestsize = SHA3_256_DIGEST_SIZE,
>> + .init = sha3_256_init,
>> + .update = sha3_update,
>> + .final = sha3_final,
>> + .descsize = sizeof(struct sha3_state),
>> + .base = {
>> + .cra_name = "sha3-256",
>> + .cra_driver_name = "sha3-256-generic",
>> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
>> + .cra_blocksize = SHA3_256_BLOCK_SIZE,
>> + .cra_module = THIS_MODULE,
>> + }
>> +};
>> +
>> +static struct shash_alg sha3_384 = {
>> + .digestsize = SHA3_384_DIGEST_SIZE,
>> + .init = sha3_384_init,
>> + .update = sha3_update,
>> + .final = sha3_final,
>> + .descsize = sizeof(struct sha3_state),
>> + .base = {
>> + .cra_name = "sha3-384",
>> + .cra_driver_name = "sha3-384-generic",
>> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
>> + .cra_blocksize = SHA3_384_BLOCK_SIZE,
>> + .cra_module = THIS_MODULE,
>> + }
>> +};
>> +
>> +static struct shash_alg sha3_512 = {
>> + .digestsize = SHA3_512_DIGEST_SIZE,
>> + .init = sha3_512_init,
>> + .update = sha3_update,
>> + .final = sha3_final,
>> + .descsize = sizeof(struct sha3_state),
>> + .base = {
>> + .cra_name = "sha3-512",
>> + .cra_driver_name = "sha3-512-generic",
>> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
>> + .cra_blocksize = SHA3_512_BLOCK_SIZE,
>> + .cra_module = THIS_MODULE,
>> + }
>> +};
>
> Shouldn't there be a priority here?
Yes, I will fix it in next patch.
>> +
>> +static int __init sha3_generic_mod_init(void)
>> +{
>> + int ret;
>> +
>> + ret = crypto_register_shash(&sha3_224);
>> + if (ret < 0)
>> + goto err_out;
>> + ret = crypto_register_shash(&sha3_256);
>> + if (ret < 0)
>> + goto err_out_224;
>> + ret = crypto_register_shash(&sha3_384);
>> + if (ret < 0)
>> + goto err_out_256;
>> + ret = crypto_register_shash(&sha3_512);
>> + if (ret < 0)
>> + goto err_out_384;
>> +
>> + return 0;
>> +
>> +err_out_384:
>> + crypto_unregister_shash(&sha3_384);
>> +err_out_256:
>> + crypto_unregister_shash(&sha3_256);
>> +err_out_224:
>> + crypto_unregister_shash(&sha3_224);
>> +err_out:
>> + return ret;
>> +}
>> +
>> +static void __exit sha3_generic_mod_fini(void)
>> +{
>> + crypto_unregister_shash(&sha3_224);
>> + crypto_unregister_shash(&sha3_256);
>> + crypto_unregister_shash(&sha3_384);
>> + crypto_unregister_shash(&sha3_512);
>> +}
>> +
>> +module_init(sha3_generic_mod_init);
>> +module_exit(sha3_generic_mod_fini);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("SHA-3 Secure Hash Algorithm");
>> +
>> +MODULE_ALIAS("sha3-224");
>> +MODULE_ALIAS("sha3-256");
>> +MODULE_ALIAS("sha3-384");
>> +MODULE_ALIAS("sha3-512");
>
> MODULE_ALIAS_CRYPTO?
>
> What about the aliases for cra_driver_name?
Yes, I will fix it in next patch.
>> diff --git a/include/crypto/sha3.h b/include/crypto/sha3.h
>> new file mode 100644
>> index 0000000..f4c9f68
>> --- /dev/null
>> +++ b/include/crypto/sha3.h
>> @@ -0,0 +1,29 @@
>> +/*
>> + * Common values for SHA-3 algorithms
>> + */
>> +#ifndef __CRYPTO_SHA3_H__
>> +#define __CRYPTO_SHA3_H__
>> +
>> +#define SHA3_224_DIGEST_SIZE (224 / 8)
>> +#define SHA3_224_BLOCK_SIZE (200 - 2 * SHA3_224_DIGEST_SIZE)
>> +
>> +#define SHA3_256_DIGEST_SIZE (256 / 8)
>> +#define SHA3_256_BLOCK_SIZE (200 - 2 * SHA3_256_DIGEST_SIZE)
>> +
>> +#define SHA3_384_DIGEST_SIZE (384 / 8)
>> +#define SHA3_384_BLOCK_SIZE (200 - 2 * SHA3_384_DIGEST_SIZE)
>> +
>> +#define SHA3_512_DIGEST_SIZE (512 / 8)
>> +#define SHA3_512_BLOCK_SIZE (200 - 2 * SHA3_512_DIGEST_SIZE)
>> +
>> +struct sha3_state {
>> + u64 st[25];
>> + unsigned int md_len;
>> + unsigned int rsiz;
>> + unsigned int rsizw;
>> +
>> + unsigned int partial;
>> + u8 buf[SHA3_224_BLOCK_SIZE];
>> +};
>> +
>> +#endif
>
>
> Ciao
> Stephan
^ permalink raw reply
* Re: [PATCH] crypto: caam: fix misspelled upper_32_bits
From: Horia Ioan Geanta Neag @ 2016-06-16 10:28 UTC (permalink / raw)
To: Arnd Bergmann, Herbert Xu
Cc: David S. Miller, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20160616090609.1041337-1-arnd@arndb.de>
On 6/16/2016 12:04 PM, Arnd Bergmann wrote:
> An endianess fix mistakenly used higher_32_bits() instead of
> upper_32_bits(), and that doesn't exist:
>
> drivers/crypto/caam/desc_constr.h: In function 'append_ptr':
> drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of function 'higher_32_bits' [-Werror=implicit-function-declaration]
> *offset = cpu_to_caam_dma(ptr);
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness")
Oops... thanks Arnd!
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
> ---
> drivers/crypto/caam/regs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
> index 8c766cf9202c..b3c5016f6458 100644
> --- a/drivers/crypto/caam/regs.h
> +++ b/drivers/crypto/caam/regs.h
> @@ -183,10 +183,10 @@ static inline u64 rd_reg64(void __iomem *reg)
> #ifdef CONFIG_SOC_IMX7D
> #define cpu_to_caam_dma(value) \
> (((u64)cpu_to_caam32(lower_32_bits(value)) << 32) | \
> - (u64)cpu_to_caam32(higher_32_bits(value)))
> + (u64)cpu_to_caam32(upper_32_bits(value)))
> #define caam_dma_to_cpu(value) \
> (((u64)caam32_to_cpu(lower_32_bits(value)) << 32) | \
> - (u64)caam32_to_cpu(higher_32_bits(value)))
> + (u64)caam32_to_cpu(upper_32_bits(value)))
> #else
> #define cpu_to_caam_dma(value) cpu_to_caam64(value)
> #define caam_dma_to_cpu(value) caam64_to_cpu(value)
>
^ permalink raw reply
* Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req
From: Romain Perier @ 2016-06-16 12:02 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <20160615224249.3e1e477b@bbrezillon>
Hello,
Le 15/06/2016 22:42, Boris Brezillon a écrit :
> On Wed, 15 Jun 2016 21:15:31 +0200
> Romain Perier <romain.perier@free-electrons.com> wrote:
>
>> Actually the only way to access the tdma chain is to use the 'req' union
>
> Currently, ...
ok
> Now that the dma specific fields are part of the base request there's no
> reason to keep this union.
>
> You can just put struct mv_cesa_req base; directly under struct
> mv_cesa_ablkcipher_req, and move mv_cesa_ablkcipher_std_req fields in
> mv_cesa_ablkcipher_req.
Well, I think that I might keep the changes related to mv_cesa_tdma_req
in this commit (+ put struct mv_cesa_req base; direct under struct
mv_cesa_ablkcipher_req) and move the changes related to
mv_cesa_ablkcipher_std_req into another commit. What do you think ?
> Initialize basereq earlier and pass it as the first argument of
> mv_cesa_dma_process().
ok
>> @@ -174,9 +174,9 @@ static inline void
>> mv_cesa_ablkcipher_dma_prepare(struct ablkcipher_request *req)
>> {
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(req);
>> - struct mv_cesa_tdma_req *dreq = &creq->req.dma;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> You named it basereq in mv_cesa_ablkcipher_step(). Try to be
> consistent, no matter the name.
ack
>
>>
>> - mv_cesa_dma_prepare(dreq, dreq->base.engine);
>> + mv_cesa_dma_prepare(dreq, dreq->engine);
>> }
>>
>> static inline void
>> @@ -199,7 +199,7 @@ static inline void mv_cesa_ablkcipher_prepare(struct crypto_async_request *req,
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
>> creq->req.base.engine = engine;
>>
>> - if (creq->req.base.type == CESA_DMA_REQ)
>> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
>> mv_cesa_ablkcipher_dma_prepare(ablkreq);
>> else
>> mv_cesa_ablkcipher_std_prepare(ablkreq);
>> @@ -302,14 +302,13 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(req);
>> gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
>> GFP_KERNEL : GFP_ATOMIC;
>> - struct mv_cesa_tdma_req *dreq = &creq->req.dma;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> Ditto.
ack
>> @@ -256,9 +256,9 @@ static int mv_cesa_ahash_std_process(struct ahash_request *req, u32 status)
>> static inline void mv_cesa_ahash_dma_prepare(struct ahash_request *req)
>> {
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> - struct mv_cesa_tdma_req *dreq = &creq->req.dma.base;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> Ditto.
ack
>> @@ -340,7 +340,7 @@ static void mv_cesa_ahash_prepare(struct crypto_async_request *req,
>>
>> creq->req.base.engine = engine;
>>
>> - if (creq->req.base.type == CESA_DMA_REQ)
>> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
>> mv_cesa_ahash_dma_prepare(ahashreq);
>> else
>> mv_cesa_ahash_std_prepare(ahashreq);
>> @@ -555,8 +555,7 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req)
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
>> GFP_KERNEL : GFP_ATOMIC;
>> - struct mv_cesa_ahash_dma_req *ahashdreq = &creq->req.dma;
>> - struct mv_cesa_tdma_req *dreq = &ahashdreq->base;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> Ditto.
ack
>
>> struct mv_cesa_ahash_dma_iter iter;
>> struct mv_cesa_op_ctx *op = NULL;
>> unsigned int frag_len;
>> @@ -662,11 +661,6 @@ static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> int ret;
>>
>> - if (cesa_dev->caps->has_tdma)
>> - creq->req.base.type = CESA_DMA_REQ;
>> - else
>> - creq->req.base.type = CESA_STD_REQ;
>> -
>
> Hm, where is it decided now? I mean, I don't see this test anywhere
> else in your patch, which means you're now always using standard mode.
It has been replaced by mv_cesa_req_get_type() + initializing
chain.first to NULL in std_init. So, that's the same thing, no ?
>
>> creq->src_nents = sg_nents_for_len(req->src, req->nbytes);
>> if (creq->src_nents < 0) {
>> dev_err(cesa_dev->dev, "Invalid number of src SG");
>> @@ -680,7 +674,7 @@ static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
>> if (*cached)
>> return 0;
>>
>> - if (creq->req.base.type == CESA_DMA_REQ)
>> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
>
> Should be
>
> if (cesa_dev->caps->has_tdma)
>
>> ret = mv_cesa_ahash_dma_req_init(req);
Why ? mv_cesa_req_get_type() tests mv_cesa_req->chain and returns a code
depending on its value. This value is initialized according to what is
set un "has_tdma"...
Thanks,
Regards,
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req
From: Boris Brezillon @ 2016-06-16 12:45 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <57629562.9030908@free-electrons.com>
On Thu, 16 Jun 2016 14:02:42 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> > Now that the dma specific fields are part of the base request there's no
> > reason to keep this union.
> >
> > You can just put struct mv_cesa_req base; directly under struct
> > mv_cesa_ablkcipher_req, and move mv_cesa_ablkcipher_std_req fields in
> > mv_cesa_ablkcipher_req.
>
>
> Well, I think that I might keep the changes related to mv_cesa_tdma_req
> in this commit (+ put struct mv_cesa_req base; direct under struct
> mv_cesa_ablkcipher_req) and move the changes related to
> mv_cesa_ablkcipher_std_req into another commit. What do you think ?
Sounds good.
> >
> >> struct mv_cesa_ahash_dma_iter iter;
> >> struct mv_cesa_op_ctx *op = NULL;
> >> unsigned int frag_len;
> >> @@ -662,11 +661,6 @@ static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
> >> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
> >> int ret;
> >>
> >> - if (cesa_dev->caps->has_tdma)
> >> - creq->req.base.type = CESA_DMA_REQ;
> >> - else
> >> - creq->req.base.type = CESA_STD_REQ;
> >> -
> >
> > Hm, where is it decided now? I mean, I don't see this test anywhere
> > else in your patch, which means you're now always using standard mode.
>
> It has been replaced by mv_cesa_req_get_type() + initializing
> chain.first to NULL in std_init. So, that's the same thing, no ?
And that's exactly my point :-). When these fields are NULL the request
is a STD request...
>
> >
> >> creq->src_nents = sg_nents_for_len(req->src, req->nbytes);
> >> if (creq->src_nents < 0) {
> >> dev_err(cesa_dev->dev, "Invalid number of src SG");
> >> @@ -680,7 +674,7 @@ static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
> >> if (*cached)
> >> return 0;
> >>
> >> - if (creq->req.base.type == CESA_DMA_REQ)
> >> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
... and here you're testing if it's a DMA request, which will always be
false, since mv_cesa_ahash_dma_req_init() is the function supposed to
fill the ->first and ->last fields.
> >
> > Should be
> >
> > if (cesa_dev->caps->has_tdma)
> >
> >> ret = mv_cesa_ahash_dma_req_init(req);
>
> Why ? mv_cesa_req_get_type() tests mv_cesa_req->chain and returns a code
> depending on its value. This value is initialized according to what is
> set un "has_tdma"...
As explained above, it's not ;).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req
From: Boris Brezillon @ 2016-06-16 12:57 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <57629562.9030908@free-electrons.com>
On Thu, 16 Jun 2016 14:02:42 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> > Now that the dma specific fields are part of the base request there's no
> > reason to keep this union.
> >
> > You can just put struct mv_cesa_req base; directly under struct
> > mv_cesa_ablkcipher_req, and move mv_cesa_ablkcipher_std_req fields in
> > mv_cesa_ablkcipher_req.
>
>
> Well, I think that I might keep the changes related to mv_cesa_tdma_req
> in this commit (+ put struct mv_cesa_req base; direct under struct
> mv_cesa_ablkcipher_req) and move the changes related to
> mv_cesa_ablkcipher_std_req into another commit. What do you think ?
After re-reading the code, I'm not sure the last part (moving
mv_cesa_ablkcipher_std_req fields into mv_cesa_ablkcipher_req) is a
good idea anymore.
So let's just kill the union, and move mv_cesa_ablkcipher_std_req and
mv_cesa_req base in mv_cesa_ablkcipher_req (you'll also have to remove
the base field from the mv_cesa_ablkcipher_std_req struct).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] crypto: caam - replace deprecated EXTRA_CFLAGS
From: Tudor Ambarus @ 2016-06-16 13:32 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, horia.geanta, Tudor Ambarus
EXTRA_CFLAGS is still supported but its usage is deprecated.
Signed-off-by: Tudor Ambarus <tudor-dan.ambarus@nxp.com>
---
drivers/crypto/caam/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 399ad55..3e9d3e1 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -2,7 +2,7 @@
# Makefile for the CAAM backend and dependent components
#
ifeq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG), y)
- EXTRA_CFLAGS := -DDEBUG
+ ccflags-y := -DDEBUG
endif
ccflags-y += -I$(srctree)/crypto
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 5/7] crypto: marvell: Adding a complete operation for async requests
From: Romain Perier @ 2016-06-16 13:41 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <20160615225531.4e060f11@bbrezillon>
Hello,
Le 15/06/2016 22:55, Boris Brezillon a écrit :
>> +
>
> Nit: not sure you should mix this cosmetic change with the other
> changes.
Ok
> You already have ivsize initialized.
>
>> + memcpy_fromio(ablkreq->info, basereq->chain.last->data, ivsize);
>
> Use memcpy() here.
good catch, for both.
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 6/7] crypto: marvell: Adding load balancing between engines
From: Romain Perier @ 2016-06-16 13:44 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnaud Ebalard, Gregory Clement, Thomas Petazzoni,
David S. Miller, Russell King, linux-crypto, linux-arm-kernel
In-Reply-To: <20160615231315.5e254706@bbrezillon>
Hello,
Le 15/06/2016 23:13, Boris Brezillon a écrit :
> On Wed, 15 Jun 2016 21:15:33 +0200
> Romain Perier <romain.perier@free-electrons.com> wrote:
>
>> This commits adds support for fine grained load balancing on
>> multi-engine IPs. The engine is pre-selected based on its current load
>> and on the weight of the crypto request that is about to be processed.
>> The global crypto queue is also moved to each engine. These changes are
>
> to the mv_cesa_engine object.
>
>> useful for preparing the code to support TDMA chaining between crypto
>> requests, because each tdma chain will be handled per engine.
>
> These changes are required to allow chaining crypto requests at the DMA
> level.
ack
>> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
>> index fbaae2f..02aa38f 100644
>> --- a/drivers/crypto/marvell/cipher.c
>> +++ b/drivers/crypto/marvell/cipher.c
>> @@ -89,6 +89,9 @@ static void mv_cesa_ablkcipher_std_step(struct ablkcipher_request *req)
>> size_t len = min_t(size_t, req->nbytes - sreq->offset,
>> CESA_SA_SRAM_PAYLOAD_SIZE);
>>
>> + mv_cesa_adjust_op(engine, &sreq->op);
>> + memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op));
>> +
>> len = sg_pcopy_to_buffer(req->src, creq->src_nents,
>> engine->sram + CESA_SA_DATA_SRAM_OFFSET,
>> len, sreq->offset);
>> @@ -167,12 +170,9 @@ mv_cesa_ablkcipher_std_prepare(struct ablkcipher_request *req)
>> {
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(req);
>> struct mv_cesa_ablkcipher_std_req *sreq = &creq->req.std;
>> - struct mv_cesa_engine *engine = sreq->base.engine;
>>
>> sreq->size = 0;
>> sreq->offset = 0;
>> - mv_cesa_adjust_op(engine, &sreq->op);
>> - memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op));
>
> Are these changes really related to this load balancing support?
> AFAICT, it's something that could have been done earlier, and is not
> dependent on the changes your introducing here, but maybe I'm missing
> something.
Yeah, indeed. I suggest another commit for doing it. What do you think ?
>
>> }
>
> [...]
>
>> static int mv_cesa_ecb_aes_encrypt(struct ablkcipher_request *req)
>> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
>> index f7f84cc..5946a69 100644
>> --- a/drivers/crypto/marvell/hash.c
>> +++ b/drivers/crypto/marvell/hash.c
>> @@ -162,6 +162,15 @@ static void mv_cesa_ahash_std_step(struct ahash_request *req)
>> unsigned int new_cache_ptr = 0;
>> u32 frag_mode;
>> size_t len;
>> + unsigned int digsize;
>> + int i;
>> +
>> + mv_cesa_adjust_op(engine, &creq->op_tmpl);
>> + memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
>> +
>> + digsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(req));
>> + for (i = 0; i < digsize / 4; i++)
>> + writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
>>
>> if (creq->cache_ptr)
>> memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
>> @@ -265,11 +274,8 @@ static void mv_cesa_ahash_std_prepare(struct ahash_request *req)
>> {
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> struct mv_cesa_ahash_std_req *sreq = &creq->req.std;
>> - struct mv_cesa_engine *engine = sreq->base.engine;
>>
>> sreq->offset = 0;
>> - mv_cesa_adjust_op(engine, &creq->op_tmpl);
>> - memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
>
> Same as above: it doesn't seem related to the load balancing stuff.
It might be moved into this "separated commit" described above.
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
From: Andrew Zaborowski @ 2016-06-16 14:59 UTC (permalink / raw)
To: Stephan Mueller
Cc: Mat Martineau, Tadeusz Struk, David Howells, Herbert Xu,
linux-api, Marcel Holtmann, linux-kernel, keyrings,
Linux Crypto Mailing List, David Woodhouse, davem
In-Reply-To: <10863259.oUiAus9m9y@positron.chronox.de>
Hi Stephan,
On 16 June 2016 at 10:05, Stephan Mueller <smueller@chronox.de> wrote:
> Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski:
>
> Hi Andrew,
>
>> >
>> > I think we have agreed on dropping the length enforcement at the interface
>> > level.
>>
>> Separately from this there's a problem with the user being unable to
>> know if the algorithm is going to fail because of destination buffer
>> size != key size (including kernel users). For RSA, the qat
>> implementation will fail while the software implementation won't. For
>> pkcs1pad(...) there's currently just one implementation but the user
>> can't assume that.
>
> If I understand your issue correctly, my initial code requiring the caller to
> provide sufficient memory would have covered the issue, right?
This isn't an issue with AF_ALG, I should have changed the subject
line perhaps. In this case it's an inconsistency between some
implementations and the documentation (header comment). It affects
users accessing the cipher through AF_ALG but also directly.
> If so, we seem
> to have implementations which can handle shorter buffer sizes and some which
> do not. Should a caller really try to figure the right buffer size out? Why
> not requiring a mandatory buffer size and be done with it? I.e. what is the
> gain to allow shorter buffer sizes (as pointed out by Mat)?
It's that client code doesn't need an intermediate layer with an
additional buffer and a memcpy to provide a sensible API. If the code
wants to decrypt a 32-byte Digest Info structure with a given key or a
reference to a key it makes no sense, logically or in terms of
performance, for it to provide a key-sized buffer.
In the case of the userspace interface I think it's also rare for a
recv() or read() on Linux to require a buffer larger than it's going
to use, correct me if i'm wrong. (I.e. fail if given a 32-byte
buffer, return 32 bytes of data anyway) Turning your questino around
is there a gain from requiring larger buffers?
Best regards
^ permalink raw reply
* Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
From: Stephan Mueller @ 2016-06-16 15:38 UTC (permalink / raw)
To: Andrew Zaborowski
Cc: Mat Martineau, Tadeusz Struk, David Howells, Herbert Xu,
linux-api, Marcel Holtmann, linux-kernel, keyrings,
Linux Crypto Mailing List, David Woodhouse, davem
In-Reply-To: <CAOq732KFLoeBz2-fkEbbW1ixf9rAQEJcWh3WK_mbB5jQGYYe6w@mail.gmail.com>
Am Donnerstag, 16. Juni 2016, 16:59:01 schrieb Andrew Zaborowski:
Hi Andrew,
> Hi Stephan,
>
> On 16 June 2016 at 10:05, Stephan Mueller <smueller@chronox.de> wrote:
> > Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski:
> >
> > Hi Andrew,
> >
> >> > I think we have agreed on dropping the length enforcement at the
> >> > interface
> >> > level.
> >>
> >> Separately from this there's a problem with the user being unable to
> >> know if the algorithm is going to fail because of destination buffer
> >> size != key size (including kernel users). For RSA, the qat
> >> implementation will fail while the software implementation won't. For
> >> pkcs1pad(...) there's currently just one implementation but the user
> >> can't assume that.
> >
> > If I understand your issue correctly, my initial code requiring the caller
> > to provide sufficient memory would have covered the issue, right?
>
> This isn't an issue with AF_ALG, I should have changed the subject
> line perhaps. In this case it's an inconsistency between some
> implementations and the documentation (header comment). It affects
> users accessing the cipher through AF_ALG but also directly.
As I want to send a new version of the algif_akcipher shortly now (hoping for
an inclusion into 4.8), is there anything you see that I should prepare for
regarding this issue? I.e. do you forsee a potential fix that would change the
API or ABI of algif_akcipher?
>
> > If so, we seem
> > to have implementations which can handle shorter buffer sizes and some
> > which do not. Should a caller really try to figure the right buffer size
> > out? Why not requiring a mandatory buffer size and be done with it? I.e.
> > what is the gain to allow shorter buffer sizes (as pointed out by Mat)?
>
> It's that client code doesn't need an intermediate layer with an
> additional buffer and a memcpy to provide a sensible API. If the code
> wants to decrypt a 32-byte Digest Info structure with a given key or a
> reference to a key it makes no sense, logically or in terms of
> performance, for it to provide a key-sized buffer.
>
> In the case of the userspace interface I think it's also rare for a
> recv() or read() on Linux to require a buffer larger than it's going
> to use, correct me if i'm wrong. (I.e. fail if given a 32-byte
> buffer, return 32 bytes of data anyway) Turning your questino around
> is there a gain from requiring larger buffers?
That is a good one :-)
I have that check removed.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm
From: Stephan Mueller @ 2016-06-16 15:40 UTC (permalink / raw)
To: Raveendra Padasalagi
Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik
In-Reply-To: <CAAFb_vq0dGbQP6gY-t0hDCqa1pBQZGeQy00RFoUww0_Gvw=kUg@mail.gmail.com>
Am Donnerstag, 16. Juni 2016, 14:44:57 schrieb Raveendra Padasalagi:
Hi Raveendra,
> > Typo DFIPS?
>
> It's not typo, DFIPS mean here Draft FIPS 202.
> Do you want me to put it in another way ?
I have never seen DFIPS. Besides, most FIPS standards are drafts (including of
FIPS 140-2 :-) ), because it would require a signature from some ministry big-
wig in the US govt to "release" it. Hence, I expect that it would retain its
draft state for a long time :-)
But if DFIPS is what you think is right, leave it :-)
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm
From: Raveendra Padasalagi @ 2016-06-16 16:09 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik
In-Reply-To: <1704146.ryraC2p2Bb@tauon.atsec.com>
Hi Stephan,
Yes, I was initially thinking of to put it as FIPS but looked at the
existing "crypto/Kconfig"
for other algorithms and found it to be using DFIPS. So kept this also
the same :)
I need some clarification to address your comment
"Shouldn't there be a priority here?"
What I know regarding priority value for an algorithm
is higher the priority value it will be get selected for execution.
For example, let's say for software implementation of the algorithm if
priority value
is specified as 100 and hardware driver implementation of the same
algorithm uses
the priority value of 300 then hardware algo is what selected for execution.
I just had a look at priority value specified for other hash
algorithm's and none of the
software implementation specify any value, So it will be 0.
I think it's okay to not to specify any priority value for software
implementation,
as hardware implementation can use non zero value if it needs higher priority.
What's your opinion ?
Regards,
Raveendra
On Thu, Jun 16, 2016 at 9:10 PM, Stephan Mueller <smueller@chronox.de> wrote:
> Am Donnerstag, 16. Juni 2016, 14:44:57 schrieb Raveendra Padasalagi:
>
> Hi Raveendra,
>
>> > Typo DFIPS?
>>
>> It's not typo, DFIPS mean here Draft FIPS 202.
>> Do you want me to put it in another way ?
>
> I have never seen DFIPS. Besides, most FIPS standards are drafts (including of
> FIPS 140-2 :-) ), because it would require a signature from some ministry big-
> wig in the US govt to "release" it. Hence, I expect that it would retain its
> draft state for a long time :-)
>
> But if DFIPS is what you think is right, leave it :-)
>
> Ciao
> Stephan
^ permalink raw reply
* Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm
From: Stephan Mueller @ 2016-06-16 16:24 UTC (permalink / raw)
To: Raveendra Padasalagi
Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik
In-Reply-To: <CAAFb_vqubPdy4g0NsM02JaUN-YL8V17kYbVMHWSTv9CByZ3XRA@mail.gmail.com>
Am Donnerstag, 16. Juni 2016, 21:39:17 schrieb Raveendra Padasalagi:
Hi Raveendra,
> I need some clarification to address your comment
>
> "Shouldn't there be a priority here?"
>
> What I know regarding priority value for an algorithm
> is higher the priority value it will be get selected for execution.
>
> For example, let's say for software implementation of the algorithm if
> priority value
> is specified as 100 and hardware driver implementation of the same
> algorithm uses
> the priority value of 300 then hardware algo is what selected for execution.
>
> I just had a look at priority value specified for other hash
> algorithm's and none of the
> software implementation specify any value, So it will be 0.
>
> I think it's okay to not to specify any priority value for software
> implementation,
> as hardware implementation can use non zero value if it needs higher
> priority.
>
> What's your opinion ?
You are fully correct.
To be in line with the other hashes, maybe let us leave it at 0. I was
thinking about "backend" ciphers that should never ever be selected (like the
Intel AES-NI examples) which should have a lower prio than any other cipher.
But then, they have unique cra_names, so it does not really matter :-)
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
From: Andrew Zaborowski @ 2016-06-17 0:39 UTC (permalink / raw)
To: Stephan Mueller
Cc: Mat Martineau, Tadeusz Struk, David Howells, Herbert Xu,
linux-api, Marcel Holtmann, linux-kernel, keyrings,
Linux Crypto Mailing List, David Woodhouse, davem
In-Reply-To: <1696434.oCKeAI3Bfp@tauon.atsec.com>
Hi Stephan,
On 16 June 2016 at 17:38, Stephan Mueller <smueller@chronox.de> wrote:
>> This isn't an issue with AF_ALG, I should have changed the subject
>> line perhaps. In this case it's an inconsistency between some
>> implementations and the documentation (header comment). It affects
>> users accessing the cipher through AF_ALG but also directly.
>
> As I want to send a new version of the algif_akcipher shortly now (hoping for
> an inclusion into 4.8), is there anything you see that I should prepare for
> regarding this issue? I.e. do you forsee a potential fix that would change the
> API or ABI of algif_akcipher?
No, as far as I understand algif_akcipher will do the right thing now
if the algorithm does the right thing. It's only the two RSA drivers
that would need to align with the software RSA in what buffer length
they accept.
Best regards
^ permalink raw reply
* [PATCH v2 1/2] Crypto: Add SHA-3 hash algorithm
From: Raveendra Padasalagi @ 2016-06-17 5:00 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik,
Raveendra Padasalagi
In-Reply-To: <1466139636-19779-1-git-send-email-raveendra.padasalagi@broadcom.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 10625 bytes --]
From: Jeff Garzik <jeff@garzik.org>
This patch adds the implementation of SHA3 algorithm
in software and it's based on original implementation
pushed in patch https://lwn.net/Articles/518415/ with
additional changes to match the padding rules specified
in SHA-3 specification.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
---
crypto/Kconfig | 10 ++
crypto/Makefile | 1 +
crypto/sha3_generic.c | 300 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/crypto/sha3.h | 29 +++++
4 files changed, 340 insertions(+)
create mode 100644 crypto/sha3_generic.c
create mode 100644 include/crypto/sha3.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1d33beb..83ee8cb 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -750,6 +750,16 @@ config CRYPTO_SHA512_SPARC64
SHA-512 secure hash standard (DFIPS 180-2) implemented
using sparc64 crypto instructions, when available.
+config CRYPTO_SHA3
+ tristate "SHA3 digest algorithm"
+ select CRYPTO_HASH
+ help
+ SHA-3 secure hash standard (DFIPS 202). It's based on
+ cryptographic sponge function family called Keccak.
+
+ References:
+ http://keccak.noekeon.org/
+
config CRYPTO_TGR192
tristate "Tiger digest algorithms"
select CRYPTO_HASH
diff --git a/crypto/Makefile b/crypto/Makefile
index 4f4ef7e..0b82c47 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
+obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
obj-$(CONFIG_CRYPTO_WP512) += wp512.o
obj-$(CONFIG_CRYPTO_TGR192) += tgr192.o
obj-$(CONFIG_CRYPTO_GF128MUL) += gf128mul.o
diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
new file mode 100644
index 0000000..6226439
--- /dev/null
+++ b/crypto/sha3_generic.c
@@ -0,0 +1,300 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-3, as specified in
+ * http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
+ *
+ * SHA-3 code by Jeff Garzik <jeff@garzik.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)•
+ * any later version.
+ *
+ */
+#include <crypto/internal/hash.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <crypto/sha3.h>
+#include <asm/byteorder.h>
+
+#define KECCAK_ROUNDS 24
+
+#define ROTL64(x, y) (((x) << (y)) | ((x) >> (64 - (y))))
+
+static const u64 keccakf_rndc[24] = {
+ 0x0000000000000001, 0x0000000000008082, 0x800000000000808a,
+ 0x8000000080008000, 0x000000000000808b, 0x0000000080000001,
+ 0x8000000080008081, 0x8000000000008009, 0x000000000000008a,
+ 0x0000000000000088, 0x0000000080008009, 0x000000008000000a,
+ 0x000000008000808b, 0x800000000000008b, 0x8000000000008089,
+ 0x8000000000008003, 0x8000000000008002, 0x8000000000000080,
+ 0x000000000000800a, 0x800000008000000a, 0x8000000080008081,
+ 0x8000000000008080, 0x0000000080000001, 0x8000000080008008
+};
+
+static const int keccakf_rotc[24] = {
+ 1, 3, 6, 10, 15, 21, 28, 36, 45, 55, 2, 14,
+ 27, 41, 56, 8, 25, 43, 62, 18, 39, 61, 20, 44
+};
+
+static const int keccakf_piln[24] = {
+ 10, 7, 11, 17, 18, 3, 5, 16, 8, 21, 24, 4,
+ 15, 23, 19, 13, 12, 2, 20, 14, 22, 9, 6, 1
+};
+
+/* update the state with given number of rounds */
+
+static void keccakf(u64 st[25])
+{
+ int i, j, round;
+ u64 t, bc[5];
+
+ for (round = 0; round < KECCAK_ROUNDS; round++) {
+
+ /* Theta */
+ for (i = 0; i < 5; i++)
+ bc[i] = st[i] ^ st[i + 5] ^ st[i + 10] ^ st[i + 15]
+ ^ st[i + 20];
+
+ for (i = 0; i < 5; i++) {
+ t = bc[(i + 4) % 5] ^ ROTL64(bc[(i + 1) % 5], 1);
+ for (j = 0; j < 25; j += 5)
+ st[j + i] ^= t;
+ }
+
+ /* Rho Pi */
+ t = st[1];
+ for (i = 0; i < 24; i++) {
+ j = keccakf_piln[i];
+ bc[0] = st[j];
+ st[j] = ROTL64(t, keccakf_rotc[i]);
+ t = bc[0];
+ }
+
+ /* Chi */
+ for (j = 0; j < 25; j += 5) {
+ for (i = 0; i < 5; i++)
+ bc[i] = st[j + i];
+ for (i = 0; i < 5; i++)
+ st[j + i] ^= (~bc[(i + 1) % 5]) &
+ bc[(i + 2) % 5];
+ }
+
+ /* Iota */
+ st[0] ^= keccakf_rndc[round];
+ }
+}
+
+static void sha3_init(struct sha3_state *sctx, unsigned int digest_sz)
+{
+ memset(sctx, 0, sizeof(*sctx));
+ sctx->md_len = digest_sz;
+ sctx->rsiz = 200 - 2 * digest_sz;
+ sctx->rsizw = sctx->rsiz / 8;
+}
+
+static int sha3_224_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_224_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_256_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_256_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_384_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_384_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_512_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_512_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+ unsigned int done;
+ const u8 *src;
+
+ done = 0;
+ src = data;
+
+ if ((sctx->partial + len) > (sctx->rsiz - 1)) {
+ if (sctx->partial) {
+ done = -sctx->partial;
+ memcpy(sctx->buf + sctx->partial, data,
+ done + sctx->rsiz);
+ src = sctx->buf;
+ }
+
+ do {
+ unsigned int i;
+
+ for (i = 0; i < sctx->rsizw; i++)
+ sctx->st[i] ^= ((u64 *) src)[i];
+ keccakf(sctx->st);
+
+ done += sctx->rsiz;
+ src = data + done;
+ } while (done + (sctx->rsiz - 1) < len);
+
+ sctx->partial = 0;
+ }
+ memcpy(sctx->buf + sctx->partial, src, len - done);
+ sctx->partial += (len - done);
+
+ return 0;
+}
+
+static int sha3_final(struct shash_desc *desc, u8 *out)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+ unsigned int i, inlen = sctx->partial;
+
+ sctx->buf[inlen++] = 0x06;
+ memset(sctx->buf + inlen, 0, sctx->rsiz - inlen);
+ sctx->buf[sctx->rsiz - 1] |= 0x80;
+
+ for (i = 0; i < sctx->rsizw; i++)
+ sctx->st[i] ^= ((u64 *) sctx->buf)[i];
+
+ keccakf(sctx->st);
+
+ for (i = 0; i < sctx->rsizw; i++)
+ sctx->st[i] = cpu_to_le64(sctx->st[i]);
+
+ memcpy(out, sctx->st, sctx->md_len);
+
+ memset(sctx, 0, sizeof(*sctx));
+ return 0;
+}
+
+static struct shash_alg sha3_224 = {
+ .digestsize = SHA3_224_DIGEST_SIZE,
+ .init = sha3_224_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-224",
+ .cra_driver_name = "sha3-224-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_224_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static struct shash_alg sha3_256 = {
+ .digestsize = SHA3_256_DIGEST_SIZE,
+ .init = sha3_256_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-256",
+ .cra_driver_name = "sha3-256-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_256_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static struct shash_alg sha3_384 = {
+ .digestsize = SHA3_384_DIGEST_SIZE,
+ .init = sha3_384_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-384",
+ .cra_driver_name = "sha3-384-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_384_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static struct shash_alg sha3_512 = {
+ .digestsize = SHA3_512_DIGEST_SIZE,
+ .init = sha3_512_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-512",
+ .cra_driver_name = "sha3-512-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_512_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static int __init sha3_generic_mod_init(void)
+{
+ int ret;
+
+ ret = crypto_register_shash(&sha3_224);
+ if (ret < 0)
+ goto err_out;
+ ret = crypto_register_shash(&sha3_256);
+ if (ret < 0)
+ goto err_out_224;
+ ret = crypto_register_shash(&sha3_384);
+ if (ret < 0)
+ goto err_out_256;
+ ret = crypto_register_shash(&sha3_512);
+ if (ret < 0)
+ goto err_out_384;
+
+ return 0;
+
+err_out_384:
+ crypto_unregister_shash(&sha3_384);
+err_out_256:
+ crypto_unregister_shash(&sha3_256);
+err_out_224:
+ crypto_unregister_shash(&sha3_224);
+err_out:
+ return ret;
+}
+
+static void __exit sha3_generic_mod_fini(void)
+{
+ crypto_unregister_shash(&sha3_224);
+ crypto_unregister_shash(&sha3_256);
+ crypto_unregister_shash(&sha3_384);
+ crypto_unregister_shash(&sha3_512);
+}
+
+module_init(sha3_generic_mod_init);
+module_exit(sha3_generic_mod_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("SHA-3 Secure Hash Algorithm");
+
+MODULE_ALIAS_CRYPTO("sha3-224");
+MODULE_ALIAS_CRYPTO("sha3-224-generic");
+MODULE_ALIAS_CRYPTO("sha3-256");
+MODULE_ALIAS_CRYPTO("sha3-256-generic");
+MODULE_ALIAS_CRYPTO("sha3-384");
+MODULE_ALIAS_CRYPTO("sha3-384-generic");
+MODULE_ALIAS_CRYPTO("sha3-512");
+MODULE_ALIAS_CRYPTO("sha3-512-generic");
diff --git a/include/crypto/sha3.h b/include/crypto/sha3.h
new file mode 100644
index 0000000..f4c9f68
--- /dev/null
+++ b/include/crypto/sha3.h
@@ -0,0 +1,29 @@
+/*
+ * Common values for SHA-3 algorithms
+ */
+#ifndef __CRYPTO_SHA3_H__
+#define __CRYPTO_SHA3_H__
+
+#define SHA3_224_DIGEST_SIZE (224 / 8)
+#define SHA3_224_BLOCK_SIZE (200 - 2 * SHA3_224_DIGEST_SIZE)
+
+#define SHA3_256_DIGEST_SIZE (256 / 8)
+#define SHA3_256_BLOCK_SIZE (200 - 2 * SHA3_256_DIGEST_SIZE)
+
+#define SHA3_384_DIGEST_SIZE (384 / 8)
+#define SHA3_384_BLOCK_SIZE (200 - 2 * SHA3_384_DIGEST_SIZE)
+
+#define SHA3_512_DIGEST_SIZE (512 / 8)
+#define SHA3_512_BLOCK_SIZE (200 - 2 * SHA3_512_DIGEST_SIZE)
+
+struct sha3_state {
+ u64 st[25];
+ unsigned int md_len;
+ unsigned int rsiz;
+ unsigned int rsizw;
+
+ unsigned int partial;
+ u8 buf[SHA3_224_BLOCK_SIZE];
+};
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] Add SHA-3 algorithm and test vectors.
From: Raveendra Padasalagi @ 2016-06-17 5:00 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Raveendra Padasalagi
This patchset adds the implementation of SHA-3 algorithm
in software and it's based on original implementation
pushed in patch https://lwn.net/Articles/518415/ with
additional changes to match the padding rules specified
in SHA-3 specification.
This patchset also includes changes in tcrypt module to
add support for SHA-3 algorithms test and related test
vectors for basic testing.
Broadcom Secure Processing Unit-2(SPU-2) engine supports
offloading of SHA-3 operations in hardware, in order to
add SHA-3 support in SPU-2 driver we needed to have the
software implementation and test framework in place.
The patchset is based on v4.7-rc1 tag and its tested on
Broadcom NorthStar2 SoC.
The patch set can be fetched from iproc-sha3-v2 branch
of https://github.com/Broadcom/arm64-linux.git
Changes since v1:
- Renamed MODULE_ALIAS to MODULE_ALIAS_CRYPTO
- Added aliases for below cra_driver_name's
sha3-224-generic
sha3-256-generic
sha3-384-generic
sha3-512-generic
Jeff Garzik (1):
Crypto: Add SHA-3 hash algorithm
Raveendra Padasalagi (1):
Crypto: Add SHA-3 Test's in tcrypt
crypto/Kconfig | 10 ++
crypto/Makefile | 1 +
crypto/sha3_generic.c | 300 ++++++++++++++++++++++++++++++++++++++++++++++++++
crypto/tcrypt.c | 53 ++++++++-
crypto/testmgr.c | 40 +++++++
crypto/testmgr.h | 125 +++++++++++++++++++++
include/crypto/sha3.h | 29 +++++
7 files changed, 557 insertions(+), 1 deletion(-)
create mode 100644 crypto/sha3_generic.c
create mode 100644 include/crypto/sha3.h
--
1.9.1
^ permalink raw reply
* [PATCH v2 2/2] Crypto: Add SHA-3 Test's in tcrypt
From: Raveendra Padasalagi @ 2016-06-17 5:00 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Raveendra Padasalagi
In-Reply-To: <1466139636-19779-1-git-send-email-raveendra.padasalagi@broadcom.com>
Added support for SHA-3 algorithm test's
in tcrypt module and related test vectors.
Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
---
crypto/tcrypt.c | 53 ++++++++++++++++++++++-
crypto/testmgr.c | 40 ++++++++++++++++++
crypto/testmgr.h | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 217 insertions(+), 1 deletion(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 579dce0..4675459 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -72,7 +72,8 @@ static char *check[] = {
"cast6", "arc4", "michael_mic", "deflate", "crc32c", "tea", "xtea",
"khazad", "wp512", "wp384", "wp256", "tnepres", "xeta", "fcrypt",
"camellia", "seed", "salsa20", "rmd128", "rmd160", "rmd256", "rmd320",
- "lzo", "cts", "zlib", NULL
+ "lzo", "cts", "zlib", "sha3-224", "sha3-256", "sha3-384", "sha3-512",
+ NULL
};
struct tcrypt_result {
@@ -1284,6 +1285,22 @@ static int do_test(const char *alg, u32 type, u32 mask, int m)
ret += tcrypt_test("crct10dif");
break;
+ case 48:
+ ret += tcrypt_test("sha3-224");
+ break;
+
+ case 49:
+ ret += tcrypt_test("sha3-256");
+ break;
+
+ case 50:
+ ret += tcrypt_test("sha3-384");
+ break;
+
+ case 51:
+ ret += tcrypt_test("sha3-512");
+ break;
+
case 100:
ret += tcrypt_test("hmac(md5)");
break;
@@ -1691,6 +1708,22 @@ static int do_test(const char *alg, u32 type, u32 mask, int m)
test_hash_speed("poly1305", sec, poly1305_speed_template);
if (mode > 300 && mode < 400) break;
+ case 322:
+ test_hash_speed("sha3-224", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
+ case 323:
+ test_hash_speed("sha3-256", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
+ case 324:
+ test_hash_speed("sha3-384", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
+ case 325:
+ test_hash_speed("sha3-512", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
case 399:
break;
@@ -1770,6 +1803,24 @@ static int do_test(const char *alg, u32 type, u32 mask, int m)
test_ahash_speed("rmd320", sec, generic_hash_speed_template);
if (mode > 400 && mode < 500) break;
+ case 418:
+ test_ahash_speed("sha3-224", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+ case 419:
+ test_ahash_speed("sha3-256", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+ case 420:
+ test_ahash_speed("sha3-384", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+
+ case 421:
+ test_ahash_speed("sha3-512", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+
case 499:
break;
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c727fb0..b773a56 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3659,6 +3659,46 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "sha3-224",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_224_tv_template,
+ .count = SHA3_224_TEST_VECTORS
+ }
+ }
+ }, {
+ .alg = "sha3-256",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_256_tv_template,
+ .count = SHA3_256_TEST_VECTORS
+ }
+ }
+ }, {
+ .alg = "sha3-384",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_384_tv_template,
+ .count = SHA3_384_TEST_VECTORS
+ }
+ }
+ }, {
+ .alg = "sha3-512",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_512_tv_template,
+ .count = SHA3_512_TEST_VECTORS
+ }
+ }
+ }, {
.alg = "sha384",
.test = alg_test_hash,
.fips_allowed = 1,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 487ec88..b70e3c9 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -376,6 +376,131 @@ static struct hash_testvec md4_tv_template [] = {
},
};
+#define SHA3_224_TEST_VECTORS 3
+static struct hash_testvec sha3_224_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\x6b\x4e\x03\x42\x36\x67\xdb\xb7"
+ "\x3b\x6e\x15\x45\x4f\x0e\xb1\xab"
+ "\xd4\x59\x7f\x9a\x1b\x07\x8e\x3f"
+ "\x5b\x5a\x6b\xc7",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x9e\x86\xff\x69\x55\x7c\xa9\x5f"
+ "\x40\x5f\x08\x12\x69\x68\x5b\x38"
+ "\xe3\xa8\x19\xb3\x09\xee\x94\x2f"
+ "\x48\x2b\x6a\x8b",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x8a\x24\x10\x8b\x15\x4a\xda\x21"
+ "\xc9\xfd\x55\x74\x49\x44\x79\xba"
+ "\x5c\x7e\x7a\xb7\x6e\xf2\x64\xea"
+ "\xd0\xfc\xce\x33",
+ },
+};
+
+#define SHA3_256_TEST_VECTORS 3
+static struct hash_testvec sha3_256_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\xa7\xff\xc6\xf8\xbf\x1e\xd7\x66"
+ "\x51\xc1\x47\x56\xa0\x61\xd6\x62"
+ "\xf5\x80\xff\x4d\xe4\x3b\x49\xfa"
+ "\x82\xd8\x0a\x4b\x80\xf8\x43\x4a",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x80\x08\x4b\xf2\xfb\xa0\x24\x75"
+ "\x72\x6f\xeb\x2c\xab\x2d\x82\x15"
+ "\xea\xb1\x4b\xc6\xbd\xd8\xbf\xb2"
+ "\xc8\x15\x12\x57\x03\x2e\xcd\x8b",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x41\xc0\xdb\xa2\xa9\xd6\x24\x08"
+ "\x49\x10\x03\x76\xa8\x23\x5e\x2c"
+ "\x82\xe1\xb9\x99\x8a\x99\x9e\x21"
+ "\xdb\x32\xdd\x97\x49\x6d\x33\x76",
+ },
+};
+
+
+#define SHA3_384_TEST_VECTORS 3
+static struct hash_testvec sha3_384_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\x0c\x63\xa7\x5b\x84\x5e\x4f\x7d"
+ "\x01\x10\x7d\x85\x2e\x4c\x24\x85"
+ "\xc5\x1a\x50\xaa\xaa\x94\xfc\x61"
+ "\x99\x5e\x71\xbb\xee\x98\x3a\x2a"
+ "\xc3\x71\x38\x31\x26\x4a\xdb\x47"
+ "\xfb\x6b\xd1\xe0\x58\xd5\xf0\x04",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x18\x15\xf7\x74\xf3\x20\x49\x1b"
+ "\x48\x56\x9e\xfe\xc7\x94\xd2\x49"
+ "\xee\xb5\x9a\xae\x46\xd2\x2b\xf7"
+ "\x7d\xaf\xe2\x5c\x5e\xdc\x28\xd7"
+ "\xea\x44\xf9\x3e\xe1\x23\x4a\xa8"
+ "\x8f\x61\xc9\x19\x12\xa4\xcc\xd9",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x99\x1c\x66\x57\x55\xeb\x3a\x4b"
+ "\x6b\xbd\xfb\x75\xc7\x8a\x49\x2e"
+ "\x8c\x56\xa2\x2c\x5c\x4d\x7e\x42"
+ "\x9b\xfd\xbc\x32\xb9\xd4\xad\x5a"
+ "\xa0\x4a\x1f\x07\x6e\x62\xfe\xa1"
+ "\x9e\xef\x51\xac\xd0\x65\x7c\x22",
+ },
+};
+
+
+#define SHA3_512_TEST_VECTORS 3
+static struct hash_testvec sha3_512_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\xa6\x9f\x73\xcc\xa2\x3a\x9a\xc5"
+ "\xc8\xb5\x67\xdc\x18\x5a\x75\x6e"
+ "\x97\xc9\x82\x16\x4f\xe2\x58\x59"
+ "\xe0\xd1\xdc\xc1\x47\x5c\x80\xa6"
+ "\x15\xb2\x12\x3a\xf1\xf5\xf9\x4c"
+ "\x11\xe3\xe9\x40\x2c\x3a\xc5\x58"
+ "\xf5\x00\x19\x9d\x95\xb6\xd3\xe3"
+ "\x01\x75\x85\x86\x28\x1d\xcd\x26",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x69\x7f\x2d\x85\x61\x72\xcb\x83"
+ "\x09\xd6\xb8\xb9\x7d\xac\x4d\xe3"
+ "\x44\xb5\x49\xd4\xde\xe6\x1e\xdf"
+ "\xb4\x96\x2d\x86\x98\xb7\xfa\x80"
+ "\x3f\x4f\x93\xff\x24\x39\x35\x86"
+ "\xe2\x8b\x5b\x95\x7a\xc3\xd1\xd3"
+ "\x69\x42\x0c\xe5\x33\x32\x71\x2f"
+ "\x99\x7b\xd3\x36\xd0\x9a\xb0\x2a",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x04\xa3\x71\xe8\x4e\xcf\xb5\xb8"
+ "\xb7\x7c\xb4\x86\x10\xfc\xa8\x18"
+ "\x2d\xd4\x57\xce\x6f\x32\x6a\x0f"
+ "\xd3\xd7\xec\x2f\x1e\x91\x63\x6d"
+ "\xee\x69\x1f\xbe\x0c\x98\x53\x02"
+ "\xba\x1b\x0d\x8d\xc7\x8c\x08\x63"
+ "\x46\xb5\x33\xb4\x9c\x03\x0d\x99"
+ "\xa2\x7d\xaf\x11\x39\xd6\xe7\x5e",
+ },
+};
+
+
/*
* MD5 test vectors from RFC1321
*/
--
1.9.1
^ permalink raw reply related
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