[PATCH] lib/crypto: mips: Drop optimized MD5 code

[PATCH] lib/crypto: mips: Drop optimized MD5 code

[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/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),
no such demand has been seen for the MIPS Cavium Octeon optimized MD5
code.  Note that this code runs on only one particular line of SoCs.

Thus, let's drop it and focus effort on the more modern SHA algorithms,
which already have optimized code for the same SoCs.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---

This patch is targeting libcrypto-next

 lib/crypto/Kconfig    |  1 -
 lib/crypto/mips/md5.h | 65 -------------------------------------------
 2 files changed, 66 deletions(-)
 delete mode 100644 lib/crypto/mips/md5.h

diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index 4b6f593dc72f..9f31f03062f0 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -132,11 +132,10 @@ config CRYPTO_LIB_MD5
 	  uses any of the functions from <crypto/md5.h>.
 
 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
diff --git a/lib/crypto/mips/md5.h b/lib/crypto/mips/md5.h
deleted file mode 100644
index e08e28aeffa4..000000000000
--- a/lib/crypto/mips/md5.h
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Cryptographic API.
- *
- * MD5 Message Digest Algorithm (RFC1321).
- *
- * Adapted for OCTEON by Aaro Koskinen <aaro.koskinen@iki.fi>.
- *
- * Based on crypto/md5.c, which is:
- *
- * Derived from cryptoapi implementation, originally based on the
- * public domain implementation written by Colin Plumb in 1993.
- *
- * Copyright (c) Cryptoapi developers.
- * Copyright (c) 2002 James Morris <jmorris@intercode.com.au>
- *
- * 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 <asm/octeon/crypto.h>
-#include <asm/octeon/octeon.h>
-
-/*
- * We pass everything as 64-bit. OCTEON can handle misaligned data.
- */
-
-static void md5_blocks(struct md5_block_state *state,
-		       const u8 *data, size_t nblocks)
-{
-	struct octeon_cop2_state cop2_state;
-	u64 *state64 = (u64 *)state;
-	unsigned long flags;
-
-	if (!octeon_has_crypto())
-		return md5_blocks_generic(state, data, nblocks);
-
-	cpu_to_le32_array(state->h, ARRAY_SIZE(state->h));
-
-	flags = octeon_crypto_enable(&cop2_state);
-	write_octeon_64bit_hash_dword(state64[0], 0);
-	write_octeon_64bit_hash_dword(state64[1], 1);
-
-	do {
-		const u64 *block = (const u64 *)data;
-
-		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_md5_start(block[7]);
-
-		data += MD5_BLOCK_SIZE;
-	} while (--nblocks);
-
-	state64[0] = read_octeon_64bit_hash_dword(0);
-	state64[1] = read_octeon_64bit_hash_dword(1);
-	octeon_crypto_disable(&cop2_state, flags);
-
-	le32_to_cpu_array(state->h, ARRAY_SIZE(state->h));
-}

base-commit: 7ac21b4032e5b9b8a6a312b6f1d54f4ba24d1c16
-- 
2.53.0

Re: [PATCH] lib/crypto: mips: Drop optimized MD5 code

[Ard Biesheuvel]

On Thu, 26 Mar 2026, at 21:48, Eric Biggers wrote:
> 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/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),
> no such demand has been seen for the MIPS Cavium Octeon optimized MD5
> code.  Note that this code runs on only one particular line of SoCs.
>
> Thus, let's drop it and focus effort on the more modern SHA algorithms,
> which already have optimized code for the same SoCs.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is targeting libcrypto-next
>
>  lib/crypto/Kconfig    |  1 -
>  lib/crypto/mips/md5.h | 65 -------------------------------------------
>  2 files changed, 66 deletions(-)
>  delete mode 100644 lib/crypto/mips/md5.h
>

Acked-by: Ard Biesheuvel <ardb@kernel.org>

Re: [PATCH] lib/crypto: mips: Drop optimized MD5 code

[Eric Biggers]

On Thu, Mar 26, 2026 at 01:48:24PM -0700, Eric Biggers wrote:
> 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/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),
> no such demand has been seen for the MIPS Cavium Octeon optimized MD5
> code.  Note that this code runs on only one particular line of SoCs.
> 
> Thus, let's drop it and focus effort on the more modern SHA algorithms,
> which already have optimized code for the same SoCs.
> 
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> 
> 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

