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

[Eric Biggers <ebiggers@kernel.org>]

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