lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250531180843.GA5482@quark>
Date: Sat, 31 May 2025 11:08:43 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	ardb@...nel.org
Subject: Re: [PATCH] crypto/crc32: register only one shash_alg

On Sat, May 31, 2025 at 03:09:37PM +0800, Herbert Xu wrote:
> Eric Biggers <ebiggers@...nel.org> wrote:
> > From: Eric Biggers <ebiggers@...gle.com>
> > 
> > Stop unnecessarily registering a "crc32-generic" shash_alg when a
> > "crc32-$(ARCH)" shash_alg is registered too.
> > 
> > While every algorithm does need to have a generic implementation to
> > ensure uniformity of support across platforms, that doesn't mean that we
> > need to make the generic implementation available through crypto_shash
> > when an optimized implementation is also available.
> > 
> > Registering the generic shash_alg did allow users of the crypto_shash or
> > crypto_ahash APIs to request the generic implementation specifically,
> > instead of an optimized one.  However, the only known use case for that
> > was the differential fuzz tests in crypto/testmgr.c.  Equivalent test
> > coverage is now provided by crc_kunit.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> > ---
> > 
> > I'm planning to take this through the crc tree.
> > 
> > crypto/crc32.c | 69 ++++++++------------------------------------------
> > 1 file changed, 11 insertions(+), 58 deletions(-)
> 
> Please don't do this without first removing all drivers providing
> "crc32" as otherwise their test coverge will be reduced.
> 
> Cheers,

Yes, I'll do that.  It's time to do that anyway.

For other algorithms like sha256 where it's unlikely that all the drivers can be
removed, testmgr.c should just compare against the library implementation, not
the "generic" implementation specifically.

Ideally we'll just stop pretending that cra_driver_name actually matters, and
just name the software algorithms *-lib or *-software.

- Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