crypto: lib - create utils module

PATCH In review Eric Biggers 4 participants 16 messages Jul 25, 2022 – Aug 26, 2022

Subsystems (3)

Library code Crypto API Crypto library

lore

Share & tools

lore

Eric Biggers

author maintainer

2022-07-25 18:36 UTC #0 lore raw

v3 cover crypto: lib - create utils module

Create a utils module in lib/crypto/, and move __crypto_memneq, __crypto_xor, and crypto_simd_disabled_for_test into it.

This supersedes "crypto: xor - move __crypto_xor into lib/"
(https://lore.kernel.org/linux-crypto/[email protected]/T/#u).

Changed v2 => v3:
- Added missing MODULE_LICENSE
- Dropped patch "crypto: lib - move crypto_simd_disabled_for_test into utils"
- Added patch "crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ"

Eric Biggers (3):
crypto: lib - create utils module and move __crypto_memneq into it
crypto: lib - move __crypto_xor into utils
crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ

 crypto/Kconfig            |  2 +-
 crypto/algapi.c           | 71 -------------------------------
 lib/Kconfig               |  3 --
 lib/Makefile              |  1 -
 lib/crypto/Kconfig        |  8 ++--
 lib/crypto/Makefile       |  3 ++
 lib/{ => crypto}/memneq.c |  7 +---
 lib/crypto/utils.c        | 88 +++++++++++++++++++++++++++++++++++++++
 8 files changed, 99 insertions(+), 84 deletions(-)
 rename lib/{ => crypto}/memneq.c (98%)
 create mode 100644 lib/crypto/utils.c

base-commit: 9d2bb9a74b2877f100637d6ab5685bcd33c69d44

Signature · 1 line

2.37.0

Eric Biggers

author maintainer

2022-07-25 18:36 UTC #1 lore raw

PATCH v3 1/3 crypto: lib - create utils module and move __crypto_memneq into it

From: Eric Biggers <[email protected]>

As requested at
https://lore.kernel.org/r/[email protected], move __crypto_memneq into lib/crypto/ and put it under a new tristate. The tristate is CRYPTO_LIB_UTILS, and it builds a module libcryptoutils. As more crypto library utilities are being added, this creates a single place for them to go without cluttering up the main lib directory.

The module's main file will be lib/crypto/utils.c. However, leave memneq.c as its own file because of its nonstandard license.

Signed-off-by Eric Biggers <[email protected]>

---
 crypto/Kconfig            | 2 +-
 lib/Kconfig               | 3 ---
 lib/Makefile              | 1 -
 lib/crypto/Kconfig        | 5 ++++-
 lib/crypto/Makefile       | 3 +++
 lib/{ => crypto}/memneq.c | 5 ++++-
 6 files changed, 12 insertions(+), 7 deletions(-)
 rename lib/{ => crypto}/memneq.c (99%)

crypto/Kconfig +1 -1

index e72bf3fc298cc5..7a10441998209d 100644
@@ -15,7 +15,7 @@ source "crypto/async_tx/Kconfig"
 #
 menuconfig CRYPTO
 	tristate "Cryptographic API"
-	select LIB_MEMNEQ
+	select CRYPTO_LIB_UTILS
 	help
 	  This option provides the core Cryptographic API.

lib/Kconfig +0 -3

index eaaad4d85bf24b..6a843639814fbf 100644
@@ -120,9 +120,6 @@ config INDIRECT_IOMEM_FALLBACK
 
 source "lib/crypto/Kconfig"
 
-config LIB_MEMNEQ
-	bool
-
 config CRC_CCITT
 	tristate "CRC-CCITT functions"
 	help

lib/Makefile +0 -1

index 67482f5ec0e899..0557be76c2565f 100644
@@ -251,7 +251,6 @@ obj-$(CONFIG_DIMLIB) += dim/
 obj-$(CONFIG_SIGNATURE) += digsig.o
 
 lib-$(CONFIG_CLZ_TAB) += clz_tab.o
-lib-$(CONFIG_LIB_MEMNEQ) += memneq.o
 
 obj-$(CONFIG_GENERIC_STRNCPY_FROM_USER) += strncpy_from_user.o
 obj-$(CONFIG_GENERIC_STRNLEN_USER) += strnlen_user.o

lib/crypto/Kconfig +4 -1

index 9ff549f63540fa..b09d9d6546cbc3 100644
@@ -2,6 +2,9 @@
 
 menu "Crypto library routines"
 
+config CRYPTO_LIB_UTILS
+	tristate
+
 config CRYPTO_LIB_AES
 	tristate

@@ -71,7 +74,7 @@ config CRYPTO_LIB_CURVE25519
 	tristate "Curve25519 scalar multiplication library"
 	depends on CRYPTO_ARCH_HAVE_LIB_CURVE25519 || !CRYPTO_ARCH_HAVE_LIB_CURVE25519
 	select CRYPTO_LIB_CURVE25519_GENERIC if CRYPTO_ARCH_HAVE_LIB_CURVE25519=n
-	select LIB_MEMNEQ
+	select CRYPTO_LIB_UTILS
 	help
 	  Enable the Curve25519 library interface. This interface may be
 	  fulfilled by either the generic implementation or an arch-specific

lib/crypto/Makefile +3 -0

index 919cbb2c220d61..b956b3bae26aaf 100644
@@ -1,5 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 
+obj-$(CONFIG_CRYPTO_LIB_UTILS)			+= libcryptoutils.o
+libcryptoutils-y				:= memneq.o
+
 # chacha is used by the /dev/random driver which is always builtin
 obj-y						+= chacha.o
 obj-$(CONFIG_CRYPTO_LIB_CHACHA_GENERIC)		+= libchacha.o

lib/crypto/memneq.c renamed from lib/memneq.c +4 -1

similarity index 99%
rename from lib/memneq.c
rename to lib/crypto/memneq.c
index fb11608b1ec1dd..f2098318428478 100644
@@ -59,8 +59,9 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include <crypto/algapi.h>
 #include <asm/unaligned.h>
+#include <crypto/algapi.h>
+#include <linux/module.h>
 
 #ifndef __HAVE_ARCH_CRYPTO_MEMNEQ

@@ -174,3 +175,5 @@ noinline unsigned long __crypto_memneq(const void *a, const void *b,
 EXPORT_SYMBOL(__crypto_memneq);
 
 #endif /* __HAVE_ARCH_CRYPTO_MEMNEQ */
+
+MODULE_LICENSE("GPL");

Signature · 1 line

2.37.0

Jason A. Donenfeld

maintainer Reviewed-by on v3 1/3

2022-07-25 22:11 UTC #2 lore raw

Re: [PATCH v3 1/3] crypto: lib - create utils module and move __crypto_memneq into it

Quoted 11 lines · Eric Biggers

From: Eric Biggers <[email protected]>
As requested at
https://lore.kernel.org/r/[email protected], move __crypto_memneq into lib/crypto/ and put it under a new tristate. The tristate is CRYPTO_LIB_UTILS, and it builds a module libcryptoutils. As more crypto library utilities are being added, this creates a single place for them to go without cluttering up the main lib directory.
The module's main file will be lib/crypto/utils.c. However, leave memneq.c as its own file because of its nonstandard license.

Reviewed-by Jason A. Donenfeld <[email protected]>

Eric Biggers

author maintainer

2022-07-25 18:36 UTC #3 lore raw

PATCH v3 2/3 crypto: lib - move __crypto_xor into utils

In reply to Eric Biggers

From: Eric Biggers <[email protected]>

CRYPTO_LIB_CHACHA depends on CRYPTO for __crypto_xor, defined in crypto/algapi.c. This is a layering violation because the dependencies should only go in the other direction (crypto/ => lib/crypto/). Also the correct dependency would be CRYPTO_ALGAPI, not CRYPTO. Fix this by moving __crypto_xor into the utils module in lib/crypto/.

Note that CRYPTO_LIB_CHACHA_GENERIC selected XOR_BLOCKS, which is unrelated and unnecessary. It was perhaps thought that XOR_BLOCKS was needed for __crypto_xor, but that's not the case.

Signed-off-by Eric Biggers <[email protected]>

---
 crypto/algapi.c     | 71 ------------------------------------
 lib/crypto/Kconfig  |  3 +-
 lib/crypto/Makefile |  2 +-
 lib/crypto/memneq.c |  2 --
 lib/crypto/utils.c  | 88 +++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 90 insertions(+), 76 deletions(-)
 create mode 100644 lib/crypto/utils.c

crypto/algapi.c +0 ~~-71~~

index d1c99288af3e0d..5c69ff8e8fa5c1 100644
@@ -997,77 +997,6 @@ void crypto_inc(u8 *a, unsigned int size)
 }
 EXPORT_SYMBOL_GPL(crypto_inc);
 
-void __crypto_xor(u8 *dst, const u8 *src1, const u8 *src2, unsigned int len)
-{
-	int relalign = 0;
-
-	if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)) {
-		int size = sizeof(unsigned long);
-		int d = (((unsigned long)dst ^ (unsigned long)src1) |
-			 ((unsigned long)dst ^ (unsigned long)src2)) &
-			(size - 1);
-
-		relalign = d ? 1 << __ffs(d) : size;
-
-		/*
-		 * If we care about alignment, process as many bytes as
-		 * needed to advance dst and src to values whose alignments
-		 * equal their relative alignment. This will allow us to
-		 * process the remainder of the input using optimal strides.
-		 */
-		while (((unsigned long)dst & (relalign - 1)) && len > 0) {
-			*dst++ = *src1++ ^ *src2++;
-			len--;
-		}
-	}
-
-	while (IS_ENABLED(CONFIG_64BIT) && len >= 8 && !(relalign & 7)) {
-		if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)) {
-			u64 l = get_unaligned((u64 *)src1) ^
-				get_unaligned((u64 *)src2);
-			put_unaligned(l, (u64 *)dst);
-		} else {
-			*(u64 *)dst = *(u64 *)src1 ^ *(u64 *)src2;
-		}
-		dst += 8;
-		src1 += 8;
-		src2 += 8;
-		len -= 8;
-	}
-
-	while (len >= 4 && !(relalign & 3)) {
-		if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)) {
-			u32 l = get_unaligned((u32 *)src1) ^
-				get_unaligned((u32 *)src2);
-			put_unaligned(l, (u32 *)dst);
-		} else {
-			*(u32 *)dst = *(u32 *)src1 ^ *(u32 *)src2;
-		}
-		dst += 4;
-		src1 += 4;
-		src2 += 4;
-		len -= 4;
-	}
-
-	while (len >= 2 && !(relalign & 1)) {
-		if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)) {
-			u16 l = get_unaligned((u16 *)src1) ^
-				get_unaligned((u16 *)src2);
-			put_unaligned(l, (u16 *)dst);
-		} else {
-			*(u16 *)dst = *(u16 *)src1 ^ *(u16 *)src2;
-		}
-		dst += 2;
-		src1 += 2;
-		src2 += 2;
-		len -= 2;
-	}
-
-	while (len--)
-		*dst++ = *src1++ ^ *src2++;
-}
-EXPORT_SYMBOL_GPL(__crypto_xor);
-
 unsigned int crypto_alg_extsize(struct crypto_alg *alg)
 {
 	return alg->cra_ctxsize +

lib/crypto/Kconfig +1 -2

index b09d9d6546cbc3..7e9683e9f5c636 100644
@@ -36,7 +36,7 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA
 
 config CRYPTO_LIB_CHACHA_GENERIC
 	tristate
-	select XOR_BLOCKS
+	select CRYPTO_LIB_UTILS
 	help
 	  This symbol can be depended upon by arch implementations of the
 	  ChaCha library interface that require the generic code as a

@@ -46,7 +46,6 @@ config CRYPTO_LIB_CHACHA_GENERIC
 
 config CRYPTO_LIB_CHACHA
 	tristate "ChaCha library interface"
-	depends on CRYPTO
 	depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA
 	select CRYPTO_LIB_CHACHA_GENERIC if CRYPTO_ARCH_HAVE_LIB_CHACHA=n
 	help

lib/crypto/Makefile +1 -1

index b956b3bae26aaf..c852f067ab0601 100644
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_CRYPTO_LIB_UTILS)			+= libcryptoutils.o
-libcryptoutils-y				:= memneq.o
+libcryptoutils-y				:= memneq.o utils.o
 
 # chacha is used by the /dev/random driver which is always builtin
 obj-y						+= chacha.o

lib/crypto/memneq.c +0 -2

index f2098318428478..d1e8c86fbb0fcf 100644
@@ -175,5 +175,3 @@ noinline unsigned long __crypto_memneq(const void *a, const void *b,
 EXPORT_SYMBOL(__crypto_memneq);
 
 #endif /* __HAVE_ARCH_CRYPTO_MEMNEQ */
-
-MODULE_LICENSE("GPL");

lib/crypto/utils.c new file +88 -0

88 lines not on this page · raw message

Signature · 1 line

2.37.0

Jason A. Donenfeld

maintainer Reviewed-by on v3 2/3

2022-07-25 22:09 UTC #4 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

Quoted 8 lines · Eric Biggers

From: Eric Biggers <[email protected]>
CRYPTO_LIB_CHACHA depends on CRYPTO for __crypto_xor, defined in crypto/algapi.c. This is a layering violation because the dependencies should only go in the other direction (crypto/ => lib/crypto/). Also the correct dependency would be CRYPTO_ALGAPI, not CRYPTO. Fix this by moving __crypto_xor into the utils module in lib/crypto/.

Quoted 5 lines

Note that CRYPTO_LIB_CHACHA_GENERIC selected XOR_BLOCKS, which is unrelated and unnecessary. It was perhaps thought that XOR_BLOCKS was needed for __crypto_xor, but that's not the case.
Signed-off-by Eric Biggers <[email protected]>

Reviewed-by Jason A. Donenfeld <[email protected]>

With one small question:

lib/crypto/utils.c line 5

Quoted 8 lines

lib/crypto/utils.c new file +5 -0

@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Crypto library utility functions
+ *
+ * Copyright (c) 2006 Herbert Xu <[email protected]>

Didn't Ard basically write the crypto_xor function in its current form? I seem to remember some pretty hardcore refactoring he did a while back.

Jason

Eric Biggers

author maintainer

2022-07-26 01:00 UTC #5 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

Quoted 31 lines · Jason A. Donenfeld

Quoted 8 lines · Eric Biggers
From: Eric Biggers <[email protected]>
CRYPTO_LIB_CHACHA depends on CRYPTO for __crypto_xor, defined in crypto/algapi.c. This is a layering violation because the dependencies should only go in the other direction (crypto/ => lib/crypto/). Also the correct dependency would be CRYPTO_ALGAPI, not CRYPTO. Fix this by moving __crypto_xor into the utils module in lib/crypto/.
Quoted 5 lines
Note that CRYPTO_LIB_CHACHA_GENERIC selected XOR_BLOCKS, which is unrelated and unnecessary. It was perhaps thought that XOR_BLOCKS was needed for __crypto_xor, but that's not the case.
Signed-off-by Eric Biggers <[email protected]>
Reviewed-by Jason A. Donenfeld <[email protected]>
With one small question:
lib/crypto/utils.c line 5
Quoted 8 lines
lib/crypto/utils.c new file +5 -0
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Crypto library utility functions
+ *
+ * Copyright (c) 2006 Herbert Xu <[email protected]>
Didn't Ard basically write the crypto_xor function in its current form? I seem to remember some pretty hardcore refactoring he did a while back.

Quoted 1 line

Jason

I think that's fair to say, based on git blame. I just copied the copyright statement from the top of crypto/algapi.c.

- Eric

Ard Biesheuvel

maintainer

2022-07-26 13:45 UTC #6 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

In reply to Jason A. Donenfeld

Quoted 20 lines · Jason A. Donenfeld

Quoted 8 lines · Eric Biggers
From: Eric Biggers <[email protected]>
CRYPTO_LIB_CHACHA depends on CRYPTO for __crypto_xor, defined in crypto/algapi.c. This is a layering violation because the dependencies should only go in the other direction (crypto/ => lib/crypto/). Also the correct dependency would be CRYPTO_ALGAPI, not CRYPTO. Fix this by moving __crypto_xor into the utils module in lib/crypto/.
Quoted 5 lines
Note that CRYPTO_LIB_CHACHA_GENERIC selected XOR_BLOCKS, which is unrelated and unnecessary. It was perhaps thought that XOR_BLOCKS was needed for __crypto_xor, but that's not the case.
Signed-off-by Eric Biggers <[email protected]>
Reviewed-by Jason A. Donenfeld <[email protected]>
With one small question:

Quoted 12 lines

lib/crypto/utils.c line 5
Quoted 8 lines
lib/crypto/utils.c new file +5 -0
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Crypto library utility functions
+ *
+ * Copyright (c) 2006 Herbert Xu <[email protected]>
Didn't Ard basically write the crypto_xor function in its current form? I seem to remember some pretty hardcore refactoring he did a while back.

Hi Jason,

Thanks for pointing this out. When I made those changes, I don't think an authorship assertion for copyright purposes was appropriate for the entire .c file (the FSF have some guidelines for this IIRC). It would also be strange for me or Eric to suddenly introduce a (c) Linaro (or ARM, not sure who my employer was at the time) at this point, so I think we can just leave this as proposed by Eric.

Eric Biggers

author maintainer

2022-08-26 04:44 UTC #7 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

In reply to Eric Biggers

Herbert, Jason, and Justin:

lib/crypto/Kconfig config CRYPTO_ARCH_HAVE_LIB_CHACHA · line 42

Quoted 13 lines · Eric Biggers

lib/crypto/Kconfig +1 -1

index b09d9d6546cbc3..7e9683e9f5c636 100644
@@ -36,7 +36,7 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA
 
 config CRYPTO_LIB_CHACHA_GENERIC
 	tristate
-	select XOR_BLOCKS
+	select CRYPTO_LIB_UTILS
 	help
 	  This symbol can be depended upon by arch implementations of the
 	  ChaCha library interface that require the generic code as a

Just a heads up; the unnecessary selection of XOR_BLOCKS here (which got backported to v5.10.120 and v5.15.45 by "lib/crypto: add prompts back to crypto libraries") can be considered an actual bug, as it increases boot time on systems that didn't have it selected before. This is because the code enabled by XOR_BLOCKS (crypto/xor.c) runs a benchmark, which takes some time. It doesn't take *that* long, but it got noticed as a regression nonetheless, and it needs to be fixed. My patch series happens to have fixed this, but I didn't have it mind that it was a real bug fix.

Herbert, any chance that you could send my patch series to Linus without waiting for the next merge window, so that it can be backported?

- Eric

Herbert Xu

maintainer

2022-08-26 04:46 UTC #8 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

On Thu, Aug 25, 2022 at 09:44:38PM -0700, Eric Biggers wrote:
.

Quoted 2 lines

Herbert, any chance that you could send my patch series to Linus without waiting for the next merge window, so that it can be backported?

Sure, which patch fixes this?

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Eric Biggers

author maintainer

2022-08-26 04:48 UTC #9 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

Quoted 7 lines · Herbert Xu

On Thu, Aug 25, 2022 at 09:44:38PM -0700, Eric Biggers wrote:
.
Quoted 2 lines
Herbert, any chance that you could send my patch series to Linus without waiting for the next merge window, so that it can be backported?
Sure, which patch fixes this?

The one I'm commenting on (patch 2 of 3). But patch 1 is needed as a prerequisite.

- Eric

Herbert Xu

maintainer

2022-08-26 04:53 UTC #10 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

Quoted 3 lines · Eric Biggers

The one I'm commenting on (patch 2 of 3). But patch 1 is needed as a prerequisite.

Oh so it's just dropping the select? Can you please send me a separate patch for the crypto tree with a Fixes header? I'll deal with the merge conflict.

Thanks,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Eric Biggers

author maintainer

2022-08-26 05:07 UTC #11 lore raw

Re: [PATCH v3 2/3] crypto: lib - move __crypto_xor into utils

Quoted 9 lines · Herbert Xu

Quoted 3 lines · Eric Biggers
The one I'm commenting on (patch 2 of 3). But patch 1 is needed as a prerequisite.
Oh so it's just dropping the select? Can you please send me a separate patch for the crypto tree with a Fixes header? I'll deal with the merge conflict.

Done: https://lore.kernel.org/r/[email protected]

- Eric

Eric Biggers

author maintainer

2022-07-25 18:36 UTC #12 lore raw

PATCH v3 3/3 crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ

In reply to Eric Biggers

From: Eric Biggers <[email protected]>

No architecture actually defines this, so it's unneeded.

Signed-off-by Eric Biggers <[email protected]>

---
 lib/crypto/memneq.c | 4 ----
 1 file changed, 4 deletions(-)

lib/crypto/memneq.c +0 -4

index d1e8c86fbb0fcf..243d8677cc515d 100644
@@ -63,8 +63,6 @@
 #include <crypto/algapi.h>
 #include <linux/module.h>
 
-#ifndef __HAVE_ARCH_CRYPTO_MEMNEQ
-
 /* Generic path for arbitrary size */
 static inline unsigned long
 __crypto_memneq_generic(const void *a, const void *b, size_t size)

@@ -173,5 +171,3 @@ noinline unsigned long __crypto_memneq(const void *a, const void *b,
 	}
 }
 EXPORT_SYMBOL(__crypto_memneq);
-
-#endif /* __HAVE_ARCH_CRYPTO_MEMNEQ */

Signature · 1 line

2.37.0

Jason A. Donenfeld

maintainer Reviewed-by on v3 3/3

2022-07-25 22:07 UTC #13 lore raw

Re: [PATCH v3 3/3] crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ

Quoted 5 lines · Eric Biggers

From: Eric Biggers <[email protected]>
No architecture actually defines this, so it's unneeded.
Signed-off-by Eric Biggers <[email protected]>

Reviewed-by Jason A. Donenfeld <[email protected]>

Aside: out of curiosity, I wonder what was originally intended with this, which magic arch-specific instructions were thought to be potentially of aid.

Eric Biggers

author maintainer

2022-07-26 00:51 UTC #14 lore raw

Re: [PATCH v3 3/3] crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ

Quoted 5 lines · Jason A. Donenfeld

Quoted 4 lines · Eric Biggers
From: Eric Biggers <[email protected]>
No architecture actually defines this, so it's unneeded.

Quoted 7 lines

Quoted 1 line
Signed-off-by Eric Biggers <[email protected]>
Reviewed-by Jason A. Donenfeld <[email protected]>
Aside: out of curiosity, I wonder what was originally intended with this, which magic arch-specific instructions were thought to be potentially of aid.

