On Mon, Aug 04, 2025 at 01:44:21PM +0900, Simon Richter wrote:

Hi,

On 8/4/25 05:44, Eric Biggers wrote:

quoted

Taken together, it's clear that it's time to retire these additional MD5
implementations, and focus maintenance on the MD5 generic C code.

[...]

quoted

-	ldd	[%o1 + 0x00], %f8
-	ldd	[%o1 + 0x08], %f10
-	ldd	[%o1 + 0x10], %f12
-	ldd	[%o1 + 0x18], %f14
-	ldd	[%o1 + 0x20], %f16
-	ldd	[%o1 + 0x28], %f18
-	ldd	[%o1 + 0x30], %f20
-	ldd	[%o1 + 0x38], %f22
-
-	MD5

This is a literal CPU instruction that ingests sixteen registers (f8 to f23)
and updates the hash state in f0 to f3.

Note that QEMU doesn't support this instruction.  I don't actually know
whether the SPARC64 MD5 code even works, especially after (presumably
untested) refactoring like commit cc1f5bbe428c91.  I don't think anyone
does, TBH.  No one seems to be running the crypto tests on SPARC64.

I can see the point of removing hand-optimized assembler code when a
compiler can generate something that runs just as well from generic code,
but this here is using CPU extensions that were made for this specific
purpose.

You do realize this is MD5, right?  And also SPARC64?

I'm confused why people are so attached to still having MD5 assembly
code in 2025, and *only for rare platforms*.  It's illogical.

We should just treat MD5 like the other legacy algorithms MD4 and RC4,
for which the kernel just has generic C code.  That works perfectly fine
for the few users that still need those algorithms for compatibility
reasons.

This is exactly the kind of thing you would point to as an argument why
asynchronous hardware offload support is unnecessary.

For an algorithm that is actually worthwhile to accelerate, sure.  For
MD5, it's not worthwhile anyway.

- Eric