linux-kernel - Re: [GIT PULL] CRC updates for 6.14

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: <CAHk-=wgqAZf7Sdyrka5RQQ2MVC1V_C1Gp68KrN=mHjPiRw70Jg@mail.gmail.com>
Date: Wed, 22 Jan 2025 20:13:07 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Ard Biesheuvel <ardb@...nel.org>, Chao Yu <chao@...nel.org>, "Darrick J. Wong" <djwong@...nel.org>, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, Kent Overstreet <kent.overstreet@...ux.dev>, 
	"Martin K. Petersen" <martin.petersen@...cle.com>, Michael Ellerman <mpe@...erman.id.au>, 
	"Theodore Ts'o" <tytso@....edu>, Vinicius Peixoto <vpeixoto@...amp.dev>, WangYuli <wangyuli@...ontech.com>
Subject: Re: [GIT PULL] CRC updates for 6.14

On Sun, 19 Jan 2025 at 14:51, Eric Biggers <ebiggers@...nel.org> wrote:
>
> - Reorganize the architecture-optimized CRC32 and CRC-T10DIF code to be
>   directly accessible via the library API, instead of requiring the
>   crypto API.  This is much simpler and more efficient.

I'm not a fan of the crazy crypto interfaces for simple hashes that
only complicate and slow things down, so I'm all in favor of this and
have pulled it.

HOWEVER.

I'm also very much not a fan of asking users pointless questions.

What does this patch-set ask users idiotic questions like

  CRC-T10DIF implementation
  > 1. Architecture-optimized (CRC_T10DIF_IMPL_ARCH) (NEW)
    2. Generic implementation (CRC_T10DIF_IMPL_GENERIC) (NEW)

and

  CRC32 implementation
  > 1. Arch-optimized, with fallback to slice-by-8
(CRC32_IMPL_ARCH_PLUS_SLICEBY8) (NEW)
    2. Arch-optimized, with fallback to slice-by-1
(CRC32_IMPL_ARCH_PLUS_SLICEBY1) (NEW)
    3. Slice by 8 bytes (CRC32_IMPL_SLICEBY8) (NEW)
    4. Slice by 4 bytes (CRC32_IMPL_SLICEBY4) (NEW)
    5. Slice by 1 byte (Sarwate's algorithm) (CRC32_IMPL_SLICEBY1) (NEW)
    6. Classic Algorithm (one bit at a time) (CRC32_IMPL_BIT) (NEW)

because *nobody* wants to see that completely pointless noise.

Pick the best one. Don't ask the user to pick the best one.

If you have some really strong argument for why users need to be able
to override the sane choice, make the question it at *least* depend on
EXPERT.

And honestly, I don't see how there could possibly ever be any point.
If there is an arch-optimized version, just use it.

And if the "optimized" version is crap and worse than some generic
one, it just needs to be removed.

None of this "make the user make the choice because kernel developers
can't deal with the responsibility of just saying what is best".

             Linus