linux-kernel - Re: Crypto use cases

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: <854efc41-c40f-46c9-b8ae-84bda9d17faa@hogyros.de>
Date: Tue, 5 Aug 2025 16:17:49 +0900
From: Simon Richter <Simon.Richter@...yros.de>
To: Eric Biggers <ebiggers@...nel.org>
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

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.

However if we don't want separate registries, then it makes no sense for 
the kernel to set policy for userspace here; it should offer all the 
alternatives. The kernel can, and should, define policy for itself, and 
I wholeheartedly agree that offloading small requests does not make 
sense, unless we're on battery power.

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.

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.

    Simon