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

[Eric Biggers <ebiggers@kernel.org>]

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