linux-kernel - Re: [PATCH v2] crypto: stm32 - remove crc32 and crc32c support

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: <20250608234458.GD1259@sol>
Date: Sun, 8 Jun 2025 16:44:58 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: linux-kernel@...r.kernel.org
Cc: linux-crypto@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Fabien Dessenne <fabien.dessenne@...s.st.com>,
	Lionel Debieve <lionel.debieve@...s.st.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH v2] crypto: stm32 - remove crc32 and crc32c support

On Sun, Jun 01, 2025 at 12:34:41PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
> 
> Remove the crc32 and crc32c support from the stm32 driver.  Since it's
> not wired up to the CRC library, almost no CRC user in the kernel can
> actually be taking advantage of it, so it's effectively dead code.
> 
> Support for this hardware could be migrated to the CRC library, but
> there doesn't seem to be much point.  This CRC engine is present only on
> a couple older SoCs that lacked CRC instructions.
> 
> Even on those SoCs, it's probably not worthwhile.  This driver has to
> deal with things like locking and runtime power management that do not
> exist in software CRC code and are a source of bugs (as is clear from
> the commit log) and add significant overhead to the processing of short
> messages, which are common.  The patch that originally added this driver
> seemed to justify it based purely on a microbenchmark on Cortex-M7 on
> long messages, not a real use case.  These days, if this driver were to
> be used at all it would likely be on Cortex-A7 instead.  This CRC engine
> is also not supported by QEMU, making the driver not easily testable.
> 
> Acked-by: Ard Biesheuvel <ardb@...nel.org>
> Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>
> Cc: Fabien Dessenne <fabien.dessenne@...s.st.com>
> Cc: Lionel Debieve <lionel.debieve@...s.st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>
> Cc: linux-stm32@...md-mailman.stormreply.com
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> ---
> 
> v2: reworked commit message and added Acked-by
> 
>  arch/arm/configs/multi_v7_defconfig |   1 -
>  drivers/crypto/stm32/Kconfig        |   9 -
>  drivers/crypto/stm32/Makefile       |   1 -
>  drivers/crypto/stm32/stm32-crc32.c  | 480 ----------------------------
>  4 files changed, 491 deletions(-)
>  delete mode 100644 drivers/crypto/stm32/stm32-crc32.c

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next

Adjusted wording in commit message slightly:

"Even on those SoCs, it's probably not worthwhile."

=>

"Even for those SoCs, it probably wouldn't be worthwhile."

... since it's talking about a hypothetical port to the CRC library, not the
status quo where the driver is almost never used anyway.

- Eric