Message-ID: <20250805171558.GC1286@sol>
Date: Tue, 5 Aug 2025 10:15:58 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Simon Richter <Simon.Richter@...yros.de>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ard Biesheuvel <ardb@...nel.org>,
	"Jason A . Donenfeld" <Jason@...c4.com>, linux-mips@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org
Subject: Re: Crypto use cases

On Tue, Aug 05, 2025 at 04:17:49PM +0900, Simon Richter wrote:
> Hi,
> 
> On 8/5/25 13:58, Eric Biggers wrote:
> 
> > What does this have to do with this thread, which is about the PowerPC
> > optimized MD5 code?
> 
> Hence the new subject. It is still related to removal of code, but asks
> about the bigger picture.
> 
> The code removal changes you've been pushing lately absolutely make sense in
> the context of "the crypto subsystem is for internal use by the kernel, and
> all known users will only ever submit small work items."
> 
> However, there is also the userspace API, and hardware accelerators also
> register with the crypto subsystem, so it is *also* the way for userspace to
> use specialized hardware.
> 
> If these are separate, then it makes sense to acknowledge that the kernel
> will never use asynchronous transforms for anything, simplify the internal
> API, and move all the hardware support to a separate registry that is for
> userspace applications only.

I think you're grouping together different things that aren't actually
very related.  For example this patch series proposed removing some
software code, not async drivers.  The only async driver I removed
recently is one of the crc32c ones.

Doesn't lib/crypto/ largely accomplish what you're thinking of as
"separate registries"?  As we migrate more in-kernel users to
lib/crypto/, the old-school crypto API becomes more focused just on
accomodating AF_ALG users.  However, that is, and will continue to be, a
long process.  In the mean time we still have many in-kernel users of
the old-school crypto API to decide what to do with.

> I'm also not convinced that fscrypt cannot ever learn to submit a single
> large request or a large batch of small requests if it is asked to decrypt a
> large file, so in my opinion the common registry makes more sense.

It's certainly never going to be the entire file or a single batch.
That's just not how filesystems work.

As for offloading entire I/O requests, fscrypt already supports that,
just for inline crypto engines instead of the old-school separate ones.
Inline encryption is fundamentally much more efficient.  The same
efficiency can't be achieved with a separate engine, even with a large
batch.  If people would like to continue to explore that approach
anyway, they're free to do so, but it's not a promising approach, at
least not on any of the platforms I examined.  (And pointing to
irrelevant data, like for compression, is not helpful.)

> Making sure that hardware support actually works and is tested is the
> responsibility of the driver and port maintainers. We understand that
> subsystem maintainers do not have all the hardware available, but the same
> goes for all the other subsystems -- the DRM maintainers routinely merge
> drivers for hardware they do not own, because the changes come from people
> who *do* own the hardware, and have tested the changes.
> 
> The latter is a project management issue, mostly: if there is a lack of
> working relationships with driver and port maintainers, then that needs to
> be fixed, not assumed to be an unchangeable part of the environment that
> technical decisions are made in.

This significantly understates the challenge that exists with a large
number of drivers, including orphaned drivers and architectures, as well
as the high standard of correctness that cryptography code needs to have
vs. more everyday device drivers.  And also the fact that async offload
drivers are fundamentally much harder to get correct than software code.
The odds are really stacked against everyone here, and I think calling
it a "project management issue" largely misses the point.

- Eric

Powered by blists - more mailing lists