Re: [PATCH] lib/crypto: mips: Drop optimized MD5 code

[Aaro Koskinen]

Hi,

On Thu, Mar 26, 2026 at 01:48:24PM -0700, Eric Biggers wrote:
> 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/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),
> no such demand has been seen for the MIPS Cavium Octeon optimized MD5
> code.  Note that this code runs on only one particular line of SoCs.
> 
> Thus, let's drop it and focus effort on the more modern SHA algorithms,
> which already have optimized code for the same SoCs.

I don't mind deleting this (I shut down all my MIPS hardware already
in new year 2020 to start a "fresh" decade), but just for the record,
this will probably downgrade the performance of TCP_MD5SIG which I recall
was the original reason this code got added...

Also that PowerPC case about "misusing AF_ALG" is interesting - I often do
similar on small systems (just to save binary space and avoid duplicate
implementation) - why AF_ALG even allows such use if it's considered
a bug?

A.

> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> 
> This patch is targeting libcrypto-next
> 
>  lib/crypto/Kconfig    |  1 -
>  lib/crypto/mips/md5.h | 65 -------------------------------------------
>  2 files changed, 66 deletions(-)
>  delete mode 100644 lib/crypto/mips/md5.h
> 
> diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
> index 4b6f593dc72f..9f31f03062f0 100644
> --- a/lib/crypto/Kconfig
> +++ b/lib/crypto/Kconfig
> @@ -132,11 +132,10 @@ config CRYPTO_LIB_MD5
>  	  uses any of the functions from <crypto/md5.h>.
>  
>  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
> diff --git a/lib/crypto/mips/md5.h b/lib/crypto/mips/md5.h
> deleted file mode 100644
> index e08e28aeffa4..000000000000
> --- a/lib/crypto/mips/md5.h
> +++ /dev/null
> @@ -1,65 +0,0 @@
> -/*
> - * Cryptographic API.
> - *
> - * MD5 Message Digest Algorithm (RFC1321).
> - *
> - * Adapted for OCTEON by Aaro Koskinen <aaro.koskinen@iki.fi>.
> - *
> - * Based on crypto/md5.c, which is:
> - *
> - * Derived from cryptoapi implementation, originally based on the
> - * public domain implementation written by Colin Plumb in 1993.
> - *
> - * Copyright (c) Cryptoapi developers.
> - * Copyright (c) 2002 James Morris <jmorris@intercode.com.au>
> - *
> - * 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 <asm/octeon/crypto.h>
> -#include <asm/octeon/octeon.h>
> -
> -/*
> - * We pass everything as 64-bit. OCTEON can handle misaligned data.
> - */
> -
> -static void md5_blocks(struct md5_block_state *state,
> -		       const u8 *data, size_t nblocks)
> -{
> -	struct octeon_cop2_state cop2_state;
> -	u64 *state64 = (u64 *)state;
> -	unsigned long flags;
> -
> -	if (!octeon_has_crypto())
> -		return md5_blocks_generic(state, data, nblocks);
> -
> -	cpu_to_le32_array(state->h, ARRAY_SIZE(state->h));
> -
> -	flags = octeon_crypto_enable(&cop2_state);
> -	write_octeon_64bit_hash_dword(state64[0], 0);
> -	write_octeon_64bit_hash_dword(state64[1], 1);
> -
> -	do {
> -		const u64 *block = (const u64 *)data;
> -
> -		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_md5_start(block[7]);
> -
> -		data += MD5_BLOCK_SIZE;
> -	} while (--nblocks);
> -
> -	state64[0] = read_octeon_64bit_hash_dword(0);
> -	state64[1] = read_octeon_64bit_hash_dword(1);
> -	octeon_crypto_disable(&cop2_state, flags);
> -
> -	le32_to_cpu_array(state->h, ARRAY_SIZE(state->h));
> -}
> 
> base-commit: 7ac21b4032e5b9b8a6a312b6f1d54f4ba24d1c16
> -- 
> 2.53.0
> 
> 

Re: [PATCH] lib/crypto: mips: Drop optimized MD5 code

[Eric Biggers]

