From: Eric Biggers <ebiggers@kernel.org>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
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>,
linuxppc-dev@lists.ozlabs.org,
Nicholas Piggin <npiggin@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Madhavan Srinivasan <maddy@linux.ibm.com>
Subject: Re: [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
Date: Mon, 4 May 2026 11:00:44 -0700 [thread overview]
Message-ID: <20260504180044.GC2291@sol> (raw)
In-Reply-To: <111ea924-fef5-441e-9849-83f938c913a7@kernel.org>
On Mon, May 04, 2026 at 03:28:24PM +0200, Christophe Leroy (CS GROUP) wrote:
> Hi Eric,
>
> Le 04/05/2026 à 06:14, Eric Biggers a écrit :
> > Earlier the decision was made to keep this code for a while, despite no
> > other architectures having optimized MD5 code anymore, because of
> > someone using it via AF_ALG via libkcapi-hasher
> > (https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/)
> >
> > However, with AF_ALG itself now being on its way out due to its
> > continuous stream of security vulnerabilities
> > (https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/),
> > it's time to be a bit more forceful with nudging people towards
> > userspace crypto code. It's always been the better solution anyway, and
> > it's much more efficient if properly optimized code is used.
>
> Ok, why not, but what do you propose as an alternative ? Let me explain the
> situation.
>
> We have two versions of boards:
> - One with powerpc MPC885E, which embeds a SECURITY Engine called TALITOS
> for offloading crypto operations
> - One with powerpc MPC866, which doesn't have the security engine.
>
> To use the security engine, our software use the AF_ALG interface (via
> libkcapi).
>
> Our software has to run on both boards, we can't afford two different
> versions of the software and the software shall have no dead code. Therefore
> we rely on the capability of the kernel to do the hash by itself when the
> TALITOS in not available.
>
> The kernel has always been the place where we do board specific stuff, not
> the application. I can't see why the application would have to ask the
> kernel when the Talitos is there and have to do the hashing by itself when
> the Talitos is not there.
>
> I'm really concerned with the optimised MD5 going away now, and I'm also
> wondering what will be the way to splice a file into the kernel and get it's
> MD-5 hash from the TALITOS if AF_ALG goes away in medium-term.
>
> What is the way forward ? I'm open to any suggestion as I really can't see
> where to go for now.
>
> But please don't remove powerpc MD5 before we find an alternative solution.
>
> Thanks
> Christophe
I think I gave the solution in the commit message already, no? Take the
same MD5 code and run it in userspace. It will be even faster than
invoking that code via AF_ALG.
Yes, the selection of software vs "security" engine (if you actually
still need the latter, which in reality you probably don't) would then
occur in userspace. But selecting an implementation in userspace isn't
unusual. It's no different from how different CPU features are handled
in userspace.
Anyway, please don't confuse this patch (which only affects performance)
with full removal of AF_ALG (which would be a hard break, and won't
occur until quite far in the future). This patch is just a nudge in the
right direction, and a cleanup of the kernel's powerpc support to be
aligned with all the other architectures. So I do believe we should
proceed with this patch.
- Eric
prev parent reply other threads:[~2026-05-04 18:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 4:14 [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code Eric Biggers
2026-05-04 11:43 ` Ard Biesheuvel
2026-05-04 13:28 ` Christophe Leroy (CS GROUP)
2026-05-04 13:56 ` Ard Biesheuvel
2026-05-04 18:00 ` 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=20260504180044.GC2291@sol \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=chleroy@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
/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