Re: [linux-sunxi] [PATCH v2 1/4] crypto: Add Allwinner Security System crypto accelerator
Hi, On Mon, Jun 9, 2014 at 6:59 PM, LABBE Corentin clabbe.montj...@gmail.com wrote: Add support for the Security System included in Allwinner SoC A20. The Security System is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms. Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- drivers/crypto/sunxi-ss/Makefile | 16 ++ drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c | 118 drivers/crypto/sunxi-ss/sunxi-ss-cipher-aes.c | 130 + drivers/crypto/sunxi-ss/sunxi-ss-cipher-des.c | 118 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 362 + drivers/crypto/sunxi-ss/sunxi-ss-cipher.h | 8 + drivers/crypto/sunxi-ss/sunxi-ss-hash-md5.c| 69 + drivers/crypto/sunxi-ss/sunxi-ss-hash-sha1.c | 69 + drivers/crypto/sunxi-ss/sunxi-ss-hash.c| 228 drivers/crypto/sunxi-ss/sunxi-ss-hash.h| 9 + drivers/crypto/sunxi-ss/sunxi-ss-rng.c | 115 drivers/crypto/sunxi-ss/sunxi-ss.c | 190 + drivers/crypto/sunxi-ss/sunxi-ss.h | 161 +++ 13 files changed, 1593 insertions(+) create mode 100644 drivers/crypto/sunxi-ss/Makefile create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-aes.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-des.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.h create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash-md5.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash-sha1.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.h create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-rng.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile new file mode 100644 index 000..de4556b --- /dev/null +++ b/drivers/crypto/sunxi-ss/Makefile @@ -0,0 +1,16 @@ +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o + +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_PRNG) += sunxi-ss-rng.o + +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_DES) += sunxi-ss-des.o +sunxi-ss-des-y += sunxi-ss-cipher-des.o sunxi-ss-cipher.o +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_3DES) += sunxi-ss-3des.o +sunxi-ss-3des-y += sunxi-ss-cipher-3des.o sunxi-ss-cipher.o + +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_AES) += sunxi-ss-aes.o +sunxi-ss-aes-y += sunxi-ss-cipher-aes.o sunxi-ss-cipher.o I just tried building Hans' (CC-ed) sunxi-devel branch, which includes this series, with all the Security System options enabled. It doesn't build: LD drivers/crypto/sunxi-ss/built-in.o drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_cipher_init': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: multiple definition of `sunxi_cipher_init' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: first defined here drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_des_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: multiple definition of `sunxi_des_poll' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: first defined here drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_aes_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:33: multiple definition of `sunxi_aes_poll' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:33: first defined here drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_cipher_exit': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:29: multiple definition of `sunxi_cipher_exit' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:29: first defined here drivers/crypto/sunxi-ss/sunxi-ss-aes.o: In function `sunxi_cipher_init': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: multiple definition of `sunxi_cipher_init' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: first defined here drivers/crypto/sunxi-ss/sunxi-ss-aes.o: In function `sunxi_des_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: multiple definition of `sunxi_des_poll' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: first defined here drivers/crypto/sunxi-ss/sunxi-ss-aes.o: In function `sunxi_aes_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:33: multiple definition of `sunxi_aes_poll'
Re: [PATCH v4 1/1] crypto: AES CTR x86_64 by8 AVX optimization
On 9 June 2014 19:41, chandramouli narayanan mo...@linux.intel.com wrote:
[...]
@@ -1493,6 +1521,14 @@ static int __init aesni_init(void)
aesni_gcm_enc_tfm = aesni_gcm_enc;
aesni_gcm_dec_tfm = aesni_gcm_dec;
}
+ aesni_ctr_enc_tfm = aesni_ctr_enc;
+#ifdef CONFIG_AS_AVX
+ if (cpu_has_avx) {
+ /* optimize performance of ctr mode encryption trasform */
The trasform typo is also still there. :/
+ aesni_ctr_enc_tfm = aesni_ctr_enc_avx_tfm;
+ pr_info(AES CTR mode by8 optimization enabled\n);
+ }
+#endif
#endif
err = crypto_fpu_init();
Mathias
--
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: [linux-sunxi] [PATCH v2 1/4] crypto: Add Allwinner Security System crypto accelerator
On 06/10/14 08:53, Chen-Yu Tsai wrote: Hi, On Mon, Jun 9, 2014 at 6:59 PM, LABBE Corentin clabbe.montj...@gmail.com wrote: Add support for the Security System included in Allwinner SoC A20. The Security System is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms. Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- drivers/crypto/sunxi-ss/Makefile | 16 ++ drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c | 118 drivers/crypto/sunxi-ss/sunxi-ss-cipher-aes.c | 130 + drivers/crypto/sunxi-ss/sunxi-ss-cipher-des.c | 118 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 362 + drivers/crypto/sunxi-ss/sunxi-ss-cipher.h | 8 + drivers/crypto/sunxi-ss/sunxi-ss-hash-md5.c| 69 + drivers/crypto/sunxi-ss/sunxi-ss-hash-sha1.c | 69 + drivers/crypto/sunxi-ss/sunxi-ss-hash.c| 228 drivers/crypto/sunxi-ss/sunxi-ss-hash.h| 9 + drivers/crypto/sunxi-ss/sunxi-ss-rng.c | 115 drivers/crypto/sunxi-ss/sunxi-ss.c | 190 + drivers/crypto/sunxi-ss/sunxi-ss.h | 161 +++ 13 files changed, 1593 insertions(+) create mode 100644 drivers/crypto/sunxi-ss/Makefile create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-aes.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-des.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.h create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash-md5.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash-sha1.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.h create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-rng.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.c create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile new file mode 100644 index 000..de4556b --- /dev/null +++ b/drivers/crypto/sunxi-ss/Makefile @@ -0,0 +1,16 @@ +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o + +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_PRNG) += sunxi-ss-rng.o + +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_DES) += sunxi-ss-des.o +sunxi-ss-des-y += sunxi-ss-cipher-des.o sunxi-ss-cipher.o +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_3DES) += sunxi-ss-3des.o +sunxi-ss-3des-y += sunxi-ss-cipher-3des.o sunxi-ss-cipher.o + +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_AES) += sunxi-ss-aes.o +sunxi-ss-aes-y += sunxi-ss-cipher-aes.o sunxi-ss-cipher.o I just tried building Hans' (CC-ed) sunxi-devel branch, which includes this series, with all the Security System options enabled. It doesn't build: LD drivers/crypto/sunxi-ss/built-in.o drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_cipher_init': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: multiple definition of `sunxi_cipher_init' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: first defined here drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_des_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: multiple definition of `sunxi_des_poll' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: first defined here drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_aes_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:33: multiple definition of `sunxi_aes_poll' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:33: first defined here drivers/crypto/sunxi-ss/sunxi-ss-3des.o: In function `sunxi_cipher_exit': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:29: multiple definition of `sunxi_cipher_exit' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:29: first defined here drivers/crypto/sunxi-ss/sunxi-ss-aes.o: In function `sunxi_cipher_init': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: multiple definition of `sunxi_cipher_init' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:24: first defined here drivers/crypto/sunxi-ss/sunxi-ss-aes.o: In function `sunxi_des_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: multiple definition of `sunxi_des_poll' drivers/crypto/sunxi-ss/sunxi-ss-des.o:/home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:218: first defined here drivers/crypto/sunxi-ss/sunxi-ss-aes.o: In function `sunxi_aes_poll': /home/wens/sunxi/linux/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c:33: multiple definition
Re: [PATCH v3 1/3] crypto: qce: Qualcomm crypto engine driver
Hi Joe, On 06/09/2014 07:46 PM, Joe Perches wrote: On Mon, 2014-06-09 at 15:08 +0300, Stanimir Varbanov wrote: The driver is separated by functional parts. The core part implements a platform driver probe and remove callbaks. The probe enables clocks, checks crypto version, initialize and request dma channels, create done tasklet and init crypto queue and finally register the algorithms into crypto core subsystem. trivia: diff --git a/drivers/crypto/qce/dma.h b/drivers/crypto/qce/dma.h [] +#define AUTH_NONCE_NUM_WORDS_SHIFT 20 +#define AUTH_NONCE_NUM_WORDS_MASK GENMASK(22, 20); Unnecessary semicolon and appears to be unused. Will correct, thanks. It is unused because I dropped out AEAD support from this set. I plan to add AEAD incrementally later on. -- regards, Stan -- 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 v3 4/4] ARM: sunxi: dt: Add DT bindings documentation for SUNXI Security System
This patch adds documentation for Device-Tree bindings for the Security System cryptographic accelerator driver. Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 + 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt new file mode 100644 index 000..a566803 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt @@ -0,0 +1,9 @@ +* Allwinner Security System found on A20 SoC + +Required properties: +- compatible : Should be allwinner,sun7i-a20-crypto. +- reg: Should contain the Security System register location and length. +- interrupts: Should contain the IRQ line for the Security System. +- clocks : A phandle to the functional clock node of the Security System module +- clock-names : Name of the functional clock, should be ahb and mod. + -- 1.8.5.5 -- 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 v3] crypto: Add Allwinner Security System crypto accelerator
Hello This is the driver for the Security System included in Allwinner SoC A20. The Security System (SS for short) is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms. It could be found on others Allwinner SoC: - A10s and A31 diagram speak about it with precisions (AES/DES/3DES/Md5/SHA1/PRNG) - A10 and A13 manual give the same datasheet for SS than A20 - A23 speak about a security system but without precisions But I do not have access on any of those hardware, tests are welcome. This driver currently supports: - MD5 and SHA1 hash algorithms - AES block cipher in CBC mode with 128/196/256bits keys. - DES and 3DES block cipher in CBC mode - PRNG The driver exposes all those algorithms through the kernel cryptographic API. The driver support only CPU driven (aka poll mode) transfer mode since the DMA engine of the A20 does not have a driver yet. Changes since v2: - Fix Makefile and Kconfig for static kernel. Changes since v1: - annotate ss-base as __iomem - regroup all mutex in the ss_ctx structure - splited driver in 7 modules (core md5 sha1 aes des 3des prng) in sunxi-ss directory - use dev_exit_p() for .remove - added missing CRYPTO_BLKCIPHER dep in Kconfig - use ahash instead of shash - use ablkcipher instead of blkcipher - use crypto_rng_ctx instead of crypto_tfm_ctx - set seed as an u32 - drop useless comment decoration - drop useless debug - ss_ctx is now a static pointer and whole structure being allocated - fix the platform_get_resource/devm_ioremap_resource pattern - invert getting die id and configuring clock - set clock value as a const unsigned long - add MODULE_ALIAS - use define names more consistency (SS_xxx) - fix PRNG errors - respell SS to Security System in DT documentation -- 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 v3 1/4] crypto: Add Allwinner Security System crypto accelerator
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
drivers/crypto/sunxi-ss/Makefile | 19 ++
drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c | 118
drivers/crypto/sunxi-ss/sunxi-ss-cipher-aes.c | 130 +
drivers/crypto/sunxi-ss/sunxi-ss-cipher-des.c | 118
drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 368 +
drivers/crypto/sunxi-ss/sunxi-ss-cipher.h | 8 +
drivers/crypto/sunxi-ss/sunxi-ss-hash-md5.c| 69 +
drivers/crypto/sunxi-ss/sunxi-ss-hash-sha1.c | 69 +
drivers/crypto/sunxi-ss/sunxi-ss-hash.c| 234
drivers/crypto/sunxi-ss/sunxi-ss-hash.h| 9 +
drivers/crypto/sunxi-ss/sunxi-ss-rng.c | 115
drivers/crypto/sunxi-ss/sunxi-ss.c | 190 +
drivers/crypto/sunxi-ss/sunxi-ss.h | 161 +++
13 files changed, 1608 insertions(+)
create mode 100644 drivers/crypto/sunxi-ss/Makefile
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-aes.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher-des.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.h
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash-md5.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash-sha1.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.h
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-rng.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
new file mode 100644
index 000..21e0c3c
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -0,0 +1,19 @@
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
+
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_PRNG) += sunxi-ss-rng.o
+
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_CIPHER) += sunxi-ss-cipher.o
+
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_DES) += sunxi-ss-des.o
+sunxi-ss-des-y += sunxi-ss-cipher-des.o
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_3DES) += sunxi-ss-3des.o
+sunxi-ss-3des-y += sunxi-ss-cipher-3des.o
+
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_AES) += sunxi-ss-aes.o
+sunxi-ss-aes-y += sunxi-ss-cipher-aes.o
+
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_HASH) += sunxi-ss-hash.o
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_MD5) += sunxi-ss-md5.o
+sunxi-ss-md5-y += sunxi-ss-hash-md5.o
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS_SHA1) += sunxi-ss-sha1.o
+sunxi-ss-sha1-y += sunxi-ss-hash-sha1.o
diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c
b/drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c
new file mode 100644
index 000..fcdc8a4
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher-3des.c
@@ -0,0 +1,118 @@
+/*
+ * sunxi-ss.c - hardware cryptographic accelerator for Allwinner A20 SoC
+ *
+ * Copyright (C) 2013-2014 Corentin LABBE clabbe.montj...@gmail.com
+ *
+ * Support AES cipher with 128,192,256 bits keysize.
+ * Support MD5 and SHA1 hash algorithms.
+ * Support DES and 3DES
+ * Support PRNG
+ *
+ * You could find the datasheet at
+ * http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2 of the License
+ */
+#include sunxi-ss-cipher.h
+
+/* check and set the 3DES key, prepare the mode to be used */
+static int sunxi_des3_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct sunxi_req_ctx *op = crypto_ablkcipher_ctx(tfm);
+ if (keylen != 3 * DES_KEY_SIZE) {
+ dev_err(ss-dev, Invalid keylen %u\n, keylen);
+ crypto_ablkcipher_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+ op-keylen = keylen;
+ memcpy(op-key, key, keylen);
+ return 0;
+}
+
+static int sunxi_des3_cbc_encrypt(struct ablkcipher_request *areq)
+{
+ struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
+ struct sunxi_req_ctx *op = crypto_ablkcipher_ctx(tfm);
+
+ if (areq-info == NULL) {
+ dev_info(ss-dev, Empty IV\n);
+ return -EINVAL;
+ }
+
+ op-mode |= SS_ENCRYPTION;
+ op-mode |= SS_OP_3DES;
+ op-mode |= SS_CBC;
+
+ return sunxi_des_poll(areq);
+}
+
+static int sunxi_des3_cbc_decrypt(struct ablkcipher_request *areq)
+{
+ struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
+ struct sunxi_req_ctx *op = crypto_ablkcipher_ctx(tfm);
+
+ if (areq-info == NULL) {
+
[PATCH v3 2/4] crypto: Update makefile and Kconfig for Security System
Add necessary changes for configuring and compiling the Security System driver. Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- drivers/crypto/Kconfig | 91 + drivers/crypto/Makefile | 1 + 2 files changed, 92 insertions(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 03ccdb0..ed1c918 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -418,4 +418,95 @@ config CRYPTO_DEV_MXS_DCP To compile this driver as a module, choose M here: the module will be called mxs-dcp. +config CRYPTO_DEV_SUNXI_SS + tristate Support for Allwinner Security System cryptographic accelerator + depends on ARCH_SUNXI + help + Some Allwinner SoC have a crypto accelerator named + Security System. Select this if you want to use it. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss. + +if CRYPTO_DEV_SUNXI_SS +config CRYPTO_DEV_SUNXI_SS_PRNG + tristate Security System PRNG + select CRYPTO_RNG2 + help + If you enable this option, the SS will provide a pseudo random + number generator. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss-prng. + +config CRYPTO_DEV_SUNXI_SS_HASH + tristate Security System hash common + help + Common parts of Security System shared by hash algorithms. + +config CRYPTO_DEV_SUNXI_SS_CIPHER + tristate Security System cipher common + help + Common parts of Security System shared by cipher algorithms. + +config CRYPTO_DEV_SUNXI_SS_MD5 + tristate Security System MD5 + select CRYPTO_MD5 + select CRYPTO_DEV_SUNXI_SS_HASH + help + If you enable this option, the SS will provide MD5 hardware + acceleration. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss-md5. + +config CRYPTO_DEV_SUNXI_SS_SHA1 + tristate Security System SHA1 + select CRYPTO_SHA1 + select CRYPTO_DEV_SUNXI_SS_HASH + help + If you enable this option, the SS will provide SHA1 hardware + acceleration. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss-sha1. + +config CRYPTO_DEV_SUNXI_SS_AES + tristate Security System AES + select CRYPTO_AES + select CRYPTO_BLKCIPHER + select CRYPTO_DEV_SUNXI_SS_CIPHER + help + If you enable this option, the SS will provide AES hardware + acceleration. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss-aes. + +config CRYPTO_DEV_SUNXI_SS_DES + tristate Security System DES + select CRYPTO_DES + select CRYPTO_BLKCIPHER + select CRYPTO_DEV_SUNXI_SS_CIPHER + help + If you enable this option, the SS will provide DES hardware + acceleration. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss-des. + +config CRYPTO_DEV_SUNXI_SS_3DES + tristate Security System 3DES + select CRYPTO_DES + select CRYPTO_BLKCIPHER + select CRYPTO_DEV_SUNXI_SS_CIPHER + help + If you enable this option, the SS will provide 3DES hardware + acceleration. + + To compile this driver as a module, choose M here: the module + will be called sunxi-ss-3des. + +endif #CRYPTO_DEV_SUNXI_SS + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 482f090..855292a 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -23,3 +23,4 @@ obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/ -- 1.8.5.5 -- 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 v3 3/4] ARM: sun7i: dt: Add Security System to A20 SoC DTS
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6acdbdf..19b1ced 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -529,6 +529,14 @@
status = disabled;
};
+ crypto: crypto-engine@01c15000 {
+ compatible = allwinner,sun7i-a20-crypto;
+ reg = 0x01c15000 0x1000;
+ interrupts = 0 86 4;
+ clocks = ahb_gates 5, ss_clk;
+ clock-names = ahb, mod;
+ };
+
spi2: spi@01c17000 {
compatible = allwinner,sun4i-a10-spi;
reg = 0x01c17000 0x1000;
--
1.8.5.5
--
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 v5 1/1] crypto: AES CTR x86_64 by8 AVX optimization
This patch introduces by8 AES CTR mode AVX optimization inspired by Intel Optimized IPSEC Cryptograhpic library. For additional information, please see: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=22972 The functions aes_ctr_enc_128_avx_by8(), aes_ctr_enc_192_avx_by8() and aes_ctr_enc_256_avx_by8() are adapted from Intel Optimized IPSEC Cryptographic library. When both AES and AVX features are enabled in a platform, the glue code in AESNI module overrieds the existing by4 CTR mode en/decryption with the by8 AES CTR mode en/decryption. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, the by8 CTR mode optimization shows better performance results across data key sizes as measured by tcrypt. The average performance improvement of the by8 version over the by4 version is as follows: For 128 bit key and data sizes = 256 bytes, there is a 10-16% improvement. For 192 bit key and data sizes = 256 bytes, there is a 20-22% improvement. For 256 bit key and data sizes = 256 bytes, there is a 20-25% improvement. A typical run of tcrypt with AES CTR mode encryption of the by4 and by8 optimization shows the following results: tcrypt with by4 AES CTR mode encryption optimization on a Haswell Desktop: --- testing speed of __ctr-aes-aesni encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 343 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 336 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 491 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 1130 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 7309 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 346 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 361 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 543 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 1321 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 9649 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 369 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 366 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 595 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1531 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 10522 cycles (8192 bytes) testing speed of __ctr-aes-aesni decryption test 0 (128 bit key, 16 byte blocks): 1 operation in 336 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 350 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 487 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 1129 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 7287 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 350 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 359 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 635 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 1324 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 9595 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 364 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 377 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 604 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1527 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 10549 cycles (8192 bytes) tcrypt with by8 AES CTR mode encryption optimization on a Haswell Desktop: --- testing speed of __ctr-aes-aesni encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 340 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 330 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 450 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 1043 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 6597 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 339 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 352 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 539 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 1153 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 8458 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 353 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 360 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 512 cycles (256 bytes) test 13 (256 bit key, 1024 byte
Re: [PATCH v5 1/1] crypto: AES CTR x86_64 by8 AVX optimization
On 10 June 2014 18:22, chandramouli narayanan mo...@linux.intel.com wrote: This patch introduces by8 AES CTR mode AVX optimization inspired by Intel Optimized IPSEC Cryptograhpic library. For additional information, please see: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=22972 The functions aes_ctr_enc_128_avx_by8(), aes_ctr_enc_192_avx_by8() and aes_ctr_enc_256_avx_by8() are adapted from Intel Optimized IPSEC Cryptographic library. When both AES and AVX features are enabled in a platform, the glue code in AESNI module overrieds the existing by4 CTR mode en/decryption with the by8 AES CTR mode en/decryption. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, the by8 CTR mode optimization shows better performance results across data key sizes as measured by tcrypt. The average performance improvement of the by8 version over the by4 version is as follows: For 128 bit key and data sizes = 256 bytes, there is a 10-16% improvement. For 192 bit key and data sizes = 256 bytes, there is a 20-22% improvement. For 256 bit key and data sizes = 256 bytes, there is a 20-25% improvement. A typical run of tcrypt with AES CTR mode encryption of the by4 and by8 optimization shows the following results: tcrypt with by4 AES CTR mode encryption optimization on a Haswell Desktop: --- testing speed of __ctr-aes-aesni encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 343 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 336 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 491 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 1130 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 7309 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 346 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 361 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 543 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 1321 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 9649 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 369 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 366 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 595 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1531 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 10522 cycles (8192 bytes) testing speed of __ctr-aes-aesni decryption test 0 (128 bit key, 16 byte blocks): 1 operation in 336 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 350 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 487 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 1129 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 7287 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 350 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 359 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 635 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 1324 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 9595 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 364 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 377 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 604 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1527 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 10549 cycles (8192 bytes) tcrypt with by8 AES CTR mode encryption optimization on a Haswell Desktop: --- testing speed of __ctr-aes-aesni encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 340 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 330 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 450 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 1043 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 6597 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 339 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 352 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 539 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 1153 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 8458 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 353 cycles (16 bytes) test 11
RE: [PATCH] crypto:caam - Modify width of few read only registers
Hi Kim, I contacted the Hardware folks and below is the statement from them : Unfortunately setting the DWT bit will also affect the operation of job descriptors, so I don't think that is a viable option. It looks like you will have to change the software to access all 32-bit registers as 32-bit quantities, even if two 32-bit registers appear to be two halves of a 64-bit register. If you do that it will work correctly on both big-endian and little-endian SoCs. Regards, Ruchika -Original Message- From: Kim Phillips [mailto:kim.phill...@freescale.com] Sent: Thursday, May 08, 2014 5:25 AM To: Gupta Ruchika-R66431 Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au Subject: Re: [PATCH] crypto:caam - Modify width of few read only registers On Tue, 6 May 2014 23:09:15 -0500 Gupta Ruchika-R66431 ruchika.gu...@freescale.com wrote: Hi Kim, Hi Ruchika, From: Kim Phillips [mailto:kim.phill...@freescale.com] Sent: Wednesday, May 07, 2014 2:02 AM On Tue, 6 May 2014 05:11:23 -0500 Gupta Ruchika-R66431 ruchika.gu...@freescale.com wrote: From: Kim Phillips [mailto:kim.phill...@freescale.com] Sent: Friday, May 02, 2014 2:15 AM On Tue, 29 Apr 2014 15:34:37 +0530 Ruchika Gupta ruchika.gu...@freescale.com wrote: Few read only registers like CHAVID, CTPR etc were wrongly defined as 64 bit registers. This functioned properly on the powerpc platforms. However ARM SoC's wouldn't function correctly if these registers are defined as 64 bit. why wouldn't they function correctly? The SEC IP guide states these registers as 2 32 bit registers. So register definition in I'm looking at LS2100A's SEC reference manual, it clearly has the CHAVID defined as one, single 64-bit register. What are you looking at? In the first version of guide they were defined as 64 bit. They were later changed to 32 bit once issue was reported while testing on emulator. Latest guide of LS2100 has them modified. A register width column has also been added in the memory map now. I love how they try to cover up h/w bugs by amending the documentation... crypto code should also have them defined as 32 bit registers. Defining them as 64 bit in this case would be incorrect. Endianness of the CAAM IP varies with core's endiannes. In ARM SoC's , CAAM block is also little endian. So in case the 2 - 32 bit registers are treated as a 64 bit register, the result would be word swapped as compared to powerpc platforms. As a result, the reads won't return the right result. For eg. For the 2 32 bit registers CHAVID_MS(at address 0x0) and CHAVID_LS(address 0x4) , if core reads them as 64 bit word, In powerpc (big endian) platform - CHAVID_MS would be available in most significant portion of the 64 bit word. CHAVID_LS would be the in least significant portion. This is as expected. In ARM (little endian) platform, 64 bit read would result in - CHAVID_MS in Least significant portion of the word and CHAVID_LS in the most significant location. This result is word swapped and the value read wouldn't be correct. hmm, have you looked at using the DWT Double Word Transpose bit in the MCFGR? I am not able to locate this bit in MCFGR. It's bit 19: Double Word Transpose. Setting this bit affects whether the two words within a Dword are transposed when a double-word register is accessed, ... However there are few swapping options present in Job ring configuration and QICTL registers. Are you referring to these ? no. Plus, those don't sound relevant to accessing CHAVID... Since these are 32 bit registers by nature, shouldn't we just treat them as 32 bit instead of enabling the swapping option . depends on the definition of 'treat': I'd rather still use the superior 64- bit accessors on all possible arches, if we can get them to work. Kim -- 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
