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

Message-ID: <20250619125944.GJ4037@suse.cz>
Date: Thu, 19 Jun 2025 14:59:44 +0200
From: David Sterba <dsterba@...e.cz>
To: Daniel Vacek <neelx@...e.com>
Cc: Eric Biggers <ebiggers@...nel.org>, 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 Thu, Jun 19, 2025 at 12:27:13PM +0200, Daniel Vacek wrote:
> > I revised it to:
> >
> > btrfs does export the checksum name and checksum driver name in
> > /sys/fs/btrfs/$uuid/checksum.  This commit makes the driver name portion
> > of that file contain "crc32c-lib" instead of "crc32c-generic" or
> > "crc32c-$(ARCH)".  This should be fine, since in practice the purpose of
> > the driver name portion 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
> > the driver name portion of this is basically obsolete.  (Also, note that
> > the crc32c driver name already changed in 6.14.)
> 
> How about instead removing that part since it's useless now?

There's no best answer, removing it makes sense but could break
somebody's scripts parsing that file. The information put to "(...)"
might be useful in the future again. It's less harm to leave it there
than to deal with potential fallout if it's removed.