tcrypt.ko module usage
HI All, As I understand tcrypt.ko module purpose is to test different crypto algorithm from the kenrel space. Please can some one help me with below queries to understand tcrypt use cases. #1:If one need to test crypto algorithms with under laying crypto Hardware engine using tcrypto module ,is there any method or procedure needs to be followed to hook crypto hardware engine with tcrypt module? As per my understanding its very much straight forward,like if i need to test aes algorithm then it will be some thing like "insmod tcrypt.ko mode = 10" #2: Is there any way to test tcrypt module for some scenarios like 2.a:concurrency scenario where multiple processes/threads try to send a request for same algorithm 2.b:multiple requests with a same tfm object 2.c:back logged message scenarios like multiple methods will be sent for processing while crypto engine is serving a request from same tfm object #3:Is there any significance with "CONFIG_CRYPTO_MANAGER_DISABLE_TESTS" Flag? ,Because when I disable this flags I observed that tcrypt module fails with a message like "Failed to load transform for cbc(aes): -2" BR, Srisowj -- 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 v2] crypto: omap-sham: Check for return value from pm_runtime_get_sync
Function pm_runtime_get_sync could fail and we need to check return
value to prevent kernel crash.
Signed-off-by: Pali Rohár
---
v2: Check return value for all pm_runtime_get_sync() calls
---
drivers/crypto/omap-sham.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b20e374..c5df53d 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -362,7 +362,13 @@ static void omap_sham_copy_ready_hash(struct ahash_request
*req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- pm_runtime_get_sync(dd->dev);
+ int err;
+
+ err = pm_runtime_get_sync(dd->dev);
+ if (err < 0) {
+ dev_err(dd->dev, "failed to get sync: %d\n", err);
+ return err;
+ }
if (!test_bit(FLAGS_INIT, &dd->flags)) {
set_bit(FLAGS_INIT, &dd->flags);
@@ -1949,7 +1955,13 @@ static int omap_sham_probe(struct platform_device *pdev)
dd->flags |= dd->pdata->flags;
pm_runtime_enable(dev);
- pm_runtime_get_sync(dev);
+
+ err = pm_runtime_get_sync(dev);
+ if (err < 0) {
+ dev_err(dev, "failed to get sync: %d\n", err);
+ goto err_pm;
+ }
+
rev = omap_sham_read(dd, SHA_REG_REV(dd));
pm_runtime_put_sync(&pdev->dev);
@@ -1979,6 +1991,7 @@ err_algs:
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_ahash(
&dd->pdata->algs_info[i].algs_list[j]);
+err_pm:
pm_runtime_disable(dev);
if (dd->dma_lch)
dma_release_channel(dd->dma_lch);
@@ -2021,7 +2034,11 @@ static int omap_sham_suspend(struct device *dev)
static int omap_sham_resume(struct device *dev)
{
- pm_runtime_get_sync(dev);
+ int err = pm_runtime_get_sync(dev);
+ if (err < 0) {
+ dev_err(dev, "failed to get sync: %d\n", err);
+ return err;
+ }
return 0;
}
#endif
--
1.7.9.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
Re: [PATCH 00/10] omap3 crypto fixes
On Friday 06 March 2015 23:23:06 Aaro Koskinen wrote: > Hi, > > On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: > > Are there any fixes in this series that should go into > > v4.0-rc series, or can it all wait for v4.1? > > I think these all should wait for v4.1. > > A. I would suggest to include at least patches 01, 04, 06. Probably those could go to -stable tree... but this decision is up to you. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: tcrypt.ko module usage
Am Sonntag, 8. März 2015, 14:32:53 schrieb sri sowj:
Hi sri,
> HI All,
>
>
> As I understand tcrypt.ko module purpose is to test different crypto
> algorithm from the kenrel space. Please can some one help me with
> below queries to understand tcrypt use cases.
>
> #1:If one need to test crypto algorithms with under laying crypto
> Hardware engine using tcrypto module ,is there any method or
> procedure needs to be followed to hook crypto hardware engine with
> tcrypt module?
>
> As per my understanding its very much straight forward,like if i need
> to test aes algorithm then it will be some thing like "insmod
> tcrypt.ko mode = 10"
That works if you ensured that your implementation has the highest priority of
all implementations marked with the cipher names listed in case 10 (as per
your example):
case 10:
ret += tcrypt_test("ecb(aes)");
ret += tcrypt_test("cbc(aes)");
ret += tcrypt_test("lrw(aes)");
ret += tcrypt_test("xts(aes)");
ret += tcrypt_test("ctr(aes)");
ret += tcrypt_test("rfc3686(ctr(aes))");
break;
>
> #2: Is there any way to test tcrypt module for some scenarios like
>2.a:concurrency scenario where multiple processes/threads try
> to send a request for same algorithm
This is not implemented with tcrypt. But you can either expand tcrypt,
implement your own test, test it from user space with the speed test provided
in [1] or use another implementation of the speed test that may easy be
expanded [2].
[1] http://www.chronox.de/libkcapi.html
[2] https://www.eperm.de/cryptoperf.html
>2.b:multiple requests with a same tfm object
dto
>2.c:back logged message scenarios like multiple methods will be
> sent for processing while crypto engine is serving a request from same
> tfm object
dto
>
> #3:Is there any significance with
> "CONFIG_CRYPTO_MANAGER_DISABLE_TESTS" Flag? ,Because when I disable
> this flags I observed that tcrypt module
> fails with a message like "Failed to load transform for cbc(aes): -2"
This flag relates to the testmgr.c which implements known answer tests
executed at the time a cipher implementation is registered.
>
>
> BR,
> Srisowj
> --
> 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
--
Ciao
Stephan
--
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: tcrypt.ko module usage
HI Stephan,
Thank you very much for the information provided.
It was a great help with quick response, I really appreciate your
efforts and the time.
If possible can you please help me to understand on how to handle
backlog messages from crypto kernel driver?
BR,
Srisowj
On Sun, Mar 8, 2015 at 3:54 PM, Stephan Mueller wrote:
> Am Sonntag, 8. März 2015, 14:32:53 schrieb sri sowj:
>
> Hi sri,
>
>> HI All,
>>
>>
>> As I understand tcrypt.ko module purpose is to test different crypto
>> algorithm from the kenrel space. Please can some one help me with
>> below queries to understand tcrypt use cases.
>>
>> #1:If one need to test crypto algorithms with under laying crypto
>> Hardware engine using tcrypto module ,is there any method or
>> procedure needs to be followed to hook crypto hardware engine with
>> tcrypt module?
>>
>> As per my understanding its very much straight forward,like if i need
>> to test aes algorithm then it will be some thing like "insmod
>> tcrypt.ko mode = 10"
>
> That works if you ensured that your implementation has the highest priority of
> all implementations marked with the cipher names listed in case 10 (as per
> your example):
>
> case 10:
> ret += tcrypt_test("ecb(aes)");
> ret += tcrypt_test("cbc(aes)");
> ret += tcrypt_test("lrw(aes)");
> ret += tcrypt_test("xts(aes)");
> ret += tcrypt_test("ctr(aes)");
> ret += tcrypt_test("rfc3686(ctr(aes))");
> break;
>
>>
>> #2: Is there any way to test tcrypt module for some scenarios like
>>2.a:concurrency scenario where multiple processes/threads try
>> to send a request for same algorithm
>
> This is not implemented with tcrypt. But you can either expand tcrypt,
> implement your own test, test it from user space with the speed test provided
> in [1] or use another implementation of the speed test that may easy be
> expanded [2].
>
> [1] http://www.chronox.de/libkcapi.html
> [2] https://www.eperm.de/cryptoperf.html
>
>>2.b:multiple requests with a same tfm object
>
> dto
>
>>2.c:back logged message scenarios like multiple methods will be
>> sent for processing while crypto engine is serving a request from same
>> tfm object
>
> dto
>>
>> #3:Is there any significance with
>> "CONFIG_CRYPTO_MANAGER_DISABLE_TESTS" Flag? ,Because when I disable
>> this flags I observed that tcrypt module
>> fails with a message like "Failed to load transform for cbc(aes): -2"
>
> This flag relates to the testmgr.c which implements known answer tests
> executed at the time a cipher implementation is registered.
>>
>>
>> BR,
>> Srisowj
>> --
>> 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
>
>
> --
> Ciao
> Stephan
--
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 RESEND 0/2] crypto: algif - change algif_skcipher to be asynchronous
Am Freitag, 27. Februar 2015, 11:35:38 schrieb Tadeusz Struk: Hi Tadeusz, > The way the algif_skcipher works currently is that on sendmsg/sendpage it > builds an sgl for the input data and then on read/recvmsg it sends the job > for encryption putting the user to sleep till the data is processed. > This way it can only handle one job at a given time. > To be able to fuly utilize the potential of existing crypto hardware > accelerators it is required to submit multiple jobs in asynchronously. > This series adds support for asynchronous operations for algif_skcipher. > First patch enables af_alg sgl to be linked. > Second patch implement asynch read for skcipher. > > Resend with updates for 4.0 As you may know, I am working on libkcapi [1] to cover the user space AF_ALG interface and provide an easy-to use interface for applications. I am now trying to cover your interface proposal there and also measure the speed of it. What bothers me currently is the following: how would I be able to detect whether the implemented support is available in the current kernel? For the different AF_ALG interfaces (like the recently added AEAD), I can detect missing support at the time I call the socket() syscall. Thus, the application knows right from the start whether we have the requested support. But for the AIO interface, how can I detect that at runtime at a time an application can reasonably catch a missing support? [1] http://www.chronox.de/libkcapi.html > > Signed-off-by: Tadeusz Struk > --- > Tadeusz Struk (2): > crypto: af_alg - Allow to link sgl > crypto: algif - change algif_skcipher to be asynchronous > > > crypto/af_alg.c | 18 ++- > crypto/algif_skcipher.c | 308 > ++- include/crypto/if_alg.h | > 4 - > 3 files changed, 317 insertions(+), 13 deletions(-) > -- > 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 -- Ciao Stephan -- 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 00/10] omap3 crypto fixes
On Sun, 8 Mar 2015, Pali Rohár wrote: > On Friday 06 March 2015 23:23:06 Aaro Koskinen wrote: > > On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: > > > Are there any fixes in this series that should go into > > > v4.0-rc series, or can it all wait for v4.1? > > > > I think these all should wait for v4.1. > > > > A. > > I would suggest to include at least patches 01, 04, 06. Probably > those could go to -stable tree... but this decision is up to you. I'm not sure patch 1 is a fix. As far as I know we haven't run into any issues with it on real hardware - only on QEMU - unless you know otherwise, Pali? Are we sure that the QEMU model behavior matches the hardware? - Paul
[PATCH] crypto: AES-NI: fix memory usage in GCM decryption
The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size.
This patch simply subtracts the authentication tag size from cryptlen.
The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
caculate the size of the plaintext output itself and cannot simply use
cryptlen.
Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) without it (simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes).
[1] http://www.chronox.de/libkcapi.html
CC: Tadeusz Struk
Signed-off-by: Stephan Mueller
---
arch/x86/crypto/aesni-intel_glue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 6893f49..8f7900e8 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1160,7 +1160,8 @@ static int __driver_rfc4106_decrypt(struct aead_request
*req)
scatterwalk_done(&src_sg_walk, 0, 0);
scatterwalk_done(&assoc_sg_walk, 0, 0);
} else {
- scatterwalk_map_and_copy(dst, req->dst, 0, req->cryptlen, 1);
+ scatterwalk_map_and_copy(dst, req->dst, 0,
+(req->cryptlen - auth_tag_len), 1);
kfree(src);
}
return retval;
--
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 0/7] crypto: OCTEON MD5 bugfix + SHA modules
Hi, The first patch is a bug fix for OCTEON MD5 aimed for 4.0-rc cycle. The remaining patches add SHA1/SHA256/SHA512 modules. I have tested these on the following OCTEON boards and CPUs with 4.0-rc2: D-Link DSR-1000N: CN5010p1.1-500-SCP EdgeRouter Lite:CN5020p1.1-500-SCP EdgeRouter Pro: CN6120p1.1-1000-NSP All selftests are passing. With tcrypt, I get the following numbers on speed compared to the generic modules: SHA1: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 1.25x faster test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 1.20x faster test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 1.47x faster test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 1.15x faster test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 1.56x faster test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 2.27x faster test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 1.13x faster test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 2.74x faster test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 3.60x faster test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 1.13x faster test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 2.87x faster test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 3.90x faster test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 4.18x faster test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 1.13x faster test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 2.95x faster test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 4.09x faster test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 4.57x faster test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 1.13x faster test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 2.99x faster test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 4.20x faster test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 4.72x faster test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 4.73x faster SHA256: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 2.72x faster test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 2.45x faster test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 3.65x faster test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 2.18x faster test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 3.74x faster test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 5.72x faster test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 2.08x faster test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 6.54x faster test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 8.19x faster test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 2.06x faster test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 6.77x faster test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 8.56x faster test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 9.01x faster test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 2.05x faster test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 6.89x faster test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 8.82x faster test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 9.50x faster test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 2.04x faster test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 6.96x faster test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 8.95x faster test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 9.66x faster test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 9.67x faster SHA512: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 3.19x faster test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 2.18x faster test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 3.19x faster test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 2.12x faster test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 3.54x faster test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 5.16x faster test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 1.92x faster test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 5.80x faster test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 8.07x faster test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 1.88x faster test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 6.00x faster test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 8.64x faster test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 9.40x faster test 13 ( 4096 byte blocks, 16
[PATCH 3/7] crypto: octeon - add instruction definitions for SHA1/256/512
Add instruction definitions for SHA1/256/512.
Signed-off-by: Aaro Koskinen
---
arch/mips/cavium-octeon/crypto/octeon-crypto.h | 83 --
1 file changed, 79 insertions(+), 4 deletions(-)
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
index e2a4aec..3550725 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
@@ -5,7 +5,8 @@
*
* Copyright (C) 2012-2013 Cavium Inc., All Rights Reserved.
*
- * MD5 instruction definitions added by Aaro Koskinen .
+ * MD5/SHA1/SHA256/SHA512 instruction definitions added by
+ * Aaro Koskinen .
*
*/
#ifndef __LINUX_OCTEON_CRYPTO_H
@@ -21,11 +22,11 @@ extern void octeon_crypto_disable(struct octeon_cop2_state
*state,
unsigned long flags);
/*
- * Macros needed to implement MD5:
+ * Macros needed to implement MD5/SHA1/SHA256:
*/
/*
- * The index can be 0-1.
+ * The index can be 0-1 (MD5) or 0-2 (SHA1), 0-3 (SHA256).
*/
#define write_octeon_64bit_hash_dword(value, index)\
do { \
@@ -36,7 +37,7 @@ do { \
} while (0)
/*
- * The index can be 0-1.
+ * The index can be 0-1 (MD5) or 0-2 (SHA1), 0-3 (SHA256).
*/
#define read_octeon_64bit_hash_dword(index)\
({ \
@@ -72,4 +73,78 @@ do { \
: [rt] "d" (value));\
} while (0)
+/*
+ * The value is the final block dword (64-bit).
+ */
+#define octeon_sha1_start(value) \
+do { \
+ __asm__ __volatile__ ( \
+ "dmtc2 %[rt],0x4057"\
+ : \
+ : [rt] "d" (value));\
+} while (0)
+
+/*
+ * The value is the final block dword (64-bit).
+ */
+#define octeon_sha256_start(value) \
+do { \
+ __asm__ __volatile__ ( \
+ "dmtc2 %[rt],0x404f"\
+ : \
+ : [rt] "d" (value));\
+} while (0)
+
+/*
+ * Macros needed to implement SHA512:
+ */
+
+/*
+ * The index can be 0-7.
+ */
+#define write_octeon_64bit_hash_sha512(value, index) \
+do { \
+ __asm__ __volatile__ ( \
+ "dmtc2 %[rt],0x0250+" STR(index)\
+ : \
+ : [rt] "d" (value));\
+} while (0)
+
+/*
+ * The index can be 0-7.
+ */
+#define read_octeon_64bit_hash_sha512(index) \
+({ \
+ u64 __value;\
+ \
+ __asm__ __volatile__ ( \
+ "dmfc2 %[rt],0x0250+" STR(index)\
+ : [rt] "=d" (__value) \
+ : );\
+ \
+ __value;\
+})
+
+/*
+ * The index can be 0-14.
+ */
+#define write_octeon_64bit_block_sha512(value, index) \
+do { \
+ __asm__ __volatile__ ( \
+ "dmtc2 %[rt],0x0240+" STR(index)\
+ : \
+ : [rt] "d" (value));\
+} while (0)
+
+/*
+ * The value is the final block word (64-bit).
+ */
+#define octeon_sha512_start(value) \
+do { \
+ __asm__ __volatile__ ( \
+ "dmtc2 %[rt],0x424f"\
+ : \
+ : [rt] "d" (value));\
+} while (0)
+
#endif /* __LINUX_OCTEON_CRYPTO_H */
--
2.2.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 6/7] crypto: octeon - add SHA512 module
Add OCTEON SHA512 module.
Signed-off-by: Aaro Koskinen
---
arch/mips/cavium-octeon/crypto/Makefile| 1 +
arch/mips/cavium-octeon/crypto/octeon-sha512.c | 277 +
2 files changed, 278 insertions(+)
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha512.c
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
index 47806a5..f7aa9d5 100644
--- a/arch/mips/cavium-octeon/crypto/Makefile
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -7,3 +7,4 @@ obj-y += octeon-crypto.o
obj-$(CONFIG_CRYPTO_MD5_OCTEON)+= octeon-md5.o
obj-$(CONFIG_CRYPTO_SHA1_OCTEON) += octeon-sha1.o
obj-$(CONFIG_CRYPTO_SHA256_OCTEON) += octeon-sha256.o
+obj-$(CONFIG_CRYPTO_SHA512_OCTEON) += octeon-sha512.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-sha512.c
b/arch/mips/cavium-octeon/crypto/octeon-sha512.c
new file mode 100644
index 000..d5fb3c6
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-sha512.c
@@ -0,0 +1,277 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-512 and SHA-384 Secure Hash Algorithm.
+ *
+ * Adapted for OCTEON by Aaro Koskinen .
+ *
+ * Based on crypto/sha512_generic.c, which is:
+ *
+ * Copyright (c) Jean-Luc Cooke
+ * Copyright (c) Andrew McDonald
+ * Copyright (c) 2003 Kyle McMartin
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "octeon-crypto.h"
+
+/*
+ * We pass everything as 64-bit. OCTEON can handle misaligned data.
+ */
+
+static void octeon_sha512_store_hash(struct sha512_state *sctx)
+{
+ write_octeon_64bit_hash_sha512(sctx->state[0], 0);
+ write_octeon_64bit_hash_sha512(sctx->state[1], 1);
+ write_octeon_64bit_hash_sha512(sctx->state[2], 2);
+ write_octeon_64bit_hash_sha512(sctx->state[3], 3);
+ write_octeon_64bit_hash_sha512(sctx->state[4], 4);
+ write_octeon_64bit_hash_sha512(sctx->state[5], 5);
+ write_octeon_64bit_hash_sha512(sctx->state[6], 6);
+ write_octeon_64bit_hash_sha512(sctx->state[7], 7);
+}
+
+static void octeon_sha512_read_hash(struct sha512_state *sctx)
+{
+ sctx->state[0] = read_octeon_64bit_hash_sha512(0);
+ sctx->state[1] = read_octeon_64bit_hash_sha512(1);
+ sctx->state[2] = read_octeon_64bit_hash_sha512(2);
+ sctx->state[3] = read_octeon_64bit_hash_sha512(3);
+ sctx->state[4] = read_octeon_64bit_hash_sha512(4);
+ sctx->state[5] = read_octeon_64bit_hash_sha512(5);
+ sctx->state[6] = read_octeon_64bit_hash_sha512(6);
+ sctx->state[7] = read_octeon_64bit_hash_sha512(7);
+}
+
+static void octeon_sha512_transform(const void *_block)
+{
+ const u64 *block = _block;
+
+ write_octeon_64bit_block_sha512(block[0], 0);
+ write_octeon_64bit_block_sha512(block[1], 1);
+ write_octeon_64bit_block_sha512(block[2], 2);
+ write_octeon_64bit_block_sha512(block[3], 3);
+ write_octeon_64bit_block_sha512(block[4], 4);
+ write_octeon_64bit_block_sha512(block[5], 5);
+ write_octeon_64bit_block_sha512(block[6], 6);
+ write_octeon_64bit_block_sha512(block[7], 7);
+ write_octeon_64bit_block_sha512(block[8], 8);
+ write_octeon_64bit_block_sha512(block[9], 9);
+ write_octeon_64bit_block_sha512(block[10], 10);
+ write_octeon_64bit_block_sha512(block[11], 11);
+ write_octeon_64bit_block_sha512(block[12], 12);
+ write_octeon_64bit_block_sha512(block[13], 13);
+ write_octeon_64bit_block_sha512(block[14], 14);
+ octeon_sha512_start(block[15]);
+}
+
+static int octeon_sha512_init(struct shash_desc *desc)
+{
+ struct sha512_state *sctx = shash_desc_ctx(desc);
+
+ sctx->state[0] = SHA512_H0;
+ sctx->state[1] = SHA512_H1;
+ sctx->state[2] = SHA512_H2;
+ sctx->state[3] = SHA512_H3;
+ sctx->state[4] = SHA512_H4;
+ sctx->state[5] = SHA512_H5;
+ sctx->state[6] = SHA512_H6;
+ sctx->state[7] = SHA512_H7;
+ sctx->count[0] = sctx->count[1] = 0;
+
+ return 0;
+}
+
+static int octeon_sha384_init(struct shash_desc *desc)
+{
+ struct sha512_state *sctx = shash_desc_ctx(desc);
+
+ sctx->state[0] = SHA384_H0;
+ sctx->state[1] = SHA384_H1;
+ sctx->state[2] = SHA384_H2;
+ sctx->state[3] = SHA384_H3;
+ sctx->state[4] = SHA384_H4;
+ sctx->state[5] = SHA384_H5;
+ sctx->state[6] = SHA384_H6;
+ sctx->state[7] = SHA384_H7;
+ sctx->count[0] = sctx->count[1] = 0;
+
+ return 0;
+}
+
+static void __octeon_sha512_update(struct sha512_state *sctx, const u8 *data,
+ unsigned int len)
+{
+ unsigned int part_len;
+ unsigned int index;
+ unsigned int i;
[PATCH 2/7] crypto: octeon - always disable preemption when using crypto engine
Always disable preemption on behalf of the drivers when crypto engine is taken into use. This will simplify the usage. Signed-off-by: Aaro Koskinen --- arch/mips/cavium-octeon/crypto/octeon-crypto.c | 4 +++- arch/mips/cavium-octeon/crypto/octeon-md5.c| 4 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.c b/arch/mips/cavium-octeon/crypto/octeon-crypto.c index 7c82ff4..f66bd1a 100644 --- a/arch/mips/cavium-octeon/crypto/octeon-crypto.c +++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.c @@ -17,7 +17,7 @@ * crypto operations in calls to octeon_crypto_enable/disable in order to make * sure the state of COP2 isn't corrupted if userspace is also performing * hardware crypto operations. Allocate the state parameter on the stack. - * Preemption must be disabled to prevent context switches. + * Returns with preemption disabled. * * @state: Pointer to state structure to store current COP2 state in. * @@ -28,6 +28,7 @@ unsigned long octeon_crypto_enable(struct octeon_cop2_state *state) int status; unsigned long flags; + preempt_disable(); local_irq_save(flags); status = read_c0_status(); write_c0_status(status | ST0_CU2); @@ -62,5 +63,6 @@ void octeon_crypto_disable(struct octeon_cop2_state *state, else write_c0_status(read_c0_status() & ~ST0_CU2); local_irq_restore(flags); + preempt_enable(); } EXPORT_SYMBOL_GPL(octeon_crypto_disable); diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c b/arch/mips/cavium-octeon/crypto/octeon-md5.c index 3dd8845..12dccdb 100644 --- a/arch/mips/cavium-octeon/crypto/octeon-md5.c +++ b/arch/mips/cavium-octeon/crypto/octeon-md5.c @@ -97,7 +97,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, memcpy((char *)mctx->block + (sizeof(mctx->block) - avail), data, avail); - preempt_disable(); flags = octeon_crypto_enable(&state); octeon_md5_store_hash(mctx); @@ -113,7 +112,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, octeon_md5_read_hash(mctx); octeon_crypto_disable(&state, flags); - preempt_enable(); memcpy(mctx->block, data, len); @@ -131,7 +129,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) *p++ = 0x80; - preempt_disable(); flags = octeon_crypto_enable(&state); octeon_md5_store_hash(mctx); @@ -149,7 +146,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) octeon_md5_read_hash(mctx); octeon_crypto_disable(&state, flags); - preempt_enable(); memcpy(out, mctx->hash, sizeof(mctx->hash)); memset(mctx, 0, sizeof(*mctx)); -- 2.2.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 7/7] crypto: octeon - enable OCTEON SHA1/256/512 module selection
Enable user to select OCTEON SHA1/256/512 modules. Signed-off-by: Aaro Koskinen --- crypto/Kconfig | 27 +++ 1 file changed, 27 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 50f4da4..38b2315 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -546,6 +546,15 @@ config CRYPTO_SHA512_SSSE3 Extensions version 1 (AVX1), or Advanced Vector Extensions version 2 (AVX2) instructions, when available. +config CRYPTO_SHA1_OCTEON + tristate "SHA1 digest algorithm (OCTEON)" + depends on CPU_CAVIUM_OCTEON + select CRYPTO_SHA1 + select CRYPTO_HASH + help + SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_SHA1_SPARC64 tristate "SHA1 digest algorithm (SPARC64)" depends on SPARC64 @@ -610,6 +619,15 @@ config CRYPTO_SHA256 This code also includes SHA-224, a 224 bit hash with 112 bits of security against collision attacks. +config CRYPTO_SHA256_OCTEON + tristate "SHA224 and SHA256 digest algorithm (OCTEON)" + depends on CPU_CAVIUM_OCTEON + select CRYPTO_SHA256 + select CRYPTO_HASH + help + SHA-256 secure hash standard (DFIPS 180-2) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_SHA256_SPARC64 tristate "SHA224 and SHA256 digest algorithm (SPARC64)" depends on SPARC64 @@ -631,6 +649,15 @@ config CRYPTO_SHA512 This code also includes SHA-384, a 384 bit hash with 192 bits of security against collision attacks. +config CRYPTO_SHA512_OCTEON + tristate "SHA384 and SHA512 digest algorithms (OCTEON)" + depends on CPU_CAVIUM_OCTEON + select CRYPTO_SHA512 + select CRYPTO_HASH + help + SHA-512 secure hash standard (DFIPS 180-2) implemented + using OCTEON crypto instructions, when available. + config CRYPTO_SHA512_SPARC64 tristate "SHA384 and SHA512 digest algorithm (SPARC64)" depends on SPARC64 -- 2.2.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 1/7] crypto: octeon - don't disable bottom half in octeon-md5
Don't disable bottom half while the crypto engine is in use, as it should be unnecessary: All kernel crypto engine usage is wrapped with crypto engine state save/restore, so if we get interrupted by softirq that uses crypto they should save and restore our context. This actually fixes an issue when running OCTEON MD5 with interrupts disabled (tcrypt mode=302). There's a WARNING because the module is trying to enable the bottom half with irqs disabled: [ 52.656610] [ cut here ] [ 52.661439] WARNING: CPU: 1 PID: 428 at /home/aaro/git/linux/kernel/softirq.c:150 __local_bh_enable_ip+0x9c/0xd8() [ 52.671780] Modules linked in: tcrypt(+) [...] [ 52.763539] [] warn_slowpath_common+0x94/0xd8 [ 52.769465] [] __local_bh_enable_ip+0x9c/0xd8 [ 52.775390] [] octeon_md5_final+0x12c/0x1e8 [ 52.781144] [] shash_compat_digest+0xd0/0x1b0 Signed-off-by: Aaro Koskinen --- arch/mips/cavium-octeon/crypto/octeon-md5.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c b/arch/mips/cavium-octeon/crypto/octeon-md5.c index b909881..3dd8845 100644 --- a/arch/mips/cavium-octeon/crypto/octeon-md5.c +++ b/arch/mips/cavium-octeon/crypto/octeon-md5.c @@ -97,7 +97,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, memcpy((char *)mctx->block + (sizeof(mctx->block) - avail), data, avail); - local_bh_disable(); preempt_disable(); flags = octeon_crypto_enable(&state); octeon_md5_store_hash(mctx); @@ -115,7 +114,6 @@ static int octeon_md5_update(struct shash_desc *desc, const u8 *data, octeon_md5_read_hash(mctx); octeon_crypto_disable(&state, flags); preempt_enable(); - local_bh_enable(); memcpy(mctx->block, data, len); @@ -133,7 +131,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) *p++ = 0x80; - local_bh_disable(); preempt_disable(); flags = octeon_crypto_enable(&state); octeon_md5_store_hash(mctx); @@ -153,7 +150,6 @@ static int octeon_md5_final(struct shash_desc *desc, u8 *out) octeon_md5_read_hash(mctx); octeon_crypto_disable(&state, flags); preempt_enable(); - local_bh_enable(); memcpy(out, mctx->hash, sizeof(mctx->hash)); memset(mctx, 0, sizeof(*mctx)); -- 2.2.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 5/7] crypto: octeon - add SHA256 module
Add OCTEON SHA256 module.
Signed-off-by: Aaro Koskinen
---
arch/mips/cavium-octeon/crypto/Makefile| 1 +
arch/mips/cavium-octeon/crypto/octeon-sha256.c | 280 +
2 files changed, 281 insertions(+)
create mode 100644 arch/mips/cavium-octeon/crypto/octeon-sha256.c
diff --git a/arch/mips/cavium-octeon/crypto/Makefile
b/arch/mips/cavium-octeon/crypto/Makefile
index 3f671d6..47806a5 100644
--- a/arch/mips/cavium-octeon/crypto/Makefile
+++ b/arch/mips/cavium-octeon/crypto/Makefile
@@ -6,3 +6,4 @@ obj-y += octeon-crypto.o
obj-$(CONFIG_CRYPTO_MD5_OCTEON)+= octeon-md5.o
obj-$(CONFIG_CRYPTO_SHA1_OCTEON) += octeon-sha1.o
+obj-$(CONFIG_CRYPTO_SHA256_OCTEON) += octeon-sha256.o
diff --git a/arch/mips/cavium-octeon/crypto/octeon-sha256.c
b/arch/mips/cavium-octeon/crypto/octeon-sha256.c
new file mode 100644
index 000..97e96fe
--- /dev/null
+++ b/arch/mips/cavium-octeon/crypto/octeon-sha256.c
@@ -0,0 +1,280 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-224 and SHA-256 Secure Hash Algorithm.
+ *
+ * Adapted for OCTEON by Aaro Koskinen .
+ *
+ * Based on crypto/sha256_generic.c, which is:
+ *
+ * Copyright (c) Jean-Luc Cooke
+ * Copyright (c) Andrew McDonald
+ * Copyright (c) 2002 James Morris
+ * SHA224 Support Copyright 2007 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "octeon-crypto.h"
+
+/*
+ * We pass everything as 64-bit. OCTEON can handle misaligned data.
+ */
+
+static void octeon_sha256_store_hash(struct sha256_state *sctx)
+{
+ u64 *hash = (u64 *)sctx->state;
+
+ write_octeon_64bit_hash_dword(hash[0], 0);
+ write_octeon_64bit_hash_dword(hash[1], 1);
+ write_octeon_64bit_hash_dword(hash[2], 2);
+ write_octeon_64bit_hash_dword(hash[3], 3);
+}
+
+static void octeon_sha256_read_hash(struct sha256_state *sctx)
+{
+ u64 *hash = (u64 *)sctx->state;
+
+ hash[0] = read_octeon_64bit_hash_dword(0);
+ hash[1] = read_octeon_64bit_hash_dword(1);
+ hash[2] = read_octeon_64bit_hash_dword(2);
+ hash[3] = read_octeon_64bit_hash_dword(3);
+}
+
+static void octeon_sha256_transform(const void *_block)
+{
+ const u64 *block = _block;
+
+ write_octeon_64bit_block_dword(block[0], 0);
+ write_octeon_64bit_block_dword(block[1], 1);
+ write_octeon_64bit_block_dword(block[2], 2);
+ write_octeon_64bit_block_dword(block[3], 3);
+ write_octeon_64bit_block_dword(block[4], 4);
+ write_octeon_64bit_block_dword(block[5], 5);
+ write_octeon_64bit_block_dword(block[6], 6);
+ octeon_sha256_start(block[7]);
+}
+
+static int octeon_sha224_init(struct shash_desc *desc)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+
+ sctx->state[0] = SHA224_H0;
+ sctx->state[1] = SHA224_H1;
+ sctx->state[2] = SHA224_H2;
+ sctx->state[3] = SHA224_H3;
+ sctx->state[4] = SHA224_H4;
+ sctx->state[5] = SHA224_H5;
+ sctx->state[6] = SHA224_H6;
+ sctx->state[7] = SHA224_H7;
+ sctx->count = 0;
+
+ return 0;
+}
+
+static int octeon_sha256_init(struct shash_desc *desc)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+
+ sctx->state[0] = SHA256_H0;
+ sctx->state[1] = SHA256_H1;
+ sctx->state[2] = SHA256_H2;
+ sctx->state[3] = SHA256_H3;
+ sctx->state[4] = SHA256_H4;
+ sctx->state[5] = SHA256_H5;
+ sctx->state[6] = SHA256_H6;
+ sctx->state[7] = SHA256_H7;
+ sctx->count = 0;
+
+ return 0;
+}
+
+static void __octeon_sha256_update(struct sha256_state *sctx, const u8 *data,
+ unsigned int len)
+{
+ unsigned int partial;
+ unsigned int done;
+ const u8 *src;
+
+ partial = sctx->count % SHA256_BLOCK_SIZE;
+ sctx->count += len;
+ done = 0;
+ src = data;
+
+ if ((partial + len) >= SHA256_BLOCK_SIZE) {
+ if (partial) {
+ done = -partial;
+ memcpy(sctx->buf + partial, data,
+ done + SHA256_BLOCK_SIZE);
+ src = sctx->buf;
+ }
+
+ do {
+ octeon_sha256_transform(src);
+ done += SHA256_BLOCK_SIZE;
+ src = data + done;
+ } while (done + SHA256_BLOCK_SIZE <= len);
+
+ partial = 0;
+ }
+ memcpy(sctx->buf + partial, src, len - done);
+}
+
+static int octeon_sha256_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
Re: [PATCH V3 1/2] crypto: Add Imagination Technologies hw hash accelerator
Hi James,
On Thu, Mar 5, 2015 at 7:01 PM, James Hartley wrote:
> This adds support for the Imagination Technologies hash
> accelerator which provides hardware acceleration for
> SHA1 SHA224 SHA256 and MD5 hashes.
>
> Signed-off-by: James Hartley
Some general comments below, I'll leave review of the crypto-specific
stuff to Herbert.
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 3924f93..fb84be7 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam/
> obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
> 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_MXS_DCP) += mxs-dcp.o
> @@ -25,3 +26,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
> obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
> obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
> obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
> +obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
Unrelated change - perhaps a bad merge conflict resolution?
> diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
> new file mode 100644
> index 000..94a3a6f
> --- /dev/null
> +++ b/drivers/crypto/img-hash.c
> @@ -0,0 +1,1037 @@
> +/*
> + * Copyright (c) 2014 Imagination Technologies
> + * Authors: Will Thomas, James Hartley
> + *
> + * 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.
> + *
> + * Interface structure taken from omap-sham driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define CR_RESET 0
> +#define CR_RESET_SET 1
> +#define CR_RESET_UNSET 0
> +
> +#define CR_MESSAGE_LENGTH_H0x4
> +#define CR_MESSAGE_LENGTH_L0x8
> +
> +#define CR_CONTROL 0xc
> +#define CR_CONTROL_BYTE_ORDER_3210 0
> +#define CR_CONTROL_BYTE_ORDER_0123 1
> +#define CR_CONTROL_BYTE_ORDER_2310 2
> +#define CR_CONTROL_BYTE_ORDER_1032 3
> +#define CR_CONTROL_BYTE_ORDER_SHIFT8
> +#define CR_CONTROL_ALGO_MD50
> +#define CR_CONTROL_ALGO_SHA1 1
> +#define CR_CONTROL_ALGO_SHA224 2
> +#define CR_CONTROL_ALGO_SHA256 3
> +
> +#define CR_INTSTAT 0x10
> +#define CR_INTENAB 0x14
> +#define CR_INTCLEAR0x18
> +#define CR_INT_RESULTS_AVAILABLE BIT(0)
> +#define CR_INT_NEW_RESULTS_SET BIT(1)
> +#define CR_INT_RESULT_READ_ERR BIT(2)
> +#define CR_INT_MESSAGE_WRITE_ERROR BIT(3)
> +#define CR_INT_STATUS BIT(8)
> +
> +#define CR_RESULT_QUEUE0x1c
> +#define CR_RSD00x40
> +#define CR_CORE_REV0x50
> +#define CR_CORE_DES1 0x60
> +#define CR_CORE_DES2 0x70
> +
> +#define DRIVER_FLAGS_BUSY BIT(0)
> +#define DRIVER_FLAGS_FINAL BIT(1)
> +#define DRIVER_FLAGS_DMA_ACTIVEBIT(2)
> +#define DRIVER_FLAGS_OUTPUT_READY BIT(3)
> +#define DRIVER_FLAGS_INIT BIT(4)
> +#define DRIVER_FLAGS_CPU BIT(5)
> +#define DRIVER_FLAGS_DMA_READY BIT(6)
> +#define DRIVER_FLAGS_ERROR BIT(7)
> +#define DRIVER_FLAGS_SGBIT(8)
> +#define DRIVER_FLAGS_SHA1 BIT(18)
> +#define DRIVER_FLAGS_SHA224BIT(19)
> +#define DRIVER_FLAGS_SHA256BIT(20)
> +#define DRIVER_FLAGS_MD5 BIT(21)
> +
> +#define IMG_HASH_QUEUE_LENGTH 20
> +#define IMG_HASH_DMA_THRESHOLD 64
> +
> +#ifdef __LITTLE_ENDIAN
> +#define IMG_HASH_BYTE_ORDER(CR_CONTROL_BYTE_ORDER_3210)
> +#else
> +#define IMG_HASH_BYTE_ORDER(CR_CONTROL_BYTE_ORDER_0123)
> +#endif
Unnecessary parenthesis.
> +struct img_hash_dev;
> +
> +struct img_hash_request_ctx {
> + struct img_hash_dev *hdev;
> + u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
> + unsigned long flags;
> + size_t digsize;
> +
> + dma_addr_t dma_addr;
> + size_t dma_ct;
> +
> + /* sg root */
> + struct scatterlist *sgfirst;
> + /* walk state */
> + struct scatterlist *sg;
> + size_t nents;
> + size_t offset;
> + unsigned inttotal;
> + size_t sent;
> +
> + unsigned long op;
> +
> + size_t bufcnt;
> + u8 buffer[0] __aligned(sizeof(u32));
> + struct ahash_requestfallback_req;
> +};
Crypto Fixes for 4.0
Hi Linus: This push fixes a bug in the ARM XTS implementation that can cause failures to in decrypting encrypted disks. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git or master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Ard Biesheuvel (1): crypto: arm/aes update NEON AES module to latest OpenSSL version arch/arm/crypto/aesbs-core.S_shipped | 12 arch/arm/crypto/bsaes-armv7.pl | 12 2 files changed, 16 insertions(+), 8 deletions(-) Thanks, -- Email: Herbert Xu 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 V3 1/2] crypto: Add Imagination Technologies hw hash accelerator
Am Freitag, 6. März 2015, 02:58:26 schrieb James Hartley: Hi James, >This adds support for the Imagination Technologies hash >accelerator which provides hardware acceleration for >SHA1 SHA224 SHA256 and MD5 hashes. > >Signed-off-by: James Hartley >--- > drivers/crypto/Kconfig| 14 + > drivers/crypto/Makefile |2 + > drivers/crypto/img-hash.c | 1037 >+ 3 files changed, 1053 >insertions(+) > create mode 100644 drivers/crypto/img-hash.c > >diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig >index 2fb0fdf..c72223e 100644 >--- a/drivers/crypto/Kconfig >+++ b/drivers/crypto/Kconfig >@@ -436,4 +436,18 @@ config CRYPTO_DEV_QCE > hardware. To compile this driver as a module, choose M here. The > module will be called qcrypto. > >+config CRYPTO_DEV_IMGTEC_HASH >+ depends on MIPS || COMPILE_TEST >+ tristate "Imagination Technologies hardware hash accelerator" >+ select CRYPTO_ALG_API >+ select CRYPTO_MD5 >+ select CRYPTO_SHA1 >+ select CRYPTO_SHA224 >+ select CRYPTO_SHA256 >+ select CRYPTO_HASH >+ help >+This driver interfaces with the Imagination Technologies >+hardware hash accelerator. Supporting MD5/SHA1/SHA224/SHA256 >+hashing algorithms. >+ > endif # CRYPTO_HW >diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile >index 3924f93..fb84be7 100644 >--- a/drivers/crypto/Makefile >+++ b/drivers/crypto/Makefile >@@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/ > obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam/ > obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o > 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_MXS_DCP) += mxs-dcp.o >@@ -25,3 +26,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o > obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ > obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/ > obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/ >+obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/ >diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c >new file mode 100644 >index 000..94a3a6f >--- /dev/null >+++ b/drivers/crypto/img-hash.c >@@ -0,0 +1,1037 @@ >+/* >+ * Copyright (c) 2014 Imagination Technologies >+ * Authors: Will Thomas, James Hartley >+ * >+ * 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. >+ * >+ *Interface structure taken from omap-sham driver >+ */ >+ >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+ >+#include >+#include >+#include >+ >+#define CR_RESET 0 >+#define CR_RESET_SET 1 >+#define CR_RESET_UNSET0 >+ >+#define CR_MESSAGE_LENGTH_H 0x4 >+#define CR_MESSAGE_LENGTH_L 0x8 >+ >+#define CR_CONTROL0xc >+#define CR_CONTROL_BYTE_ORDER_32100 >+#define CR_CONTROL_BYTE_ORDER_01231 >+#define CR_CONTROL_BYTE_ORDER_23102 >+#define CR_CONTROL_BYTE_ORDER_10323 >+#define CR_CONTROL_BYTE_ORDER_SHIFT 8 >+#define CR_CONTROL_ALGO_MD5 0 >+#define CR_CONTROL_ALGO_SHA1 1 >+#define CR_CONTROL_ALGO_SHA2242 >+#define CR_CONTROL_ALGO_SHA2563 >+ >+#define CR_INTSTAT0x10 >+#define CR_INTENAB0x14 >+#define CR_INTCLEAR 0x18 >+#define CR_INT_RESULTS_AVAILABLE BIT(0) >+#define CR_INT_NEW_RESULTS_SETBIT(1) >+#define CR_INT_RESULT_READ_ERRBIT(2) >+#define CR_INT_MESSAGE_WRITE_ERRORBIT(3) >+#define CR_INT_STATUS BIT(8) >+ >+#define CR_RESULT_QUEUE 0x1c >+#define CR_RSD0 0x40 >+#define CR_CORE_REV 0x50 >+#define CR_CORE_DES1 0x60 >+#define CR_CORE_DES2 0x70 >+ >+#define DRIVER_FLAGS_BUSY BIT(0) >+#define DRIVER_FLAGS_FINALBIT(1) >+#define DRIVER_FLAGS_DMA_ACTIVE BIT(2) >+#define DRIVER_FLAGS_OUTPUT_READY BIT(3) >+#define DRIVER_FLAGS_INIT BIT(4) >+#define DRIVER_FLAGS_CPU BIT(5) >+#define DRIVER_FLAGS_DMA_READYBIT(6) >+#define DRIVER_FLAGS_ERRORBIT(7) >+#define DRIVER_FLAGS_SG BIT(8) >+#define DRIVER_FLAGS_SHA1 BIT(18) >+#define DRIVER_FLAGS_SHA224 BIT(19) >+#define DRIVER_FLAGS_SHA256 BIT(20) >+#define DRIVER_FLAGS_MD5 BIT(21) >+ >+#define IMG_HASH_QUEUE_LENGTH 20 >+#define IMG_HASH_DMA_THRESHOLD64 >+ >+#ifdef __LITTLE_ENDIAN >+#define IMG_HASH_BYTE_ORDER (CR_CONTROL_BYTE_ORDER_3210) >+#else >+#define IMG_HASH_BYTE_ORDER (CR_CONTROL_BYTE_ORDER_0123) >+#endif >+ >+struct img_hash_dev; >+