On Sun, Apr 19, 2026 at 03:36:31AM +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Thu, Mar 26, 2026 at 01:48:24PM -0700, Eric Biggers wrote:
> > 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/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),
> > no such demand has been seen for the MIPS Cavium Octeon optimized MD5
> > code.  Note that this code runs on only one particular line of SoCs.
> > 
> > Thus, let's drop it and focus effort on the more modern SHA algorithms,
> > which already have optimized code for the same SoCs.
> 
> I don't mind deleting this (I shut down all my MIPS hardware already
> in new year 2020 to start a "fresh" decade), but just for the record,
> this will probably downgrade the performance of TCP_MD5SIG which I recall
> was the original reason this code got added...

Sure, for any removal of optimized code it's always possible to
hypothesize a case where it regresses performance.  The question is
whether it actually matters and is worth keeping around.  You mentioned
that you did care about this code, but no longer do.  I think anyone who
may have cared about this in the past is likely to have had a similar
experience.

After all, the only line of SoCs that could run this code switched from
MIPS to ARM in 2016.  Meanwhile, TCP-MD5 itself is insecure and has been
superseded by TCP-AO.  (Note that TCP-AO supports HMAC-SHA1 and
HMAC-SHA256, which are still accelerated on MIPS Cavium Octeon.)

Yes, there are still people using TCP-MD5 anyway (on some platforms, not
necessarily this particular one).  But a nudge towards upgrading to
TCP-AO isn't necessarily a bad thing, either...

> Also that PowerPC case about "misusing AF_ALG" is interesting - I often do
> similar on small systems (just to save binary space and avoid duplicate
> implementation) - why AF_ALG even allows such use if it's considered
> a bug?

It's just a mistake from a long time ago (2010) that still has to be
maintained for backwards compatibility.  It's not something that would
be accepted in the kernel if it was proposed today.

- Eric

Re: [PATCH] lib/crypto: mips: Drop optimized MD5 code

[Eric Biggers]

On Sat, Apr 18, 2026 at 06:08:36PM -0700, Eric Biggers wrote:
> On Sun, Apr 19, 2026 at 03:36:31AM +0300, Aaro Koskinen wrote:
> > Hi,
> > 
> > On Thu, Mar 26, 2026 at 01:48:24PM -0700, Eric Biggers wrote:
> > > 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/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),
> > > no such demand has been seen for the MIPS Cavium Octeon optimized MD5
> > > code.  Note that this code runs on only one particular line of SoCs.
> > > 
> > > Thus, let's drop it and focus effort on the more modern SHA algorithms,
> > > which already have optimized code for the same SoCs.
> > 
> > I don't mind deleting this (I shut down all my MIPS hardware already
> > in new year 2020 to start a "fresh" decade), but just for the record,
> > this will probably downgrade the performance of TCP_MD5SIG which I recall
> > was the original reason this code got added...
> 
> Sure, for any removal of optimized code it's always possible to
> hypothesize a case where it regresses performance.  The question is
> whether it actually matters and is worth keeping around.  You mentioned
> that you did care about this code, but no longer do.  I think anyone who
> may have cared about this in the past is likely to have had a similar
> experience.
> 
> After all, the only line of SoCs that could run this code switched from
> MIPS to ARM in 2016.  Meanwhile, TCP-MD5 itself is insecure and has been
> superseded by TCP-AO.  (Note that TCP-AO supports HMAC-SHA1 and
> HMAC-SHA256, which are still accelerated on MIPS Cavium Octeon.)
> 
> Yes, there are still people using TCP-MD5 anyway (on some platforms, not
> necessarily this particular one).  But a nudge towards upgrading to
> TCP-AO isn't necessarily a bad thing, either...

I should also emphasize, again, that we don't actually know whether this
code even still worked.  It underwent quite a bit refactoring in the
last year or so to keep it theoretically working as the crypto subsystem
evolved.  Yet it has never been testable in QEMU, and there were never
any reports of anyone re-testing it on the hardware.

If there were someone who had said, "Yes, I need this legacy code, it
passes the MD5 KUnit test, and I'll be re-testing it regularly", that
would have been more encouraging.  But otherwise we may have been just
been keeping broken code around, which is much worse than simply using
the well-tested generic code.

- Eric