public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ard Biesheuvel <ardb@kernel.org>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	sparclinux@vger.kernel.org
Subject: Re: [PATCH] lib/crypto: sparc: Drop optimized MD5 code
Date: Fri, 27 Mar 2026 13:14:56 -0700	[thread overview]
Message-ID: <20260327201456.GB25969@quark> (raw)
In-Reply-To: <20260326230232.GA67831@quark>

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

      reply	other threads:[~2026-03-27 20:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 20:33 [PATCH] lib/crypto: sparc: Drop optimized MD5 code Eric Biggers
2026-03-26 21:51 ` John Paul Adrian Glaubitz
2026-03-26 23:02   ` Eric Biggers
2026-03-27 20:14     ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260327201456.GB25969@quark \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox