linux-kernel - Re: [GIT PULL] Crypto Update for 6.15

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: <Z-N55Yjve6wTnPqm@gondor.apana.org.au>
Date: Wed, 26 Mar 2025 11:52:05 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [GIT PULL] Crypto Update for 6.15

On Tue, Mar 25, 2025 at 08:34:04PM -0700, Eric Biggers wrote:
>
> So I think your observation about the workqueue being unhelpful is generally
> correct, but fixing that is already partially implemented and is being worked on
> further.  And regardless, this does not have that much relevance to the crypto
> API.  Yes, you can't sleep from a softirq, which means you can't wait for an
> async crypto request to complete (other than polling).  So if you want to do
> that, you have to go down the workqueue code path.  But in practice 99% of users
> are just using the CPU-based crypto that is synchronous and does not block.

The point is that you don't have to wait.  Once verity verification
is done, all you do is mark the page/folio as up-to-date.  That work
can be done directly from softirq context.  So all you need to do to
support async crypto is to mark the page/folio as up-to-date from the
completion function, no work queues are needed anywhere.

Look, right now you've got this crazy cargo cult programming paradigm
of work queues that is worshipped because it lets you wait for async
completion.  In reality it is forcing everybody to go async even when
they don't need it.  Take ext4 as an example:

	ext4 calls verity
	schedule_work(verity_work);
	return asynchronously!

verity_work:
	do the crypto work
	__read_end_io(bio);

Just get rid of the work queue, it is not needed for async crypto,
which you don't even support anymore because you hate the interface
so much.

Even if we want to support async crypto, all you have to do is move
the __read_end_io call into the async completion function.  Voila,
no work queues are needed.

	ext4 calls verity

verity:
	ret = do the crypto work
	if (is_async(ret))
		return asynchronously;
	__read_end_io(bio)
	return synchronously;

async completion:
	__read_end_io(bio)

Networking has been doing this since 2008, I have no idea why storage
insists on the crazy workqueue paradigm.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt