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: <20250617201748.GE4037@suse.cz>
Date: Tue, 17 Jun 2025 22:17:48 +0200
From: David Sterba <dsterba@...e.cz>
To: Eric Biggers <ebiggers@...nel.org>
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 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.