Re: [PATCH 2/3] AF_ALG: Drop support for off-CPU cryptography
Eric Biggers <[email protected]> Sat, 25 Jul 2026 16:09:22 -0700
| Newsgroups | org.kernel.vger.io-uring,org.kernel.vger.linux-crypto,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-s390,org.kernel.vger.netdev |
|---|---|
| Message-ID | <20260725230922.GB41199@quark> |
On Sat, Jul 25, 2026 at 03:04:43PM -0700, Eric Biggers wrote: > If needed, "cbc(paes)" and/or "cbc-paes-caam" (whichever name it is > being accessed as) can be allowed as a special case, as a stop-gap. > > This would need confirmed use of that specific algorithm with upstream, > which we don't quite have yet. Dominique had a confirmed use of > "tk(cbc(aes))", but that has never existed upstream in the first place, > so it's not something that could be allowlisted upstream. > > You've only mentioned that it "can" be used in this way in upstream. > Can you confirm that it *is* used, and with an actual upstream algorithm > name, and if so which one(s)? And if so, would you also be able to > share whether this is for dm-crypt or not? We should remember that > dm-crypt accepts keys directly and AF_ALG is not needed to use it. We'd also need to know whether the user (if there is one) requires unprivileged use. Hopefully not: these sorts of hardware crypto drivers have lots of bugs. Indeed, the CAAM "cbc(paes)" doesn't validate the key length correctly, leaks DMA mappings, concurrent requests race with each other, etc... - Eric