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
prev parent 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