lib/crypto: sparc: Drop optimized MD5 code
Subsystems (2)
Eric Biggers
maintainerPATCH 1/1 lib/crypto: sparc: Drop optimized MD5 code
MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important.
While there was demand for continuing to maintain the PowerPC optimized MD5 code to accommodate userspace programs that are misusing AF_ALG
(https://lore.kernel.org/linux-crypto/[email protected]/),
no such demand has been seen for the SPARC optimized MD5 code.
Thus, let's drop it and focus effort on the more modern SHA algorithms, which already have optimized code for SPARC.
---
This patch is targeting libcrypto-next
lib/crypto/Kconfig | 1 - lib/crypto/Makefile | 1 - lib/crypto/sparc/md5.h | 48 -------------------------- lib/crypto/sparc/md5_asm.S | 70 -------------------------------------- 4 files changed, 120 deletions(-) delete mode 100644 lib/crypto/sparc/md5.h delete mode 100644 lib/crypto/sparc/md5_asm.S
lib/crypto/Kconfig +0 -1
@@ -134,11 +134,10 @@ config CRYPTO_LIB_MD5 config CRYPTO_LIB_MD5_ARCH bool depends on CRYPTO_LIB_MD5 && !UML default y if MIPS && CPU_CAVIUM_OCTEON default y if PPC - default y if SPARC64 config CRYPTO_LIB_MLDSA tristate select CRYPTO_LIB_SHA3 help
lib/crypto/Makefile +0 -1
@@ -186,11 +186,10 @@ clean-files += powerpc/ghashp8-ppc.S obj-$(CONFIG_CRYPTO_LIB_MD5) += libmd5.o libmd5-y := md5.o ifeq ($(CONFIG_CRYPTO_LIB_MD5_ARCH),y) CFLAGS_md5.o += -I$(src)/$(SRCARCH) libmd5-$(CONFIG_PPC) += powerpc/md5-asm.o -libmd5-$(CONFIG_SPARC) += sparc/md5_asm.o endif # CONFIG_CRYPTO_LIB_MD5_ARCH ################################################################################ obj-$(CONFIG_CRYPTO_LIB_MLDSA) += libmldsa.o
lib/crypto/sparc/md5.h deleted +0 -48
48 lines not on this page · raw message
lib/crypto/sparc/md5_asm.S deleted +0 -70
70 lines not on this page · raw message
base-commit: 7ac21b4032e5b9b8a6a312b6f1d54f4ba24d1c16
Signature · 1 line
2.53.0
Quoted 3 lines · Eric Biggers
MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important.
Why is it risky? That makes no sense. I also don't see how it diverts resources as no one is forced to work on the code.
SPARC is an architecture used by hobbyists and in space these days (in the form of Leon). I don't think any other kernel developer will have to take a look at it.
Adrian
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Eric Biggers
maintainerQuoted 6 lines · John Paul Adrian Glaubitz
Quoted 3 lines · Eric Biggers
MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important.
Why is it risky? That makes no sense.
Because there can be issues in architecture-optimized algorithm implementations that don't exist in the generic implementations. That's a very common class of issue that has repeated over time.
Quoted 6 lines
I also don't see how it diverts resources as no one is forced to work on the code.
SPARC is an architecture used by hobbyists and in space these days (in the form of Leon). I don't think any other kernel developer will have to take a look at it.
Huh? We've been refactoring how the various crypto and CRC algorithms are integrated, for all architectures.
So people outside the SPARC community, especially myself, been having to spend quite a bit of time updating the SPARC code so that it can still be used.
And this isn't new. I've had to patch arch/sparc/crypto/ many times over the years as things change in the crypto subsystem. Many other people, again outside the SPARC community, have as well.
The fact that you're denying that we've had to do this is really frustrating. There is a significant maintenance cost to keeping this code working, which is being paid by people outside the SPARC community.
It seems best to at least focus that effort on modern algorithms like AES and SHA-256, and not obsolete ones like MD5 and DES. Note that dropping those eliminates the need to add them to QEMU, as well.
I think that makes things easier for everyone.
- Eric
Eric Biggers
maintainerQuoted 34 lines · Eric Biggers
Quoted 6 lines · John Paul Adrian Glaubitz
Quoted 3 lines · Eric Biggers
MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important.
Why is it risky? That makes no sense.
Because there can be issues in architecture-optimized algorithm implementations that don't exist in the generic implementations. That's a very common class of issue that has repeated over time.
Quoted 6 lines
I also don't see how it diverts resources as no one is forced to work on the code.
SPARC is an architecture used by hobbyists and in space these days (in the form of Leon). I don't think any other kernel developer will have to take a look at it.
Huh? We've been refactoring how the various crypto and CRC algorithms are integrated, for all architectures.
So people outside the SPARC community, especially myself, been having to spend quite a bit of time updating the SPARC code so that it can still be used.
And this isn't new. I've had to patch
arch/sparc/crypto/many times over the years as things change in the crypto subsystem. Many other people, again outside the SPARC community, have as well.The fact that you're denying that we've had to do this is really frustrating. There is a significant maintenance cost to keeping this code working, which is being paid by people outside the SPARC community.
Quoted 5 lines
It seems best to at least focus that effort on modern algorithms like AES and SHA-256, and not obsolete ones like MD5 and DES. Note that dropping those eliminates the need to add them to QEMU, as well.
I think that makes things easier for everyone.
Let me know if you're aware of a real user that needs the obsolete MD5 algorithm to be accelerated for SPARC in the kernel.
Otherwise, I suggest we proceed with this patch, as this objection seems to based only on principles and misunderstandings.
I think our interests are aligned, actually: we both want Linux to work reliably on SPARC.
- Eric
Quoted 39 lines · Eric Biggers
Quoted 38 lines · Eric Biggers
Quoted 6 lines · John Paul Adrian Glaubitz
Quoted 3 lines · Eric Biggers
MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important.
Why is it risky? That makes no sense.
Because there can be issues in architecture-optimized algorithm implementations that don't exist in the generic implementations. That's a very common class of issue that has repeated over time.
Quoted 6 lines
I also don't see how it diverts resources as no one is forced to work on the code.
SPARC is an architecture used by hobbyists and in space these days (in the form of Leon). I don't think any other kernel developer will have to take a look at it.
Huh? We've been refactoring how the various crypto and CRC algorithms are integrated, for all architectures.
So people outside the SPARC community, especially myself, been having to spend quite a bit of time updating the SPARC code so that it can still be used.
And this isn't new. I've had to patch
arch/sparc/crypto/many times over the years as things change in the crypto subsystem. Many other people, again outside the SPARC community, have as well.The fact that you're denying that we've had to do this is really frustrating. There is a significant maintenance cost to keeping this code working, which is being paid by people outside the SPARC community.
It seems best to at least focus that effort on modern algorithms like AES and SHA-256, and not obsolete ones like MD5 and DES. Note that dropping those eliminates the need to add them to QEMU, as well.
Quoted 8 lines
Quoted 1 line
I think that makes things easier for everyone.
Let me know if you're aware of a real user that needs the obsolete MD5 algorithm to be accelerated for SPARC in the kernel.
Otherwise, I suggest we proceed with this patch, as this objection seems to based only on principles and misunderstandings.
Agreed. I do sympathise with the hobbyists, (and with the astronauts, for that matter), but the mainline kernel is not a museum. If someone has a desire to run obsolete code on an obsolete architecture, they are more than welcome to do so. But demanding that the rest of the world spends time on this is unreasonable, especially given that few people have access to the hardware.
The upshot of that is that the burden falls on the maintainers to chase bot reports and other reported regressions on obsolete architectures, and doing so for code such as MD5 which is entirely obsolete itself is just busywork.
Quoted 9 lines · Eric Biggers
MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important.
While there was demand for continuing to maintain the PowerPC optimized MD5 code to accommodate userspace programs that are misusing
AF_ALG
(https://lore.kernel.org/linux-crypto/[email protected]/),
no such demand has been seen for the SPARC optimized MD5 code.
Quoted 7 lines
Thus, let's drop it and focus effort on the more modern SHA algorithms, which already have optimized code for SPARC.
Signed-off-by Eric Biggers <[email protected]>---
This patch is targeting libcrypto-next
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next
- Eric