linux-kernel - Re: [PATCH 2/2] crypto/crc32[c]: register only "-lib" drivers

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250617202050.GB1288@sol>
Date: Tue, 17 Jun 2025 13:20:50 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: David Sterba <dsterba@...e.cz>
Cc: linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	Ard Biesheuvel <ardb@...nel.org>, linux-btrfs@...r.kernel.org,
	Alexander Gordeev <agordeev@...ux.ibm.com>,
	Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
	David Sterba <dsterba@...e.com>
Subject: Re: [PATCH 2/2] crypto/crc32[c]: register only "-lib" drivers

On Tue, Jun 17, 2025 at 10:17:48PM +0200, David Sterba wrote:
> On Fri, Jun 13, 2025 at 11:37:53AM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@...gle.com>
> > 
> > For the "crc32" and "crc32c" shash algorithms, instead of registering
> > "*-generic" drivers as well as conditionally registering "*-$(ARCH)"
> > drivers, instead just register "*-lib" drivers.  These just use the
> > regular library functions crc32_le() and crc32c(), so they just do the
> > right thing and are fully accelerated when supported by the CPU.
> > 
> > This eliminates the need for the CRC library to export crc32_le_base()
> > and crc32c_base().  Separate patches make those static functions.
> > 
> > Since this patch removes the "crc32-generic" and "crc32c-generic" driver
> > names which crypto/testmgr.c expects to exist, update crypto/testmgr.c
> > accordingly.  This does mean that crypto/testmgr.c will no longer
> > fuzz-test the "generic" implementation against the "arch" implementation
> > for crc32 and crc32c, but this was redundant with crc_kunit anyway.
> > 
> > Besides the above, and btrfs_init_csum_hash() which the previous patch
> > fixed, no code appears to have been relying on the "crc32-generic" or
> > "crc32c-generic" driver names specifically.
> > 
> > btrfs does export the checksum driver name in
> > /sys/fs/btrfs/$uuid/checksum.  This patch makes that file contain
> > "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)".  This
> > should be fine, since in practice the purpose of this file seems to have
> > been just to allow users to manually check whether they needed to enable
> > the optimized CRC32C code.  This was needed only because of the bug in
> > old kernels where the optimized CRC32C code defaulted to off and even
> > needed to be explicitly added to the ramdisk to be used.  Now that it
> > just works in Linux 6.14 and later, there's no need for users to take
> > any action and this file is basically obsolete.
> 
> Well, not the whole file, because it says which checksumming algo is
> used for the filesystem, but the implementation part is.

Oh, right.  It's one of those sysfs files that don't follow the normal sysfs
convention and contain multiple values.  I'll update the paragraph above to
clarify that it's referring to the driver name part of the file.

- Eric