[PATCH v7 02/14] crypto: mv_cesa: use gen_pool to reserve the SRAM memory region
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.
To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.
Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/mv_cesa.txt | 24 ++---
drivers/crypto/Kconfig | 1 +
drivers/crypto/mv_cesa.c | 58 --
3 files changed, 60 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index eaa2873..13b8fc5 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -2,21 +2,29 @@ Marvell Cryptographic Engines And Security Accelerator
Required properties:
- compatible : should be marvell,orion-crypto
-- reg : base physical address of the engine and length of memory mapped
-region, followed by base physical address of sram and its memory
-length
-- reg-names : regs , sram;
-- interrupts : interrupt number
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
- clocks: reference to the crypto engines clocks. This property is only
required for Dove platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
Examples:
crypto@3 {
compatible = marvell,orion-crypto;
- reg = 0x3 0x1,
- 0x400 0x800;
- reg-names = regs , sram;
+ reg = 0x3 0x1;
+ reg-names = regs;
interrupts = 22;
+ marvell,crypto-srams = crypto_sram;
+ marvell,crypto-sram-size = 0x600;
status = okay;
};
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 033c0c8..a6bbea8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -166,6 +166,7 @@ config CRYPTO_DEV_MV_CESA
select CRYPTO_AES
select CRYPTO_BLKCIPHER2
select CRYPTO_HASH
+ select SRAM
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Marvell Orion
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 27b2373..a4c8637 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -9,6 +9,7 @@
#include crypto/aes.h
#include crypto/algapi.h
#include linux/crypto.h
+#include linux/genalloc.h
#include linux/interrupt.h
#include linux/io.h
#include linux/kthread.h
@@ -29,6 +30,8 @@
#define MAX_HW_HASH_SIZE 0x
#define MV_CESA_EXPIRE 500 /* msec */
+#define MV_CESA_DEFAULT_SRAM_SIZE 2048
+
/*
* STM:
* /---\
@@ -83,6 +86,8 @@ struct req_progress {
struct crypto_priv {
void __iomem *reg;
void __iomem *sram;
+ struct gen_pool *sram_pool;
+ dma_addr_t sram_dma;
int irq;
struct clk *clk;
struct task_struct *queue_th;
@@ -1019,6 +1024,39 @@ static struct ahash_alg mv_hmac_sha1_alg = {
}
};
+static int mv_cesa_get_sram(struct platform_device *pdev,
+ struct crypto_priv *cp)
+{
+ struct resource *res;
+ u32 sram_size = MV_CESA_DEFAULT_SRAM_SIZE;
+
+ of_property_read_u32(pdev-dev.of_node, marvell,crypto-sram-size,
+sram_size);
+
+ cp-sram_size = sram_size;
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ marvell,crypto-srams, 0);
+ if (cp-sram_pool) {
+ cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
+ cp-sram_dma);
+ if (cp-sram)
+
[PATCH v7 03/14] crypto: mv_cesa: explicitly define kirkwood and dove compatible strings
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support on Dove and Kirkwood.
In the other hand, the migration from the old driver to the new one is not
something all people are willing to do without first auditing the new
driver.
Hence we have to support the new compatible in the mv_cesa driver so that
new platforms with updated DTs can still attach their crypto engine device
to this driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 5 -
drivers/crypto/mv_cesa.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
index 13b8fc5..c0c35f0 100644
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -1,7 +1,10 @@
Marvell Cryptographic Engines And Security Accelerator
Required properties:
-- compatible : should be marvell,orion-crypto
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index a4c8637..fcab963 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1034,7 +1034,7 @@ static int mv_cesa_get_sram(struct platform_device *pdev,
sram_size);
cp-sram_size = sram_size;
- cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
+ cp-sram_pool = of_get_named_gen_pool(pdev-dev.of_node,
marvell,crypto-srams, 0);
if (cp-sram_pool) {
cp-sram = gen_pool_dma_alloc(cp-sram_pool, sram_size,
@@ -1197,6 +1197,8 @@ static int mv_remove(struct platform_device *pdev)
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,orion-crypto, },
+ { .compatible = marvell,kirkwood-crypto, },
+ { .compatible = marvell,dove-crypto, },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 14/14] crypto: marvell/CESA: add DT bindings documentation
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
new file mode 100644
index 000..c6c6a4a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
@@ -0,0 +1,45 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible: should be one of the following string
+ marvell,orion-crypto
+ marvell,kirkwood-crypto
+ marvell,dove-crypto
+ marvell,armada-370-crypto
+ marvell,armada-xp-crypto
+ marvell,armada-375-crypto
+ marvell,armada-38x-crypto
+- reg: base physical address of the engine and length of memory mapped
+ region. Can also contain an entry for the SRAM attached to the CESA,
+ but this representation is deprecated and marvell,crypto-srams should
+ be used instead
+- reg-names: regs. Can contain an sram entry, but this representation
+is deprecated and marvell,crypto-srams should be used instead
+- interrupts: interrupt number
+- clocks: reference to the crypto engines clocks. This property is not
+ required for orion and kirkwood platforms
+- clock-names: cesaX and cesazX, X should be replaced by the crypto engine
+ id.
+ This property is not required for the orion and kirkwoord
+ platforms.
+ cesazX clocks are not required on armada-370 platforms
+- marvell,crypto-srams: phandle to crypto SRAM definitions
+
+Optional properties:
+- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
+ specified the whole SRAM is used (2KB)
+
+
+Examples:
+
+ crypto@9 {
+ compatible = marvell,armada-xp-crypto;
+ reg = 0x9 0x1;
+ reg-names = regs;
+ interrupts = 48, 49;
+ clocks = gateclk 23, gateclk 23;
+ clock-names = cesa0, cesa1;
+ marvell,crypto-srams = crypto_sram0, crypto_sram1;
+ marvell,crypto-sram-size = 0x600;
+ status = okay;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 05/14] crypto: marvell/CESA: add TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).
Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/marvell/Makefile | 2 +-
drivers/crypto/marvell/cesa.c | 68 +++
drivers/crypto/marvell/cesa.h | 229 ++
drivers/crypto/marvell/cipher.c | 179 -
drivers/crypto/marvell/hash.c | 414 +++-
drivers/crypto/marvell/tdma.c | 224 ++
7 files changed, 1101 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/marvell/tdma.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index cbc3d3d..cdca762 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -185,6 +185,7 @@ config CRYPTO_DEV_MARVELL_CESA
help
This driver allows you to utilize the Cryptographic Engines and
Security Accelerator (CESA) which can be found on the Armada 370.
+ This driver supports CPU offload through DMA transfers.
This driver is aimed at replacing the mv_cesa driver. This will only
happen once it has received proper testing.
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
index 68d0982..0c12b13 100644
--- a/drivers/crypto/marvell/Makefile
+++ b/drivers/crypto/marvell/Makefile
@@ -1,2 +1,2 @@
obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
-marvell-cesa-objs := cesa.o cipher.o hash.o
+marvell-cesa-objs := cesa.o cipher.o hash.o tdma.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 76a6943..986f024 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -184,6 +184,7 @@ static const struct mv_cesa_caps armada_370_caps = {
.ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
.ahash_algs = armada_370_ahash_algs,
.nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
};
static const struct of_device_id mv_cesa_of_match_table[] = {
@@ -192,6 +193,66 @@ static const struct of_device_id mv_cesa_of_match_table[]
= {
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+static void
+mv_cesa_conf_mbus_windows(struct mv_cesa_engine *engine,
+ const struct mbus_dram_target_info *dram)
+{
+ void __iomem *iobase = engine-regs;
+ int i;
+
+ for (i = 0; i 4; i++) {
+ writel(0, iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(0, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+
+ for (i = 0; i dram-num_cs; i++) {
+ const struct mbus_dram_window *cs = dram-cs + i;
+
+ writel(((cs-size - 1) 0x) |
+ (cs-mbus_attr 8) |
+ (dram-mbus_dram_target_id 4) | 1,
+ iobase + CESA_TDMA_WINDOW_CTRL(i));
+ writel(cs-base, iobase + CESA_TDMA_WINDOW_BASE(i));
+ }
+}
+
+static int mv_cesa_dev_dma_init(struct mv_cesa_dev *cesa)
+{
+ struct device *dev = cesa-dev;
+ struct mv_cesa_dev_dma *dma;
+
+ if (!cesa-caps-has_tdma)
+ return 0;
+
+ dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
+ if (!dma)
+ return -ENOMEM;
+
+ dma-tdma_desc_pool = dmam_pool_create(tdma_desc, dev,
+ sizeof(struct mv_cesa_tdma_desc),
+ 16, 0);
+ if (!dma-tdma_desc_pool)
+ return -ENOMEM;
+
+ dma-op_pool = dmam_pool_create(cesa_op, dev,
+ sizeof(struct mv_cesa_op_ctx), 16, 0);
+ if (!dma-op_pool)
+ return -ENOMEM;
+
+ dma-cache_pool = dmam_pool_create(cesa_cache, dev,
+ CESA_MAX_HASH_BLOCK_SIZE, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ dma-padding_pool = dmam_pool_create(cesa_padding, dev, 72, 1, 0);
+ if (!dma-cache_pool)
+ return -ENOMEM;
+
+ cesa-dma = dma;
+
+ return 0;
+}
+
static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
{
struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
@@ -299,6 +360,10 @@ static int mv_cesa_probe(struct platform_device *pdev)
if (IS_ERR(cesa-regs))
return -ENOMEM;
+
[PATCH v7 07/14] crypto: marvell/CESA: add Triple-DES support
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 files changed, 151 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 212840e..c0b1b49 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -171,6 +171,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 4b07209..1229c3d 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -779,6 +779,8 @@ extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
+extern struct crypto_alg mv_cesa_ecb_des3_ede_alg;
+extern struct crypto_alg mv_cesa_cbc_des3_ede_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index e420ea6..0745cf3 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -22,6 +22,11 @@ struct mv_cesa_des_ctx {
u8 key[DES_KEY_SIZE];
};
+struct mv_cesa_des3_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES3_EDE_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -268,6 +273,22 @@ static int mv_cesa_des_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des3_ede_setkey(struct crypto_ablkcipher *cipher,
+ const u8 *key, unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ if (len != DES3_EDE_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES3_EDE_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -514,6 +535,132 @@ struct crypto_alg mv_cesa_cbc_des_alg = {
},
};
+static int mv_cesa_des3_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des3_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_3DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES3_EDE_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des3_ede_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des3_ede_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_3DES_EDE |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des3_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des3_ede_alg = {
+ .cra_name = ecb(des3_ede),
+ .cra_driver_name = mv-ecb-des3-ede,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des3_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES3_EDE_KEY_SIZE,
+ .max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .setkey = mv_cesa_des3_ede_setkey,
+ .encrypt =
[PATCH v7 04/14] crypto: add a new driver for Marvell's CESA
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.
Other algorithms and platforms will be added later on.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile | 1 +
drivers/crypto/marvell/Makefile | 2 +
drivers/crypto/marvell/cesa.c | 417 +++
drivers/crypto/marvell/cesa.h | 554 +++
drivers/crypto/marvell/cipher.c | 331 ++
drivers/crypto/marvell/hash.c | 720
7 files changed, 2040 insertions(+)
create mode 100644 drivers/crypto/marvell/Makefile
create mode 100644 drivers/crypto/marvell/cesa.c
create mode 100644 drivers/crypto/marvell/cesa.h
create mode 100644 drivers/crypto/marvell/cipher.c
create mode 100644 drivers/crypto/marvell/hash.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index a6bbea8..cbc3d3d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,6 +174,21 @@ config CRYPTO_DEV_MV_CESA
Currently the driver supports AES in ECB and CBC mode without DMA.
+config CRYPTO_DEV_MARVELL_CESA
+ tristate New Marvell's Cryptographic Engine driver
+ depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) HAS_DMA
HAS_IOMEM
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_HASH
+ select SRAM
+ help
+ This driver allows you to utilize the Cryptographic Engines and
+ Security Accelerator (CESA) which can be found on the Armada 370.
+
+ This driver is aimed at replacing the mv_cesa driver. This will only
+ happen once it has received proper testing.
+
config CRYPTO_DEV_NIAGARA2
tristate Niagara2 Stream Processing Unit driver
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..e35c07a 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
diff --git a/drivers/crypto/marvell/Makefile b/drivers/crypto/marvell/Makefile
new file mode 100644
index 000..68d0982
--- /dev/null
+++ b/drivers/crypto/marvell/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell-cesa.o
+marvell-cesa-objs := cesa.o cipher.o hash.o
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
new file mode 100644
index 000..76a6943
--- /dev/null
+++ b/drivers/crypto/marvell/cesa.c
@@ -0,0 +1,417 @@
+/*
+ * Support for Marvell's Cryptographic Engine and Security Accelerator (CESA)
+ * that can be found on the following platform: Orion, Kirkwood, Armada. This
+ * driver supports the TDMA engine on platforms on which it is available.
+ *
+ * Author: Boris Brezillon boris.brezil...@free-electrons.com
+ * Author: Arnaud Ebalard a...@natisbad.org
+ *
+ * This work is based on an initial version written by
+ * Sebastian Andrzej Siewior sebastian at breakpoint dot cc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/genalloc.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kthread.h
+#include linux/mbus.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_irq.h
+
+#include cesa.h
+
+struct mv_cesa_dev *cesa_dev;
+
+static void mv_cesa_dequeue_req_unlocked(struct mv_cesa_engine *engine)
+{
+ struct crypto_async_request *req, *backlog;
+ struct mv_cesa_ctx *ctx;
+
+ spin_lock_bh(cesa_dev-lock);
+ backlog = crypto_get_backlog(cesa_dev-queue);
+ req = crypto_dequeue_request(cesa_dev-queue);
+ engine-req = req;
+ spin_unlock_bh(cesa_dev-lock);
+
+ if (!req)
+ return;
+
+ if (backlog)
+ backlog-complete(backlog, -EINPROGRESS);
+
+ ctx =
Re: [v2 PATCH 6/8] crypto: caam - Convert GCM to new AEAD interface
On 6/18/2015 9:17 AM, Herbert Xu wrote:
+static void init_gcm_job(struct aead_request *req,
+struct aead_edesc *edesc,
+bool all_contig, bool encrypt)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct caam_ctx *ctx = crypto_aead_ctx(aead);
+ unsigned int ivsize = crypto_aead_ivsize(aead);
+ u32 *desc = edesc-hw_desc;
+ bool generic_gcm = (ivsize == 12);
+ unsigned int last;
+
+ init_aead_job(req, edesc, all_contig, encrypt);
+
+ /* BUG This should not be specific to generic GCM. */
AFAICT, for non-generic GCM uses (RFC4106, RFC4543), cryptlen and/or
assoclen are always 0. That's why the descriptors do not address these
cases.
Of course. But with the algif_aead interface you need to at least
ensure that you don't crash or do something silly should the user
give you such an input. So my question is what happens when it is
zero? Does the hardware simply emit an error and recover, or does it
hang/lock up/do something worse?
To make sure, I've tried this case on HW (with modified tcrypt tests):
caam_jr ffe301000.jr: 4000101c: DECO: desc idx 16: DECO Watchdog timer
timeout error
alg: aead: encryption failed on test 1 for rfc4106-gcm-aes-caam:
ret=-1073745948
caam_jr ffe301000.jr: 4000111c: DECO: desc idx 17: DECO Watchdog timer
timeout error
alg: aead: encryption failed on test 1 for rfc4543-gcm-aes-caam:
ret=-1073746204
The errors are reported by HW and handled by the driver.
BTW does this actually work on your hardware now?
tcrypt tests pass.
I'll run more tests (IPsec) on my side and report back if I encounter
any issue.
Thanks,
Horia
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 08/14] crypto: marvell/CESA: add MD5 support
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed, 174 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index c0b1b49..047c1c0 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -178,7 +178,9 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
};
static struct ahash_alg *armada_370_ahash_algs[] = {
+ mv_md5_alg,
mv_sha1_alg,
+ mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 1229c3d..283e322 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -774,7 +774,9 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
/* Algorithm definitions */
+extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 528da26..36bb756 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -12,6 +12,7 @@
* by the Free Software Foundation.
*/
+#include crypto/md5.h
#include crypto/sha.h
#include cesa.h
@@ -346,8 +347,16 @@ static int mv_cesa_ahash_process(struct
crypto_async_request *req, u32 status)
ahashreq-nbytes - creq-cache_ptr);
if (creq-last_req) {
- for (i = 0; i digsize / 4; i++)
- creq-state[i] = cpu_to_be32(creq-state[i]);
+ for (i = 0; i digsize / 4; i++) {
+ /*
+* Hardware provides MD5 digest in a different
+* endianness than SHA-1 and SHA-256 ones.
+*/
+ if (digsize == MD5_DIGEST_SIZE)
+ creq-state[i] = cpu_to_le32(creq-state[i]);
+ else
+ creq-state[i] = cpu_to_be32(creq-state[i]);
+ }
memcpy(ahashreq-result, creq-state, digsize);
}
@@ -788,6 +797,95 @@ static int mv_cesa_ahash_finup(struct ahash_request *req)
return ret;
}
+static int mv_cesa_md5_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_MD5);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_md5_export(struct ahash_request *req, void *out)
+{
+ struct md5_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+
+ out_state-byte_count = creq-len;
+ memcpy(out_state-hash, creq-state, digsize);
+ memset(out_state-block, 0, sizeof(out_state-block));
+ if (creq-cache)
+ memcpy(out_state-block, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_md5_import(struct ahash_request *req, const void *in)
+{
+ const struct md5_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-byte_count;
+ memcpy(creq-state, in_state-hash, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % sizeof(in_state-block);
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-block, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+static int mv_cesa_md5_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_md5_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+struct ahash_alg mv_md5_alg = {
+ .init = mv_cesa_md5_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_md5_digest,
+ .export = mv_cesa_md5_export,
+ .import = mv_cesa_md5_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .base = {
+ .cra_name = md5,
+ .cra_driver_name = mv-md5,
+ .cra_priority = 300,
+
[PATCH v7 01/14] crypto: mv_cesa: document the clocks property
On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com --- Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt index 47229b1..eaa2873 100644 --- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -7,6 +7,8 @@ Required properties: length - reg-names : regs , sram; - interrupts : interrupt number +- clocks: reference to the crypto engines clocks. This property is only + required for Dove platforms Examples: -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
Hello, This patch series adds a new driver supporting Marvell's CESA IP. This driver addresses some limitations of the existing one. From a performance and CPU load point of view the most important limitation in the existing driver is the lack of DMA support, thus preventing us from chaining crypto operations. I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. Here are the main features brought by this new driver: - support for armada SoCs (up to 38x) while keeping support for older ones (Orion and Kirkwood). Note that old DT bindings (those used on Orion and Kirkwood platforms) are supported, or IOTW, old DTs are compatible with this new driver. - DMA mode to offload the CPU in case of intensive crypto usage - new algorithms: SHA256, DES and 3DES I'd like to thank Arnaud, who has carefully reviewed several iterations of this driver, helped me improved my implementation, provided support for several crypto algorithms, provided support for armada-370 and tested the driver on different platforms, hence the SoB and dual MODULE_AUTHOR in the driver code. In this version I dropped the DT changes, but you'll find them in my cesa-v7 branch [1]. In this branch you'll find everything you need to test on all Marvell platforms (including the old ones). I'll post a series updating all the DTs once this driver has been merged. Best Regards, Boris [1]https://github.com/bbrezillon/linux-marvell/tree/cesa-v7 Changes since v6: - do not store dma_map_sg() return value - use sg_dma_len() and sg_dma_address() - test for req-src != req-dst to choose the dma mapping method Changes since v5: - fix the dma_map_sg return code check (again) - fix select entries in the Kconfig option Changes since v4: - fix the dma_map_sg return code check - add import/export functions to all HMAC algos - update the passed IV when handling cipher requests - properly handle requests in the crypto queue backlog - use sg_nents_for_len Changes since v3: - add import functions for hash algorithms - patch mv_cesa driver to support the new DT bindings - few fixes in the documentation - replace mv_mbus_dram_info() call by mv_mbus_dram_info_nooverlap() - remove DT updates from the series Changes since v2: - fixes in the cipher code (-dst_nents was assigned the -src_nents value and CBC state was overwritten by the IV after each chunk operation) - spit the code as suggested by Sebastian Changes since v1: - (suggested by Jason) kept the existing CESA driver and added a mechanism to prevent the new driver from probing devices handled my the existing one (Orion and Kirkwood platforms) - (reported by Paul) addressed a few Kconfig and module definition issues - (suggested by Andrew) added DT changes to the series Arnaud Ebalard (4): crypto: marvell/CESA: add Triple-DES support crypto: marvell/CESA: add MD5 support crypto: marvell/CESA: add SHA256 support crypto: marvell/CESA: add support for Kirkwood and Dove SoCs Boris Brezillon (10): crypto: mv_cesa: document the clocks property crypto: mv_cesa: use gen_pool to reserve the SRAM memory region crypto: mv_cesa: explicitly define kirkwood and dove compatible strings crypto: add a new driver for Marvell's CESA crypto: marvell/CESA: add TDMA support crypto: marvell/CESA: add DES support crypto: marvell/CESA: add support for all armada SoCs crypto: marvell/CESA: add allhwsupport module parameter crypto: marvell/CESA: add support for Orion SoCs crypto: marvell/CESA: add DT bindings documentation .../devicetree/bindings/crypto/marvell-cesa.txt| 45 + .../devicetree/bindings/crypto/mv_cesa.txt | 31 +- drivers/crypto/Kconfig | 17 + drivers/crypto/Makefile|1 + drivers/crypto/marvell/Makefile|2 + drivers/crypto/marvell/cesa.c | 548 drivers/crypto/marvell/cesa.h | 791 +++ drivers/crypto/marvell/cipher.c| 797 +++ drivers/crypto/marvell/hash.c | 1441 drivers/crypto/marvell/tdma.c | 224 +++ drivers/crypto/mv_cesa.c | 60 +- 11 files changed, 3933 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt create mode 100644 drivers/crypto/marvell/Makefile create mode 100644 drivers/crypto/marvell/cesa.c create mode 100644 drivers/crypto/marvell/cesa.h create mode 100644 drivers/crypto/marvell/cipher.c create mode 100644 drivers/crypto/marvell/hash.c create mode 100644 drivers/crypto/marvell/tdma.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH v7 12/14] crypto: marvell/CESA: add support for Orion SoCs
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is explicitly requested to do
so).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index a05b5cb..8e5ea72 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -172,6 +172,22 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
crypto_unregister_alg(cesa-caps-cipher_algs[i]);
}
+static struct crypto_alg *orion_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
+ mv_cesa_ecb_des3_ede_alg,
+ mv_cesa_cbc_des3_ede_alg,
+ mv_cesa_ecb_aes_alg,
+ mv_cesa_cbc_aes_alg,
+};
+
+static struct ahash_alg *orion_ahash_algs[] = {
+ mv_md5_alg,
+ mv_sha1_alg,
+ mv_ahmac_md5_alg,
+ mv_ahmac_sha1_alg,
+};
+
static struct crypto_alg *armada_370_cipher_algs[] = {
mv_cesa_ecb_des_alg,
mv_cesa_cbc_des_alg,
@@ -190,6 +206,15 @@ static struct ahash_alg *armada_370_ahash_algs[] = {
mv_ahmac_sha256_alg,
};
+static const struct mv_cesa_caps orion_caps = {
+ .nengines = 1,
+ .cipher_algs = orion_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(orion_cipher_algs),
+ .ahash_algs = orion_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(orion_ahash_algs),
+ .has_tdma = false,
+};
+
static const struct mv_cesa_caps armada_370_caps = {
.nengines = 1,
.cipher_algs = armada_370_cipher_algs,
@@ -209,6 +234,7 @@ static const struct mv_cesa_caps armada_xp_caps = {
};
static const struct of_device_id mv_cesa_of_match_table[] = {
+ { .compatible = marvell,orion-crypto, .data = orion_caps },
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
{ .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
{ .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
@@ -334,7 +360,7 @@ static void mv_cesa_put_sram(struct platform_device *pdev,
int idx)
static int mv_cesa_probe(struct platform_device *pdev)
{
- const struct mv_cesa_caps *caps = NULL;
+ const struct mv_cesa_caps *caps = orion_caps;
const struct mbus_dram_target_info *dram;
const struct of_device_id *match;
struct device *dev = pdev-dev;
@@ -349,14 +375,16 @@ static int mv_cesa_probe(struct platform_device *pdev)
return -EEXIST;
}
- if (!dev-of_node)
- return -ENOTSUPP;
+ if (dev-of_node) {
+ match = of_match_node(mv_cesa_of_match_table, dev-of_node);
+ if (!match || !match-data)
+ return -ENOTSUPP;
- match = of_match_node(mv_cesa_of_match_table, dev-of_node);
- if (!match || !match-data)
- return -ENOTSUPP;
+ caps = match-data;
+ }
- caps = match-data;
+ if (caps == orion_caps !allhwsupport)
+ return -ENOTSUPP;
cesa = devm_kzalloc(dev, sizeof(*cesa), GFP_KERNEL);
if (!cesa)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 10/14] crypto: marvell/CESA: add support for all armada SoCs
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 9c43cd7e..af590bf 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -195,8 +195,20 @@ static const struct mv_cesa_caps armada_370_caps = {
.has_tdma = true,
};
+static const struct mv_cesa_caps armada_xp_caps = {
+ .nengines = 2,
+ .cipher_algs = armada_370_cipher_algs,
+ .ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
+ .ahash_algs = armada_370_ahash_algs,
+ .nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
+ .has_tdma = true,
+};
+
static const struct of_device_id mv_cesa_of_match_table[] = {
{ .compatible = marvell,armada-370-crypto, .data = armada_370_caps },
+ { .compatible = marvell,armada-xp-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-375-crypto, .data = armada_xp_caps },
+ { .compatible = marvell,armada-38x-crypto, .data = armada_xp_caps },
{}
};
MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 06/14] crypto: marvell/CESA: add DES support
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 986f024..212840e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -169,6 +169,8 @@ static void mv_cesa_remove_algs(struct mv_cesa_dev *cesa)
}
static struct crypto_alg *armada_370_cipher_algs[] = {
+ mv_cesa_ecb_des_alg,
+ mv_cesa_cbc_des_alg,
mv_cesa_ecb_aes_alg,
mv_cesa_cbc_aes_alg,
};
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index f8faf26..4b07209 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -777,6 +777,8 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_sha1_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct crypto_alg mv_cesa_ecb_des_alg;
+extern struct crypto_alg mv_cesa_cbc_des_alg;
extern struct crypto_alg mv_cesa_ecb_aes_alg;
extern struct crypto_alg mv_cesa_cbc_aes_alg;
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index e21783b..e420ea6 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -13,9 +13,15 @@
*/
#include crypto/aes.h
+#include crypto/des.h
#include cesa.h
+struct mv_cesa_des_ctx {
+ struct mv_cesa_ctx base;
+ u8 key[DES_KEY_SIZE];
+};
+
struct mv_cesa_aes_ctx {
struct mv_cesa_ctx base;
struct crypto_aes_ctx aes;
@@ -238,6 +244,30 @@ static int mv_cesa_aes_setkey(struct crypto_ablkcipher
*cipher, const u8 *key,
return 0;
}
+static int mv_cesa_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
+ unsigned int len)
+{
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 tmp[DES_EXPKEY_WORDS];
+ int ret;
+
+ if (len != DES_KEY_SIZE) {
+ crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ ret = des_ekey(tmp, key);
+ if (!ret (tfm-crt_flags CRYPTO_TFM_REQ_WEAK_KEY)) {
+ tfm-crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
+ return -EINVAL;
+ }
+
+ memcpy(ctx-key, key, DES_KEY_SIZE);
+
+ return 0;
+}
+
static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
const struct mv_cesa_op_ctx *op_templ)
{
@@ -364,6 +394,126 @@ static int mv_cesa_ablkcipher_req_init(struct
ablkcipher_request *req,
return ret;
}
+static int mv_cesa_des_op(struct ablkcipher_request *req,
+ struct mv_cesa_op_ctx *tmpl)
+{
+ struct mv_cesa_des_ctx *ctx = crypto_tfm_ctx(req-base.tfm);
+ int ret;
+
+ mv_cesa_update_op_cfg(tmpl, CESA_SA_DESC_CFG_CRYPTM_DES,
+ CESA_SA_DESC_CFG_CRYPTM_MSK);
+
+ memcpy(tmpl-ctx.blkcipher.key, ctx-key, DES_KEY_SIZE);
+
+ ret = mv_cesa_ablkcipher_req_init(req, tmpl);
+ if (ret)
+ return ret;
+
+ ret = mv_cesa_queue_req(req-base);
+ if (ret ret != -EINPROGRESS)
+ mv_cesa_ablkcipher_cleanup(req);
+
+ return ret;
+}
+
+static int mv_cesa_ecb_des_encrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_ENC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+static int mv_cesa_ecb_des_decrypt(struct ablkcipher_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl,
+ CESA_SA_DESC_CFG_CRYPTCM_ECB |
+ CESA_SA_DESC_CFG_DIR_DEC);
+
+ return mv_cesa_des_op(req, tmpl);
+}
+
+struct crypto_alg mv_cesa_ecb_des_alg = {
+ .cra_name = ecb(des),
+ .cra_driver_name = mv-ecb-des,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+CRYPTO_ALG_KERN_DRIVER_ONLY | CRYPTO_ALG_ASYNC,
+ .cra_blocksize = DES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_des_ctx),
+ .cra_alignmask = 0,
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = mv_cesa_ablkcipher_cra_init,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize = DES_KEY_SIZE,
+ .max_keysize = DES_KEY_SIZE,
+ .setkey = mv_cesa_des_setkey,
+ .encrypt = mv_cesa_ecb_des_encrypt,
+ .decrypt =
[PATCH v7 09/14] crypto: marvell/CESA: add SHA256 support
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files changed, 163 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 047c1c0..9c43cd7e 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,8 +180,10 @@ static struct crypto_alg *armada_370_cipher_algs[] = {
static struct ahash_alg *armada_370_ahash_algs[] = {
mv_md5_alg,
mv_sha1_alg,
+ mv_sha256_alg,
mv_ahmac_md5_alg,
mv_ahmac_sha1_alg,
+ mv_ahmac_sha256_alg,
};
static const struct mv_cesa_caps armada_370_caps = {
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index 283e322..b60698b 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -776,8 +776,10 @@ int mv_cesa_dma_add_op_transfers(struct mv_cesa_tdma_chain
*chain,
extern struct ahash_alg mv_md5_alg;
extern struct ahash_alg mv_sha1_alg;
+extern struct ahash_alg mv_sha256_alg;
extern struct ahash_alg mv_ahmac_md5_alg;
extern struct ahash_alg mv_ahmac_sha1_alg;
+extern struct ahash_alg mv_ahmac_sha256_alg;
extern struct crypto_alg mv_cesa_ecb_des_alg;
extern struct crypto_alg mv_cesa_cbc_des_alg;
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 36bb756..ae9272e 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -975,6 +975,95 @@ struct ahash_alg mv_sha1_alg = {
}
};
+static int mv_cesa_sha256_init(struct ahash_request *req)
+{
+ struct mv_cesa_op_ctx tmpl;
+
+ mv_cesa_set_op_cfg(tmpl, CESA_SA_DESC_CFG_MACM_SHA256);
+
+ mv_cesa_ahash_init(req, tmpl);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_digest(struct ahash_request *req)
+{
+ int ret;
+
+ ret = mv_cesa_sha256_init(req);
+ if (ret)
+ return ret;
+
+ return mv_cesa_ahash_finup(req);
+}
+
+static int mv_cesa_sha256_export(struct ahash_request *req, void *out)
+{
+ struct sha256_state *out_state = out;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int ds = crypto_ahash_digestsize(ahash);
+
+ out_state-count = creq-len;
+ memcpy(out_state-state, creq-state, ds);
+ memset(out_state-buf, 0, sizeof(out_state-buf));
+ if (creq-cache)
+ memcpy(out_state-buf, creq-cache, creq-cache_ptr);
+
+ return 0;
+}
+
+static int mv_cesa_sha256_import(struct ahash_request *req, const void *in)
+{
+ const struct sha256_state *in_state = in;
+ struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
+ struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+ unsigned int digsize = crypto_ahash_digestsize(ahash);
+ unsigned int cache_ptr;
+ int ret;
+
+ creq-len = in_state-count;
+ memcpy(creq-state, in_state-state, digsize);
+ creq-cache_ptr = 0;
+
+ cache_ptr = creq-len % SHA256_BLOCK_SIZE;
+ if (!cache_ptr)
+ return 0;
+
+ ret = mv_cesa_ahash_alloc_cache(req);
+ if (ret)
+ return ret;
+
+ memcpy(creq-cache, in_state-buf, cache_ptr);
+ creq-cache_ptr = cache_ptr;
+
+ return 0;
+}
+
+struct ahash_alg mv_sha256_alg = {
+ .init = mv_cesa_sha256_init,
+ .update = mv_cesa_ahash_update,
+ .final = mv_cesa_ahash_final,
+ .finup = mv_cesa_ahash_finup,
+ .digest = mv_cesa_sha256_digest,
+ .export = mv_cesa_sha256_export,
+ .import = mv_cesa_sha256_import,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha256,
+ .cra_driver_name = mv-sha256,
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct mv_cesa_hash_ctx),
+ .cra_init = mv_cesa_ahash_cra_init,
+ .cra_module = THIS_MODULE,
+}
+ }
+};
+
struct mv_cesa_ahash_result {
struct completion completion;
int error;
@@ -1280,3 +1369,73 @@ struct ahash_alg mv_ahmac_sha1_alg = {
}
}
};
+
+static int mv_cesa_ahmac_sha256_setkey(struct crypto_ahash *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct mv_cesa_hmac_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
+ struct sha256_state istate, ostate;
+ int ret, i;
+
+
[PATCH] MAINTAINERS: clarify drivers/crypto/nx/ file ownership
Update the IBM Power in-Nest Crypto Acceleration and IBM Power 842 compression accelerator sections to specify the correct files. The IBM Power in-Nest Crypto Acceleration was originally the only NX driver, and so its section listed all drivers/crypto/nx/ files, but now there is also the 842 driver which has its own section. This lists explicitly what files are owned by the Crypto driver and which files are owned by the 842 compression driver. Signed-off-by: Dan Streetman ddstr...@ieee.org --- Leonidas, I assume you'll update the owner line at some point too, since you're the new NX Crypto owner. MAINTAINERS | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index fb06e1e..d6fb983 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4856,11 +4856,19 @@ M: Marcelo Henrique Cerri mhce...@linux.vnet.ibm.com M: Fionnuala Gunter f...@linux.vnet.ibm.com L: linux-crypto@vger.kernel.org S: Supported -F: drivers/crypto/nx/ +F: drivers/crypto/nx/Makefile +F: drivers/crypto/nx/Kconfig +F: drivers/crypto/nx/nx-aes* +F: drivers/crypto/nx/nx-sha* +F: drivers/crypto/nx/nx.* +F: drivers/crypto/nx/nx_csbcpb.h +F: drivers/crypto/nx/nx_debugfs.h IBM Power 842 compression accelerator M: Dan Streetman ddstr...@us.ibm.com S: Supported +F: drivers/crypto/nx/Makefile +F: drivers/crypto/nx/Kconfig F: drivers/crypto/nx/nx-842* F: include/linux/sw842.h F: crypto/842.c -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: nx - add LE support to pSeries platform driver
Add support to the nx-842-pseries.c driver for running in little endian
mode.
The pSeries platform NX 842 driver currently only works as big endian.
This adds cpu_to_be*() and be*_to_cpu() in the appropriate places to
work in LE mode also.
Signed-off-by: Dan Streetman ddstr...@ieee.org
---
drivers/crypto/nx/Kconfig | 2 +-
drivers/crypto/nx/nx-842-pseries.c | 83 +++---
drivers/crypto/nx/nx-842.h | 3 +-
3 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
index b1addf6..e421c96 100644
--- a/drivers/crypto/nx/Kconfig
+++ b/drivers/crypto/nx/Kconfig
@@ -24,7 +24,7 @@ if CRYPTO_DEV_NX_COMPRESS
config CRYPTO_DEV_NX_COMPRESS_PSERIES
tristate Compression acceleration support on pSeries platform
- depends on PPC_PSERIES IBMVIO !CPU_LITTLE_ENDIAN
+ depends on PPC_PSERIES IBMVIO
default y
help
Support for PowerPC Nest (NX) compression acceleration. This
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index da52d8e..3040a60 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -166,8 +166,8 @@ static unsigned long nx842_get_desired_dma(struct vio_dev
*viodev)
}
struct nx842_slentry {
- unsigned long ptr; /* Real address (use __pa()) */
- unsigned long len;
+ __be64 ptr; /* Real address (use __pa()) */
+ __be64 len;
};
/* pHyp scatterlist entry */
@@ -186,30 +186,21 @@ static inline unsigned long nx842_get_scatterlist_size(
static int nx842_build_scatterlist(unsigned long buf, int len,
struct nx842_scatterlist *sl)
{
- unsigned long nextpage;
+ unsigned long entrylen;
struct nx842_slentry *entry;
sl-entry_nr = 0;
entry = sl-entries;
while (len) {
- entry-ptr = nx842_get_pa((void *)buf);
- nextpage = ALIGN(buf + 1, NX842_HW_PAGE_SIZE);
- if (nextpage buf + len) {
- /* we aren't at the end yet */
- if (IS_ALIGNED(buf, NX842_HW_PAGE_SIZE))
- /* we are in the middle (or beginning) */
- entry-len = NX842_HW_PAGE_SIZE;
- else
- /* we are at the beginning */
- entry-len = nextpage - buf;
- } else {
- /* at the end */
- entry-len = len;
- }
-
- len -= entry-len;
- buf += entry-len;
+ entry-ptr = cpu_to_be64(nx842_get_pa((void *)buf));
+ entrylen = min_t(int, len,
+LEN_ON_SIZE(buf, NX842_HW_PAGE_SIZE));
+ entry-len = cpu_to_be64(entrylen);
+
+ len -= entrylen;
+ buf += entrylen;
+
sl-entry_nr++;
entry++;
}
@@ -230,8 +221,8 @@ static int nx842_validate_result(struct device *dev,
csb-completion_code,
csb-completion_extension);
dev_dbg(dev, processed_bytes:%d address:0x%016lx\n,
- csb-processed_byte_count,
- (unsigned long)csb-address);
+ be32_to_cpu(csb-processed_byte_count),
+ (unsigned long)be64_to_cpu(csb-address));
return -EIO;
}
@@ -338,7 +329,6 @@ static int nx842_pseries_compress(const unsigned char *in,
unsigned int inlen,
csbcpb = workmem-csbcpb;
memset(csbcpb, 0, sizeof(*csbcpb));
op.csbcpb = nx842_get_pa(csbcpb);
- op.out = nx842_get_pa(slout.entries);
if ((inbuf NX842_HW_PAGE_MASK) ==
((inbuf + inlen - 1) NX842_HW_PAGE_MASK)) {
@@ -364,6 +354,10 @@ static int nx842_pseries_compress(const unsigned char *in,
unsigned int inlen,
op.outlen = -nx842_get_scatterlist_size(slout);
}
+ dev_dbg(dev, %s: op.in %lx op.inlen %ld op.out %lx op.outlen %ld\n,
+ __func__, (unsigned long)op.in, (long)op.inlen,
+ (unsigned long)op.out, (long)op.outlen);
+
/* Send request to pHyp */
ret = vio_h_cop_sync(local_devdata-vdev, op);
@@ -380,7 +374,7 @@ static int nx842_pseries_compress(const unsigned char *in,
unsigned int inlen,
if (ret)
goto unlock;
- *outlen = csbcpb-csb.processed_byte_count;
+ *outlen = be32_to_cpu(csbcpb-csb.processed_byte_count);
dev_dbg(dev, %s: processed_bytes=%d\n, __func__, *outlen);
unlock:
@@ -493,6 +487,10 @@ static int nx842_pseries_decompress(const unsigned char
*in, unsigned int inlen,
op.outlen = -nx842_get_scatterlist_size(slout);
}
+ dev_dbg(dev, %s: op.in
Re: variable iv lengths for aes-gcm
On Thu, Jun 18, 2015 at 12:44:06PM +0300, Ambarus Tudor-Dan-B38632 wrote: The reason is to cover a wide range of applications. Your question also applies to the gcm NIST publication. Users may want to use a crypto module that meets the requirements of FIPS Pub. for various applications that use variable lengths for IV. What are these applications? Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
crypto: nx - Check for bogus firmware properties
The nx driver reads two crucial paramters from the firmware for
each crypto algorithm, the maximum SG list length and byte limit.
Unfortunately those two parameters may be bogus, or worse they
may be absent altogether. When this happens the algorithms will
still register successfully but will fail when used or tested.
This patch adds checks to report any firmware entries which are
found to be bogus, and avoid registering algorithms which have
bogus parameters. A warning is also printed when an algorithm
is not registered because of this as there may have been no firmware
entries for it at all.
Reported-by: Ondrej Moriš omo...@redhat.com
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
drivers/crypto/nx/nx.c | 150 ++---
1 file changed, 118 insertions(+), 32 deletions(-)
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index 8473505..f6198f2 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -32,6 +32,7 @@
#include linux/scatterlist.h
#include linux/device.h
#include linux/of.h
+#include linux/types.h
#include asm/hvcall.h
#include asm/vio.h
@@ -398,6 +399,13 @@ static void nx_of_update_msc(struct device *dev,
goto next_loop;
}
+ if (!trip-sglen || trip-databytelen NX_PAGE_SIZE) {
+ dev_warn(dev, bogus sglen/databytelen:
+%u/%u (ignored)\n, trip-sglen,
+trip-databytelen);
+ goto next_loop;
+ }
+
switch (trip-keybitlen) {
case 128:
case 160:
@@ -490,6 +498,72 @@ static void nx_of_init(struct device *dev, struct nx_of
*props)
nx_of_update_msc(dev, p, props);
}
+static bool nx_check_prop(struct device *dev, u32 fc, u32 mode, int slot)
+{
+ struct alg_props *props = nx_driver.of.ap[fc][mode][slot];
+
+ if (!props-sglen || props-databytelen NX_PAGE_SIZE) {
+ if (dev)
+ dev_warn(dev, bogus sglen/databytelen for %u/%u/%u:
+%u/%u (ignored)\n, fc, mode, slot,
+props-sglen, props-databytelen);
+ return false;
+ }
+
+ return true;
+}
+
+static bool nx_check_props(struct device *dev, u32 fc, u32 mode)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+ if (!nx_check_prop(dev, fc, mode, i))
+ return false;
+
+ return true;
+}
+
+static int nx_register_alg(struct crypto_alg *alg, u32 fc, u32 mode)
+{
+ return nx_check_props(nx_driver.viodev-dev, fc, mode) ?
+ crypto_register_alg(alg) : 0;
+}
+
+static int nx_register_aead(struct aead_alg *alg, u32 fc, u32 mode)
+{
+ return nx_check_props(nx_driver.viodev-dev, fc, mode) ?
+ crypto_register_aead(alg) : 0;
+}
+
+static int nx_register_shash(struct shash_alg *alg, u32 fc, u32 mode, int slot)
+{
+ return (slot = 0 ? nx_check_prop(nx_driver.viodev-dev,
+ fc, mode, slot) :
+ nx_check_props(nx_driver.viodev-dev, fc, mode)) ?
+ crypto_register_shash(alg) : 0;
+}
+
+static void nx_unregister_alg(struct crypto_alg *alg, u32 fc, u32 mode)
+{
+ if (nx_check_props(NULL, fc, mode))
+ crypto_unregister_alg(alg);
+}
+
+static void nx_unregister_aead(struct aead_alg *alg, u32 fc, u32 mode)
+{
+ if (nx_check_props(NULL, fc, mode))
+ crypto_unregister_aead(alg);
+}
+
+static void nx_unregister_shash(struct shash_alg *alg, u32 fc, u32 mode,
+ int slot)
+{
+ if (slot = 0 ? nx_check_prop(NULL, fc, mode, slot) :
+ nx_check_props(NULL, fc, mode))
+ crypto_unregister_shash(alg);
+}
+
/**
* nx_register_algs - register algorithms with the crypto API
*
@@ -514,72 +588,77 @@ static int nx_register_algs(void)
nx_driver.of.status = NX_OKAY;
- rc = crypto_register_alg(nx_ecb_aes_alg);
+ rc = nx_register_alg(nx_ecb_aes_alg, NX_FC_AES, NX_MODE_AES_ECB);
if (rc)
goto out;
- rc = crypto_register_alg(nx_cbc_aes_alg);
+ rc = nx_register_alg(nx_cbc_aes_alg, NX_FC_AES, NX_MODE_AES_CBC);
if (rc)
goto out_unreg_ecb;
- rc = crypto_register_alg(nx_ctr_aes_alg);
+ rc = nx_register_alg(nx_ctr_aes_alg, NX_FC_AES, NX_MODE_AES_CTR);
if (rc)
goto out_unreg_cbc;
- rc = crypto_register_alg(nx_ctr3686_aes_alg);
+ rc = nx_register_alg(nx_ctr3686_aes_alg, NX_FC_AES, NX_MODE_AES_CTR);
if (rc)
goto out_unreg_ctr;
- rc = crypto_register_aead(nx_gcm_aes_alg);
+ rc = nx_register_aead(nx_gcm_aes_alg, NX_FC_AES,
Re: [v2 PATCH 6/8] crypto: caam - Convert GCM to new AEAD interface
On Thu, Jun 18, 2015 at 02:18:21PM +0300, Horia Geantă wrote: To make sure, I've tried this case on HW (with modified tcrypt tests): caam_jr ffe301000.jr: 4000101c: DECO: desc idx 16: DECO Watchdog timer timeout error alg: aead: encryption failed on test 1 for rfc4106-gcm-aes-caam: ret=-1073745948 caam_jr ffe301000.jr: 4000111c: DECO: desc idx 17: DECO Watchdog timer timeout error alg: aead: encryption failed on test 1 for rfc4543-gcm-aes-caam: ret=-1073746204 The errors are reported by HW and handled by the driver. OK as long as it doesn't cause problems for other users of caam (that would be a DDoS) then it should be fine. tcrypt tests pass. I'll run more tests (IPsec) on my side and report back if I encounter any issue. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 06/14] crypto: marvell/CESA: add DES support
Hi Herbert, On Wed, 17 Jun 2015 09:45:34 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Add support for DES operations. The addition of DES support seems controversial. At first I thought it would be good to support all the algorithms supported by the CESA engine, but I think I'll drop it in the next iteration. Do you think Triple-DES should be dropped too ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 06/14] crypto: marvell/CESA: add DES support
On Thu, Jun 18, 2015 at 08:57:09AM +0200, Boris Brezillon wrote: Hi Herbert, On Wed, 17 Jun 2015 09:45:34 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Add support for DES operations. The addition of DES support seems controversial. At first I thought it would be good to support all the algorithms supported by the CESA engine, but I think I'll drop it in the next iteration. Do you think Triple-DES should be dropped too ? We're not here to make policy decisions. So I don't see anything wrong with keeping it. However, if you don't wish to add it then it's fine by me too. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] crypto: aead - Fix aead_instance struct size
The struct aead_instance is meant to extend struct crypto_instance
by incorporating the extra members of struct aead_alg. However,
the current layout which is copied from shash/ahash does not specify
the struct fully. In particular only aead_alg is present.
For shash/ahash this works because users there add extra headroom
to sizeof(struct crypto_instance) when allocating the instance.
Unfortunately for aead, this bit was lost when the new aead_instance
was added.
Rather than fixing it like shash/ahash, this patch simply expands
struct aead_instance to contain what is supposed to be there, i.e.,
adding struct crypto_instance.
In order to not break existing AEAD users, this is done through an
anonymous union.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
include/crypto/internal/aead.h |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/crypto/internal/aead.h b/include/crypto/internal/aead.h
index ba52c37b8..4b25471 100644
--- a/include/crypto/internal/aead.h
+++ b/include/crypto/internal/aead.h
@@ -15,12 +15,19 @@
#include crypto/aead.h
#include crypto/algapi.h
+#include linux/stddef.h
#include linux/types.h
struct rtattr;
struct aead_instance {
- struct aead_alg alg;
+ union {
+ struct {
+ char head[offsetof(struct aead_alg, base)];
+ struct crypto_instance base;
+ } s;
+ struct aead_alg alg;
+ };
};
struct crypto_aead_spawn {
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] crypto: api - Add CRYPTO_MINALIGN_ATTR to struct crypto_alg
The struct crypto_alg is embedded into various type-specific structs
such as aead_alg. This is then used as part of instances such as
struct aead_instance. It is also embedded into the generic struct
crypto_instance. In order to ensure that struct aead_instance can
be converted to struct crypto_instance when necessary, we need to
ensure that crypto_alg is aligned properly.
This patch adds an alignment attribute to struct crypto_alg to
ensure this.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
include/linux/crypto.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 25a4b71..2d34901 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -512,7 +512,7 @@ struct crypto_alg {
void (*cra_destroy)(struct crypto_alg *alg);
struct module *cra_module;
-};
+} CRYPTO_MINALIGN_ATTR;
/*
* Algorithm registration interface.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] crypto: caam - Reintroduce DESC_MAX_USED_BYTES
I incorrectly removed DESC_MAX_USED_BYTES when enlarging the size of the shared descriptor buffers, thus making it four times larger than what is necessary. This patch restores the division by four calculation. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au --- drivers/crypto/caam/caamalg.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c index f206521..789c385 100644 --- a/drivers/crypto/caam/caamalg.c +++ b/drivers/crypto/caam/caamalg.c @@ -100,7 +100,8 @@ #define DESC_ABLKCIPHER_DEC_LEN(DESC_ABLKCIPHER_BASE + \ 15 * CAAM_CMD_SZ) -#define DESC_MAX_USED_LEN (CAAM_DESC_BYTES_MAX - DESC_JOB_IO_LEN) +#define DESC_MAX_USED_BYTES(CAAM_DESC_BYTES_MAX - DESC_JOB_IO_LEN) +#define DESC_MAX_USED_LEN (DESC_MAX_USED_BYTES / CAAM_CMD_SZ) #ifdef DEBUG /* for print_hex_dumps with line references */ -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] crypto: caam - Set last bit on src SG list
The new aead_edesc_alloc left out the bit indicating the last
entry on the source SG list. This patch fixes it.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
---
drivers/crypto/caam/caamalg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 789c385..daca933 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2624,7 +2624,7 @@ static struct aead_edesc *aead_edesc_alloc(struct
aead_request *req,
sec4_sg_index = 0;
if (!all_contig) {
- sg_to_sec4_sg(req-src, src_nents,
+ sg_to_sec4_sg_last(req-src, src_nents,
edesc-sec4_sg + sec4_sg_index, 0);
sec4_sg_index += src_nents;
}
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: variable iv lengths for aes-gcm
On 6/18/2015 11:07 AM, Herbert Xu wrote: On Thu, Jun 18, 2015 at 10:43:18AM +0300, Ambarus Tudor-Dan-B38632 wrote: I'm trying to find a method to pass IVs of various lengths to an algorithm. A particular case would be aes-gcm IV. It can have any number of bits between 1 and 2^64. A possible way to do this is to set the ivlen per request. Are there any (better) ways to do this? Why would you want do this apart from the fact that your hardware supports it and you want to export this? The reason is to cover a wide range of applications. Your question also applies to the gcm NIST publication. Users may want to use a crypto module that meets the requirements of FIPS Pub. for various applications that use variable lengths for IV. ta -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: variable iv lengths for aes-gcm
On Thu, Jun 18, 2015 at 10:43:18AM +0300, Ambarus Tudor-Dan-B38632 wrote: I'm trying to find a method to pass IVs of various lengths to an algorithm. A particular case would be aes-gcm IV. It can have any number of bits between 1 and 2^64. A possible way to do this is to set the ivlen per request. Are there any (better) ways to do this? Why would you want do this apart from the fact that your hardware supports it and you want to export this? Using a long IV is fundamentally insecure because all GCM will do is hash it and there is nothing that can guarantee uniquenes of the hash result. You might as well just pull out a random number and use that as your IV. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, +DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) It's worse than that... You're right on that point, but there's an additional point. If dma_map_sg() coalesces scatterlist entries, then ret will be smaller than src_nents, and ret indicates how many scatterlist entries to be walked during DMA - you should not use src_nents for that. I couldn't see where the driver used that information. In fact, the driver seems to be capable of walking more than src_nents/ret numbers of scatterlist entries: it just keeps going with sg_next() until it hits the end of the allocated scatterlist. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Thu, Jun 18, 2015 at 10:04:00AM +0100, Russell King - ARM Linux wrote: If dma_map_sg() coalesces scatterlist entries, then ret will be smaller than src_nents, and ret indicates how many scatterlist entries to be walked during DMA - you should not use src_nents for that. I couldn't see where the driver used that information. In fact, the driver seems to be capable of walking more than src_nents/ret numbers of scatterlist entries: it just keeps going with sg_next() until it hits the end of the allocated scatterlist. I think he should be OK even though he throws away the return value because he's stopping his walk once the sum of sg_dma_length reaches his end goal. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support
On Thu, Jun 18, 2015 at 11:33:24AM +0200, Boris Brezillon wrote: Hi Russel, On Thu, 18 Jun 2015 10:04:00 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, +DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + + creq-src_nents = ret; DMA-API-HOWTO says that you must retain the original nents and use it when you call dma_unmap_sg. So I'm afraid one more repost is needed :) It's worse than that... You're right on that point, but there's an additional point. If dma_map_sg() coalesces scatterlist entries, then ret will be smaller than src_nents, and ret indicates how many scatterlist entries to be walked during DMA - you should not use src_nents for that. I couldn't see where the driver used that information. In fact, the driver seems to be capable of walking more than src_nents/ret numbers of scatterlist entries: it just keeps going with sg_next() until it hits the end of the allocated scatterlist. Yes, I realized that, and I never used the value returned by dma_map_sg() to walk the scatterlist anyway: I was using the sg_next() and sg-length value (which I replaced by sg_dma_len() in v7 as suggested by Herbert). So the -src_nents assignment to dma_map_sg() return value was just a silly mistake caused by an uncareful read of the DMA-API-HOWTO. Am I missing something else ? Yes. 'ret' should be used to indicate the number of scatterlist entries to walk for DMA purposes after the scatterlist has been mapped. For PIO purposes, using src_nents is still acceptable. As Herbert points out, you're stopping after the sum of transferred bytes matches, so I suppose that's fine. One other point though: you should use sg_dma_address() rather than dereferencing sg-dma_address directly. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
