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

[Eric Biggers]

On Thu, Mar 26, 2026 at 04:02:32PM -0700, Eric Biggers wrote:
> On Thu, Mar 26, 2026 at 10:51:01PM +0100, John Paul Adrian Glaubitz wrote:
> > On Thu, 2026-03-26 at 13:33 -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.
> > 
> > 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.
> 
> > 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.

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