* [PATCH 16/28] ARM: DRA7: hwmod: Add data for DES IP
From: Tero Kristo @ 2016-06-01 9:04 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Joel Fernandes <joelf@ti.com>
DRA7 SoC contains DES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Joel Fernandes <joelf@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37 +++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d0e7e525..13e4ea2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2541,6 +2541,34 @@ static struct omap_hwmod dra7xx_uart10_hwmod = {
},
};
+/* DES (the 'P' (public) device) */
+static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = {
+ .rev_offs = 0x0030,
+ .sysc_offs = 0x0034,
+ .syss_offs = 0x0038,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class dra7xx_des_hwmod_class = {
+ .name = "des",
+ .sysc = &dra7xx_des_sysc,
+};
+
+/* DES */
+static struct omap_hwmod dra7xx_des_hwmod = {
+ .name = "des",
+ .class = &dra7xx_des_hwmod_class,
+ .clkdm_name = "l4sec_clkdm",
+ .main_clk = "l3_iclk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'usb_otg_ss' class
*
@@ -3683,6 +3711,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__uart7 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per1 -> des */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = {
+ .master = &dra7xx_l4_per1_hwmod,
+ .slave = &dra7xx_des_hwmod,
+ .clk = "l3_iclk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_per2 -> uart8 */
static struct omap_hwmod_ocp_if dra7xx_l4_per2__uart8 = {
.master = &dra7xx_l4_per2_hwmod,
@@ -3916,6 +3952,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l4_per2__uart8,
&dra7xx_l4_per2__uart9,
&dra7xx_l4_wkup__uart10,
+ &dra7xx_l4_per1__des,
&dra7xx_l4_per3__usb_otg_ss1,
&dra7xx_l4_per3__usb_otg_ss2,
&dra7xx_l4_per3__usb_otg_ss3,
--
1.9.1
^ permalink raw reply related
* [PATCH 14/28] crypto: omap-aes: fix crypto engine initialization order
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
The crypto engine must be initialized before registering algorithms,
otherwise the test manager will crash as it attempts to execute
tests for the algos while they are being registered.
Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 867e56a..2d0978a 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1204,6 +1204,17 @@ static int omap_aes_probe(struct platform_device *pdev)
list_add_tail(&dd->list, &dev_list);
spin_unlock(&list_lock);
+ /* Initialize crypto engine */
+ dd->engine = crypto_engine_alloc_init(dev, 1);
+ if (!dd->engine)
+ goto err_engine;
+
+ dd->engine->prepare_request = omap_aes_prepare_req;
+ dd->engine->crypt_one_request = omap_aes_crypt_req;
+ err = crypto_engine_start(dd->engine);
+ if (err)
+ goto err_engine;
+
for (i = 0; i < dd->pdata->algs_info_size; i++) {
if (!dd->pdata->algs_info[i].registered) {
for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
@@ -1221,26 +1232,17 @@ static int omap_aes_probe(struct platform_device *pdev)
}
}
- /* Initialize crypto engine */
- dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
- goto err_algs;
-
- dd->engine->prepare_request = omap_aes_prepare_req;
- dd->engine->crypt_one_request = omap_aes_crypt_req;
- err = crypto_engine_start(dd->engine);
- if (err)
- goto err_engine;
-
return 0;
-err_engine:
- crypto_engine_exit(dd->engine);
err_algs:
for (i = dd->pdata->algs_info_size - 1; i >= 0; i--)
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_alg(
&dd->pdata->algs_info[i].algs_list[j]);
+err_engine:
+ if (dd->engine)
+ crypto_engine_exit(dd->engine);
+
omap_aes_dma_cleanup(dd);
err_irq:
tasklet_kill(&dd->done_task);
--
1.9.1
^ permalink raw reply related
* [PATCH 15/28] crypto: omap-des: fix crypto engine initialization order
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
The crypto engine must be initialized before registering algorithms,
otherwise the test manager will crash as it attempts to execute
tests for the algos while they are being registered.
Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-des.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index e4c87bc..f5bf0d1 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -1079,6 +1079,17 @@ static int omap_des_probe(struct platform_device *pdev)
list_add_tail(&dd->list, &dev_list);
spin_unlock(&list_lock);
+ /* Initialize des crypto engine */
+ dd->engine = crypto_engine_alloc_init(dev, 1);
+ if (!dd->engine)
+ goto err_engine;
+
+ dd->engine->prepare_request = omap_des_prepare_req;
+ dd->engine->crypt_one_request = omap_des_crypt_req;
+ err = crypto_engine_start(dd->engine);
+ if (err)
+ goto err_engine;
+
for (i = 0; i < dd->pdata->algs_info_size; i++) {
for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
algp = &dd->pdata->algs_info[i].algs_list[j];
@@ -1094,27 +1105,18 @@ static int omap_des_probe(struct platform_device *pdev)
}
}
- /* Initialize des crypto engine */
- dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
- goto err_algs;
-
- dd->engine->prepare_request = omap_des_prepare_req;
- dd->engine->crypt_one_request = omap_des_crypt_req;
- err = crypto_engine_start(dd->engine);
- if (err)
- goto err_engine;
-
return 0;
-err_engine:
- crypto_engine_exit(dd->engine);
err_algs:
for (i = dd->pdata->algs_info_size - 1; i >= 0; i--)
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_alg(
&dd->pdata->algs_info[i].algs_list[j]);
+err_engine:
+ if (dd->engine)
+ crypto_engine_exit(dd->engine);
+
omap_des_dma_cleanup(dd);
err_irq:
tasklet_kill(&dd->done_task);
--
1.9.1
^ permalink raw reply related
* [PATCH 13/28] crypto: engine: avoid unnecessary context switches
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
Crypto engine will now hi-jack the currently running thread for executing
crypto functionality. Only if we are not running a thread (in interrupt
context) the kthread will be scheduled.
This will improve performance of crypto operations using crypto engine.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
crypto/crypto_engine.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index a55c82d..aac5870 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -136,6 +136,14 @@ static void crypto_pump_work(struct kthread_work *work)
crypto_pump_requests(engine, true);
}
+static void queue_pump_work(struct crypto_engine *engine)
+{
+ if (in_interrupt())
+ queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ else
+ crypto_pump_requests(engine, true);
+}
+
/**
* crypto_transfer_request - transfer the new request into the engine queue
* @engine: the hardware engine
@@ -156,10 +164,11 @@ int crypto_transfer_request(struct crypto_engine *engine,
ret = ablkcipher_enqueue_request(&engine->queue, req);
+ spin_unlock_irqrestore(&engine->queue_lock, flags);
+
if (!engine->busy && need_pump)
- queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ queue_pump_work(engine);
- spin_unlock_irqrestore(&engine->queue_lock, flags);
return ret;
}
EXPORT_SYMBOL_GPL(crypto_transfer_request);
@@ -210,7 +219,7 @@ void crypto_finalize_request(struct crypto_engine *engine,
req->base.complete(&req->base, err);
- queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ queue_pump_work(engine);
}
EXPORT_SYMBOL_GPL(crypto_finalize_request);
@@ -234,7 +243,7 @@ int crypto_engine_start(struct crypto_engine *engine)
engine->running = true;
spin_unlock_irqrestore(&engine->queue_lock, flags);
- queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ queue_pump_work(engine);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 12/28] crypto: omap-aes: Add fallback support
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
As setting up the DMA operations is quite costly, add software fallback
support for requests smaller than 200 bytes. This change gives some 10%
extra performance in ipsec use case.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/Kconfig | 3 +++
drivers/crypto/omap-aes.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index d77ba2f..0c57ac9 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -305,6 +305,9 @@ config CRYPTO_DEV_OMAP_AES
select CRYPTO_AES
select CRYPTO_BLKCIPHER
select CRYPTO_ENGINE
+ select CRYPTO_CBC
+ select CRYPTO_ECB
+ select CRYPTO_CTR
help
OMAP processors have AES module accelerator. Select this if you
want to use the OMAP module for AES algorithms.
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index f710602..867e56a 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -103,6 +103,7 @@ struct omap_aes_ctx {
int keylen;
u32 key[AES_KEYSIZE_256 / sizeof(u32)];
unsigned long flags;
+ struct crypto_ablkcipher *fallback;
};
struct omap_aes_reqctx {
@@ -680,15 +681,28 @@ static void omap_aes_done_task(unsigned long data)
static int omap_aes_crypt(struct ablkcipher_request *req, unsigned long mode)
{
+ struct crypto_tfm *tfm =
+ crypto_ablkcipher_tfm(crypto_ablkcipher_reqtfm(req));
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_aes_reqctx *rctx = ablkcipher_request_ctx(req);
struct omap_aes_dev *dd;
+ int ret;
pr_debug("nbytes: %d, enc: %d, cbc: %d\n", req->nbytes,
!!(mode & FLAGS_ENCRYPT),
!!(mode & FLAGS_CBC));
+ if (req->nbytes < 200) {
+ ablkcipher_request_set_tfm(req, ctx->fallback);
+
+ if (mode & FLAGS_ENCRYPT)
+ ret = crypto_ablkcipher_encrypt(req);
+ else
+ ret = crypto_ablkcipher_decrypt(req);
+ ablkcipher_request_set_tfm(req, __crypto_ablkcipher_cast(tfm));
+ return ret;
+ }
dd = omap_aes_find_dev(ctx);
if (!dd)
return -ENODEV;
@@ -704,6 +718,7 @@ static int omap_aes_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen)
{
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(tfm);
+ int ret;
if (keylen != AES_KEYSIZE_128 && keylen != AES_KEYSIZE_192 &&
keylen != AES_KEYSIZE_256)
@@ -714,6 +729,14 @@ static int omap_aes_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
memcpy(ctx->key, key, keylen);
ctx->keylen = keylen;
+ ctx->fallback->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+ ctx->fallback->base.crt_flags |=
+ tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK;
+
+ ret = crypto_ablkcipher_setkey(ctx->fallback, key, keylen);
+ if (!ret)
+ return 0;
+
return 0;
}
@@ -751,6 +774,11 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
struct omap_aes_dev *dd = NULL;
int err;
+ const char *name = crypto_tfm_alg_name(tfm);
+ const u32 flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK;
+ struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct crypto_ablkcipher *blk;
+
list_for_each_entry(dd, &dev_list, list) {
err = pm_runtime_get_sync(dd->dev);
@@ -761,6 +789,12 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
}
}
+ blk = crypto_alloc_ablkcipher(name, 0, flags);
+ if (IS_ERR(blk))
+ return PTR_ERR(blk);
+
+ ctx->fallback = blk;
+
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -769,11 +803,16 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
struct omap_aes_dev *dd = NULL;
+ struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
list_for_each_entry(dd, &dev_list, list) {
pm_runtime_put_sync(dd->dev);
}
+ if (ctx->fallback)
+ crypto_free_ablkcipher(ctx->fallback);
+
+ ctx->fallback = NULL;
}
/* ********************** ALGS ************************************ */
@@ -785,7 +824,7 @@ static struct crypto_alg algs_ecb_cbc[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
@@ -807,7 +846,7 @@ static struct crypto_alg algs_ecb_cbc[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
@@ -833,7 +872,7 @@ static struct crypto_alg algs_ctr[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
--
1.9.1
^ permalink raw reply related
* [PATCH 11/28] crypto: omap-aes: Add support for multiple cores
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Some SoCs like omap4/omap5/dra7 contain multiple AES crypto accelerator
cores. Adapt the driver to support this. The driver picks the last used
device from a list of AES devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: forward ported to 4.7 kernel]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index cf53d3f..f710602 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -319,20 +319,12 @@ static void omap_aes_dma_stop(struct omap_aes_dev *dd)
static struct omap_aes_dev *omap_aes_find_dev(struct omap_aes_ctx *ctx)
{
- struct omap_aes_dev *dd = NULL, *tmp;
+ struct omap_aes_dev *dd;
spin_lock_bh(&list_lock);
- if (!ctx->dd) {
- list_for_each_entry(tmp, &dev_list, list) {
- /* FIXME: take fist available aes core */
- dd = tmp;
- break;
- }
- ctx->dd = dd;
- } else {
- /* already found before */
- dd = ctx->dd;
- }
+ dd = list_first_entry(&dev_list, struct omap_aes_dev, list);
+ list_move_tail(&dd->list, &dev_list);
+ ctx->dd = dd;
spin_unlock_bh(&list_lock);
return dd;
@@ -600,7 +592,7 @@ static int omap_aes_prepare_req(struct crypto_engine *engine,
{
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
- struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
+ struct omap_aes_dev *dd = ctx->dd;
struct omap_aes_reqctx *rctx;
int len;
@@ -644,7 +636,7 @@ static int omap_aes_crypt_req(struct crypto_engine *engine,
{
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
- struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
+ struct omap_aes_dev *dd = ctx->dd;
if (!dd)
return -ENODEV;
--
1.9.1
^ permalink raw reply related
* [PATCH 10/28] crypto: omap-aes - Fix enabling clocks
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Enable clocks for all cores before starting session.
Driver has to pic the aes core dynamically based on the queue length.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/crypto/omap-aes.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 8178632..cf53d3f 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -760,18 +760,13 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
struct omap_aes_dev *dd = NULL;
int err;
- /* Find AES device, currently picks the first device */
- spin_lock_bh(&list_lock);
list_for_each_entry(dd, &dev_list, list) {
- break;
- }
- spin_unlock_bh(&list_lock);
-
- err = pm_runtime_get_sync(dd->dev);
- if (err < 0) {
- dev_err(dd->dev, "%s: failed to get_sync(%d)\n",
- __func__, err);
- return err;
+ err = pm_runtime_get_sync(dd->dev);
+ if (err < 0) {
+ dev_err(dd->dev, "%s: failed to get_sync(%d)\n",
+ __func__, err);
+ return err;
+ }
}
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
@@ -783,14 +778,10 @@ static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
struct omap_aes_dev *dd = NULL;
- /* Find AES device, currently picks the first device */
- spin_lock_bh(&list_lock);
list_for_each_entry(dd, &dev_list, list) {
- break;
+ pm_runtime_put_sync(dd->dev);
}
- spin_unlock_bh(&list_lock);
- pm_runtime_put_sync(dd->dev);
}
/* ********************** ALGS ************************************ */
--
1.9.1
^ permalink raw reply related
* [PATCH 09/28] crypto: omap-des: Fix support for unequal lengths
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <a0131933@ti.com>
For cases where total length of an input SGs is not same as
length of the input data for encryption, omap-des driver
crashes. This happens in the case when IPsec is trying to use
omap-des driver.
To avoid this, we copy all the pages from the input SG list
into a contiguous buffer and prepare a single element SG list
for this buffer with length as the total bytes to crypt, which is
similar thing that is done in case of unaligned lengths.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-des.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 3eedb03..e4c87bc 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -521,29 +521,36 @@ static int omap_des_crypt_dma_stop(struct omap_des_dev *dd)
return 0;
}
-static int omap_des_copy_needed(struct scatterlist *sg)
+static int omap_des_copy_needed(struct scatterlist *sg, int total)
{
+ int len = 0;
+
+ if (!IS_ALIGNED(total, DES_BLOCK_SIZE))
+ return -1;
+
while (sg) {
if (!IS_ALIGNED(sg->offset, 4))
return -1;
if (!IS_ALIGNED(sg->length, DES_BLOCK_SIZE))
return -1;
+
+ len += sg->length;
sg = sg_next(sg);
}
+
+ if (len != total)
+ return -1;
+
return 0;
}
static int omap_des_copy_sgs(struct omap_des_dev *dd)
{
void *buf_in, *buf_out;
- int pages;
-
- pages = dd->total >> PAGE_SHIFT;
-
- if (dd->total & (PAGE_SIZE-1))
- pages++;
+ int pages, total;
- BUG_ON(!pages);
+ total = ALIGN(dd->total, DES_BLOCK_SIZE);
+ pages = get_order(total);
buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
buf_out = (void *)__get_free_pages(GFP_ATOMIC, pages);
@@ -595,8 +602,8 @@ static int omap_des_prepare_req(struct crypto_engine *engine,
dd->in_sg = req->src;
dd->out_sg = req->dst;
- if (omap_des_copy_needed(dd->in_sg) ||
- omap_des_copy_needed(dd->out_sg)) {
+ if (omap_des_copy_needed(dd->in_sg, dd->total) ||
+ omap_des_copy_needed(dd->out_sg, dd->total)) {
if (omap_des_copy_sgs(dd))
pr_err("Failed to copy SGs for unaligned cases\n");
dd->sgs_copied = 1;
--
1.9.1
^ permalink raw reply related
* [PATCH 08/28] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
Context export/import are now required for ahash algorithms due to
required support in algif_hash. Implement these for OMAP SHA driver,
saving and restoring the internal state of the driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 40 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 34ebe1d..321c097 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1329,6 +1329,35 @@ static void omap_sham_cra_exit(struct crypto_tfm *tfm)
pm_runtime_get_sync(dd->dev);
}
+static int omap_sham_export(struct ahash_request *req, void *out)
+{
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
+ struct omap_sham_ctx *ctx = crypto_ahash_ctx(tfm);
+ struct omap_sham_hmac_ctx *bctx = ctx->base;
+
+ memcpy(out, rctx, sizeof(*rctx) + BUFLEN);
+ memcpy(out + sizeof(*rctx) + BUFLEN, ctx, sizeof(*ctx));
+ memcpy(out + sizeof(*rctx) + BUFLEN + sizeof(*ctx), bctx,
+ sizeof(*bctx));
+
+ return 0;
+}
+
+static int omap_sham_import(struct ahash_request *req, const void *in)
+{
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
+ struct omap_sham_ctx *ctx = crypto_ahash_ctx(tfm);
+ struct omap_sham_hmac_ctx *bctx = ctx->base;
+
+ memcpy(rctx, in, sizeof(*rctx) + BUFLEN);
+ memcpy(ctx, in + sizeof(*rctx) + BUFLEN, sizeof(*ctx));
+ memcpy(bctx, in + sizeof(*rctx) + BUFLEN + sizeof(*ctx), sizeof(*bctx));
+
+ return 0;
+}
+
static struct ahash_alg algs_sha1_md5[] = {
{
.init = omap_sham_init,
@@ -1980,8 +2009,15 @@ static int omap_sham_probe(struct platform_device *pdev)
for (i = 0; i < dd->pdata->algs_info_size; i++) {
for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
- err = crypto_register_ahash(
- &dd->pdata->algs_info[i].algs_list[j]);
+ struct ahash_alg *alg;
+
+ alg = &dd->pdata->algs_info[i].algs_list[j];
+ alg->export = omap_sham_export;
+ alg->import = omap_sham_import;
+ alg->halg.statesize = sizeof(struct omap_sham_reqctx) +
+ sizeof(struct omap_sham_ctx) +
+ sizeof(struct omap_sham_hmac_ctx) + BUFLEN;
+ err = crypto_register_ahash(alg);
if (err)
goto err_algs;
--
1.9.1
^ permalink raw reply related
* [PATCH 06/28] crypto: omap-sham: avoid executing tasklet where not needed
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
Some of the call paths of OMAP SHA driver can avoid executing the next
step of the crypto queue under tasklet; instead, execute the next step
directly via function call. This avoids a costly round-trip via the
scheduler giving a slight performance boost.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a5c823b..34ebe1d 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -240,6 +240,8 @@ static struct omap_sham_drv sham = {
.lock = __SPIN_LOCK_UNLOCKED(sham.lock),
};
+static void omap_sham_done_task(unsigned long data);
+
static inline u32 omap_sham_read(struct omap_sham_dev *dd, u32 offset)
{
return __raw_readl(dd->io_base + offset);
@@ -994,7 +996,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
req->base.complete(&req->base, err);
/* handle new request */
- tasklet_schedule(&dd->done_task);
+ omap_sham_done_task((unsigned long)dd);
}
static int omap_sham_handle_queue(struct omap_sham_dev *dd,
--
1.9.1
^ permalink raw reply related
* [PATCH 07/28] crypto: ahash: increase the maximum allowed statesize
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
The statesize is used to determine the maximum size for saved ahash
context. In some cases, this can be much larger than what is currently
allocated for it, for example omap-sham driver uses a buffer size of
PAGE_SIZE. Increase the statesize to accommodate this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
crypto/ahash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 3887a98..375bbd7 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -536,7 +536,7 @@ static int ahash_prepare_alg(struct ahash_alg *alg)
struct crypto_alg *base = &alg->halg.base;
if (alg->halg.digestsize > PAGE_SIZE / 8 ||
- alg->halg.statesize > PAGE_SIZE / 8 ||
+ alg->halg.statesize > PAGE_SIZE * 2 ||
alg->halg.statesize == 0)
return -EINVAL;
--
1.9.1
^ permalink raw reply related
* [PATCH 05/28] crypto: omap-sham: set sw fallback to 240 bytes
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Bin Liu, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Bin Liu <b-liu@ti.com>
Adds software fallback support for small crypto requests. In these cases,
it is undesirable to use DMA, as setting it up itself is rather heavy
operation. Gives about 40% extra performance in ipsec usecase.
Signed-off-by: Bin Liu <b-liu@ti.com>
[t-kristo@ti.com: dropped the extra traces, updated some comments
on the code]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 287bc43..a5c823b 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1082,7 +1082,7 @@ static int omap_sham_update(struct ahash_request *req)
ctx->offset = 0;
if (ctx->flags & BIT(FLAGS_FINUP)) {
- if ((ctx->digcnt + ctx->bufcnt + ctx->total) < 9) {
+ if ((ctx->digcnt + ctx->bufcnt + ctx->total) < 240) {
/*
* OMAP HW accel works only with buffers >= 9
* will switch to bypass in final()
@@ -1138,9 +1138,13 @@ static int omap_sham_final(struct ahash_request *req)
if (ctx->flags & BIT(FLAGS_ERROR))
return 0; /* uncompleted hash is not needed */
- /* OMAP HW accel works only with buffers >= 9 */
- /* HMAC is always >= 9 because ipad == block size */
- if ((ctx->digcnt + ctx->bufcnt) < 9)
+ /*
+ * OMAP HW accel works only with buffers >= 9.
+ * HMAC is always >= 9 because ipad == block size.
+ * If buffersize is less than 240, we use fallback SW encoding,
+ * as using DMA + HW in this case doesn't provide any benefit.
+ */
+ if ((ctx->digcnt + ctx->bufcnt) < 240)
return omap_sham_final_shash(req);
else if (ctx->bufcnt)
return omap_sham_enqueue(req, OP_FINAL);
--
1.9.1
^ permalink raw reply related
* [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Calling runtime PM API for every block causes serious perf hit to
crypto operations that are done on a long buffer.
As crypto is performed on a page boundary, encrypting large buffers can
cause a series of crypto operations divided by page. The runtime PM API
is also called those many times.
We call runtime_pm_get_sync only at beginning on the session (cra_init)
and runtime_pm_put at the end. This result in upto a 50% speedup.
This doesn't make the driver to keep the system awake as runtime get/put
is only called during a crypto session which completes usually quickly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 6eefaa2..bd0258f 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -360,14 +360,6 @@ static void omap_sham_copy_ready_hash(struct ahash_request *req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- int err;
-
- err = pm_runtime_get_sync(dd->dev);
- if (err < 0) {
- dev_err(dd->dev, "failed to get sync: %d\n", err);
- return err;
- }
-
if (!test_bit(FLAGS_INIT, &dd->flags)) {
set_bit(FLAGS_INIT, &dd->flags);
dd->err = 0;
@@ -999,8 +991,6 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
- pm_runtime_put(dd->dev);
-
if (req->base.complete)
req->base.complete(&req->base, err);
@@ -1239,6 +1229,7 @@ static int omap_sham_cra_init_alg(struct crypto_tfm *tfm, const char *alg_base)
{
struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
const char *alg_name = crypto_tfm_alg_name(tfm);
+ struct omap_sham_dev *dd;
/* Allocate a fallback and abort if it failed. */
tctx->fallback = crypto_alloc_shash(alg_name, 0,
@@ -1266,6 +1257,13 @@ static int omap_sham_cra_init_alg(struct crypto_tfm *tfm, const char *alg_base)
}
+ spin_lock_bh(&sham.lock);
+ list_for_each_entry(dd, &sham.dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(&sham.lock);
+
+ pm_runtime_get_sync(dd->dev);
return 0;
}
@@ -1307,6 +1305,7 @@ static int omap_sham_cra_sha512_init(struct crypto_tfm *tfm)
static void omap_sham_cra_exit(struct crypto_tfm *tfm)
{
struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
+ struct omap_sham_dev *dd;
crypto_free_shash(tctx->fallback);
tctx->fallback = NULL;
@@ -1315,6 +1314,14 @@ static void omap_sham_cra_exit(struct crypto_tfm *tfm)
struct omap_sham_hmac_ctx *bctx = tctx->base;
crypto_free_shash(bctx->shash);
}
+
+ spin_lock_bh(&sham.lock);
+ list_for_each_entry(dd, &sham.dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(&sham.lock);
+
+ pm_runtime_get_sync(dd->dev);
}
static struct ahash_alg algs_sha1_md5[] = {
--
1.9.1
^ permalink raw reply related
* [PATCH 03/28] crypto: omap-sham: change queue size from 1 to 10
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
Change crypto queue size from 1 to 10 for omap SHA driver. This should
allow clients to enqueue requests more effectively to avoid serializing
whole crypto sequences, giving extra performance.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index bd0258f..71eac5c 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -173,7 +173,7 @@ struct omap_sham_ctx {
struct omap_sham_hmac_ctx base[0];
};
-#define OMAP_SHAM_QUEUE_LENGTH 1
+#define OMAP_SHAM_QUEUE_LENGTH 10
struct omap_sham_algs_info {
struct ahash_alg *algs_list;
--
1.9.1
^ permalink raw reply related
* [PATCH 04/28] crypto: omap: do not call dmaengine_terminate_all
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: linux-arm-kernel, lokeshvutla, Tero Kristo
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
The extra call to dmaengine_terminate_all is not needed, as the DMA
is not running at this point. This improves performance slightly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 2 --
drivers/crypto/omap-sham.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 4a0e6a5..8178632 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -528,8 +528,6 @@ static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
omap_aes_dma_stop(dd);
- dmaengine_terminate_all(dd->dma_lch_in);
- dmaengine_terminate_all(dd->dma_lch_out);
return 0;
}
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 71eac5c..287bc43 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -805,7 +805,6 @@ static int omap_sham_update_dma_stop(struct omap_sham_dev *dd)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
- dmaengine_terminate_all(dd->dma_lch);
if (ctx->flags & BIT(FLAGS_SG)) {
dma_unmap_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE);
--
1.9.1
^ permalink raw reply related
* [PATCH 01/28] crypto: omap-aes: Fix registration of algorithms
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: lokeshvutla, Tero Kristo, linux-arm-kernel
In-Reply-To: <1464771389-10640-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Algorithms can be registered only once. So skip registration of
algorithms if already registered (i.e. in case we have two AES cores
in the system.)
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce174d3..4a0e6a5 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1185,17 +1185,19 @@ static int omap_aes_probe(struct platform_device *pdev)
spin_unlock(&list_lock);
for (i = 0; i < dd->pdata->algs_info_size; i++) {
- for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
- algp = &dd->pdata->algs_info[i].algs_list[j];
+ if (!dd->pdata->algs_info[i].registered) {
+ for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
+ algp = &dd->pdata->algs_info[i].algs_list[j];
- pr_debug("reg alg: %s\n", algp->cra_name);
- INIT_LIST_HEAD(&algp->cra_list);
+ pr_debug("reg alg: %s\n", algp->cra_name);
+ INIT_LIST_HEAD(&algp->cra_list);
- err = crypto_register_alg(algp);
- if (err)
- goto err_algs;
+ err = crypto_register_alg(algp);
+ if (err)
+ goto err_algs;
- dd->pdata->algs_info[i].registered++;
+ dd->pdata->algs_info[i].registered++;
+ }
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH 00/28] crypto: omap fixes / support additions
From: Tero Kristo @ 2016-06-01 8:56 UTC (permalink / raw)
To: linux-omap, linux-crypto, herbert, davem, tony
Cc: lokeshvutla, linux-arm-kernel
Hi,
This series adds support for crypto hardware accelerators on TI DRA7xx
and AM43xx SoCs, and fixes a number of bugs in the existing codebase.
This series also addresses performance issues with the AES / SHA
accelerators, doing some optimizations on these.
Patch #7 and #13 are generic crypto API implementation changes.
Without #7, omap-sham export/import does not work, #13 is kind
of nice to have.
Patches 16+ should be picked-up / acked by Tony, but they have
dependencies on the preceding patches; at least the AES dual core
support must be in before applying the rest, otherwise bad things
will happen.
-Tero
^ permalink raw reply
* Re: (none)
From: Herbert Xu @ 2016-06-01 7:05 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: linux-crypto
In-Reply-To: <CAH8yC8==HPONkYSoPaa9E0b4+SKnbPEPeQatBUqc_HzJbD8DAA@mail.gmail.com>
On Wed, Jun 01, 2016 at 02:59:21AM -0400, Jeffrey Walton wrote:
>
> $ cat /proc/modules | egrep -i '(via|padlock|rng)'
> padlock_sha 16384 0 - Live 0x00000000
> padlock_aes 16384 0 - Live 0x00000000
> via_cputemp 16384 0 - Live 0x00000000
> hwmon_vid 16384 1 via_cputemp, Live 0x00000000
> via_rng 16384 0 - Live 0x00000000
> i2c_viapro 16384 0 - Live 0x00000000
> pata_via 16384 0 - Live 0x00000000
> sata_via 16384 2 - Live 0x00000000
OK, by default hwrng entropy is not fed into /dev/random.
You need to enable it by hand by setting default_quality on the
rng-core module to a non-zero value.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: (none)
From: Stephan Mueller @ 2016-06-01 7:05 UTC (permalink / raw)
To: noloader; +Cc: Herbert Xu, linux-crypto
In-Reply-To: <CAH8yC8==HPONkYSoPaa9E0b4+SKnbPEPeQatBUqc_HzJbD8DAA@mail.gmail.com>
Am Mittwoch, 1. Juni 2016, 02:59:21 schrieb Jeffrey Walton:
Hi Jeffrey,
> On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu <herbert@gondor.apana.org.au>
wrote:
> > On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
> >> I thought via-rng.c covers the VIA Padlock RNG?
> >
> > Indeed, you're quite right. In that case Jeffrey was the via-rng
> > driver loaded?
[...]
Ok, it is loaded. Did you use /dev/hw_random for getting data?
Ciao
Stephan
^ permalink raw reply
* Re: (none)
From: Jeffrey Walton @ 2016-06-01 6:59 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160601061947.GA32424@gondor.apana.org.au>
On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>>
>> I thought via-rng.c covers the VIA Padlock RNG?
>
> Indeed, you're quite right. In that case Jeffrey was the via-rng
> driver loaded?
$ cat /proc/modules | egrep -i '(via|padlock|rng)'
padlock_sha 16384 0 - Live 0x00000000
padlock_aes 16384 0 - Live 0x00000000
via_cputemp 16384 0 - Live 0x00000000
hwmon_vid 16384 1 via_cputemp, Live 0x00000000
via_rng 16384 0 - Live 0x00000000
i2c_viapro 16384 0 - Live 0x00000000
pata_via 16384 0 - Live 0x00000000
sata_via 16384 2 - Live 0x00000000
And:
$ lsmod | egrep -i '(via|padlock|rng)'
padlock_sha 16384 0
padlock_aes 16384 0
via_cputemp 16384 0
hwmon_vid 16384 1 via_cputemp
via_rng 16384 0
i2c_viapro 16384 0
pata_via 16384 0
sata_via 16384 2
And:
$ dmesg | egrep -i '(via|padlock|rng)'
[ 0.124003] smpboot: CPU0: Centaur VIA C7-D Processor 1800MHz (fam:
06, model: 0d, stepping: 00)
[ 0.263914] pci 0000:00:01.0: disabling DAC on VIA PCI bridge
[ 2.290795] agpgart: Detected VIA P4M900 chipset
[ 2.296875] agpgart-via 0000:00:00.0: AGP aperture is 128M @ 0xf0000000
[ 2.934927] sata_via 0000:00:0f.0: version 2.6
[ 2.935155] sata_via 0000:00:0f.0: routed to hard irq line 6
[ 2.948457] scsi host0: sata_via
[ 2.967744] scsi host1: sata_via
[ 2.968167] pata_via 0000:00:0f.1: version 0.3.4
[ 2.976090] scsi host2: pata_via
[ 2.982777] scsi host3: pata_via
[ 4.339291] systemd[1]: Set hostname to <via>.
[ 10.415938] VIA RNG detected
[ 11.257974] hwmon_vid: Using 6-bit VID table for VIA C7-D CPU
[ 12.100845] padlock_aes: Using VIA PadLock ACE for AES algorithm.
[ 12.149586] padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
[ 12.633495] input: HDA VIA VT82xx Rear Mic as
/devices/pci0000:80/0000:80:01.0/sound/card0/input9
[ 12.633720] input: HDA VIA VT82xx Line as
/devices/pci0000:80/0000:80:01.0/sound/card0/input10
[ 12.633927] input: HDA VIA VT82xx Headphone Front as
/devices/pci0000:80/0000:80:01.0/sound/card0/input11
^ permalink raw reply
* Re: (none)
From: Herbert Xu @ 2016-06-01 6:19 UTC (permalink / raw)
To: Stephan Mueller; +Cc: noloader, linux-crypto
In-Reply-To: <3022334.qkucHDndN1@tauon.atsec.com>
On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>
> I thought via-rng.c covers the VIA Padlock RNG?
Indeed, you're quite right. In that case Jeffrey was the via-rng
driver loaded?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: (none)
From: Stephan Mueller @ 2016-06-01 5:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: noloader, linux-crypto
In-Reply-To: <20160601045943.GA31881@gondor.apana.org.au>
Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu:
Hi Herbert,
> Jeffrey Walton <noloader@gmail.com> wrote:
> > Please forgive my ignorance here...
> >
> > I have test system with a VIA C7-M processor and PM-400 chipset. This
> > is one of those Thin Client/Internet of Things processor and chipsets
> > I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
> >
> > The processor includes the Padlock extensions. Padlock is similar to
> > Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's
> > instructions by about a decade.
> >
> > The Padlock Security Engine can produce a stream of random numbers at
> > megabits per socond, so I've been kind of surprised it has been
> >
> > suffering entropy depletion. Here's what the audit trail looks like:
> > Testing operating system provided blocking random number generator...
> > FAILED: it took 74 seconds to generate 5 bytes
> > passed: 5 generated bytes compressed to 7 bytes by DEFLATE
> >
> > Above, the blocking RNG is drained. Then, 16 bytes are requested. It
> > appears to take over one minute to gather five bytes when effectively
> > an endless stream is available.
> >
> > My question is, is this system expected to suffer entropy depletion
> > out of the box? Or are users expected to do something special so the
> > system does not fail?
>
> I don't think anybody has written either an hwrng driver or a rdrand
> hook for padlock. Patches are welcome.
I thought via-rng.c covers the VIA Padlock RNG?
Ciao
Stephan
^ permalink raw reply
* Re: (none)
From: Herbert Xu @ 2016-06-01 4:59 UTC (permalink / raw)
To: noloader; +Cc: linux-crypto
In-Reply-To: <CAH8yC8kZuhG92QJJgg27f0S1SrFp2RbMb19GuocfMYc++x9t3g@mail.gmail.com>
Jeffrey Walton <noloader@gmail.com> wrote:
> Please forgive my ignorance here...
>
> I have test system with a VIA C7-M processor and PM-400 chipset. This
> is one of those Thin Client/Internet of Things processor and chipsets
> I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
>
> The processor includes the Padlock extensions. Padlock is similar to
> Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's
> instructions by about a decade.
>
> The Padlock Security Engine can produce a stream of random numbers at
> megabits per socond, so I've been kind of surprised it has been
> suffering entropy depletion. Here's what the audit trail looks like:
>
> Testing operating system provided blocking random number generator...
> FAILED: it took 74 seconds to generate 5 bytes
> passed: 5 generated bytes compressed to 7 bytes by DEFLATE
>
> Above, the blocking RNG is drained. Then, 16 bytes are requested. It
> appears to take over one minute to gather five bytes when effectively
> an endless stream is available.
>
> My question is, is this system expected to suffer entropy depletion
> out of the box? Or are users expected to do something special so the
> system does not fail?
I don't think anybody has written either an hwrng driver or a rdrand
hook for padlock. Patches are welcome.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [RFC v3 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-06-01 4:58 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464756501.git.baolin.wang@linaro.org>
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than always 512
bytes and thus increase the hardware engine processing speed.
So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
mode.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/crypto/skcipher.h | 7 +++++++
include/linux/crypto.h | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 0f987f5..d89d29a 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -519,5 +519,12 @@ static inline void skcipher_request_set_crypt(
req->iv = iv;
}
+static inline unsigned int skcipher_is_bulk_mode(struct crypto_skcipher *sk_tfm)
+{
+ struct crypto_tfm *tfm = crypto_skcipher_tfm(sk_tfm);
+
+ return crypto_tfm_alg_bulk(tfm);
+}
+
#endif /* _CRYPTO_SKCIPHER_H */
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..a315487 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -63,6 +63,7 @@
#define CRYPTO_ALG_DEAD 0x00000020
#define CRYPTO_ALG_DYING 0x00000040
#define CRYPTO_ALG_ASYNC 0x00000080
+#define CRYPTO_ALG_BULK 0x00000100
/*
* Set this bit if and only if the algorithm requires another algorithm of
@@ -623,6 +624,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm *tfm)
return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK;
}
+static inline unsigned int crypto_tfm_alg_bulk(struct crypto_tfm *tfm)
+{
+ return tfm->__crt_alg->cra_flags & CRYPTO_ALG_BULK;
+}
+
static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm)
{
return tfm->__crt_alg->cra_blocksize;
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher
From: Baolin Wang @ 2016-06-01 4:58 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464756501.git.baolin.wang@linaro.org>
Since the ecb(aes) cipher does not need to handle the IV things for encryption
or decryption, that means it can support for bulk block when handling data.
Thus this patch adds the CRYPTO_ALG_BULK flag for ecb(aes) cipher to improve
the hardware aes engine's efficiency.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/crypto/omap-aes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce174d3..ab09429 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -804,7 +804,7 @@ static struct crypto_alg algs_ecb_cbc[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_BULK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
--
1.7.9.5
^ 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