The original commit (6bf37e5aa90f) says:

Similarly to kernel library string functions, leave an option for future even further optimized architecture specific assembler implementations.

But so far no one has bothered. It's already optimized to use 'long' accesses, so I wouldn't expect it to get much faster with assembly.

- Eric

Herbert Xu

maintainer

2022-08-19 10:59 UTC #15 lore raw

In reply to Eric Biggers

Quoted 26 lines · Eric Biggers

Create a utils module in lib/crypto/, and move __crypto_memneq, __crypto_xor, and crypto_simd_disabled_for_test into it.
This supersedes "crypto: xor - move __crypto_xor into lib/"
(https://lore.kernel.org/linux-crypto/[email protected]/T/#u).
Changed v2 => v3:
- Added missing MODULE_LICENSE
- Dropped patch "crypto: lib - move crypto_simd_disabled_for_test into utils"
- Added patch "crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ"
Eric Biggers (3):
crypto: lib - create utils module and move __crypto_memneq into it
crypto: lib - move __crypto_xor into utils
crypto: lib - remove __HAVE_ARCH_CRYPTO_MEMNEQ
crypto/Kconfig            |  2 +-
crypto/algapi.c           | 71 -------------------------------
lib/Kconfig               |  3 --
lib/Makefile              |  1 -
lib/crypto/Kconfig        |  8 ++--
lib/crypto/Makefile       |  3 ++
lib/{ => crypto}/memneq.c |  7 +---
lib/crypto/utils.c        | 88 +++++++++++++++++++++++++++++++++++++++
8 files changed, 99 insertions(+), 84 deletions(-)

Quoted 5 lines

rename lib/{ => crypto}/memneq.c (98%)
create mode 100644 lib/crypto/utils.c
base-commit: 9d2bb9a74b2877f100637d6ab5685bcd33c69d44

All applied. Thanks.

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt