Re: [PATCH 2/3] AF_ALG: Drop support for off-CPU cryptography

[Eric Biggers]

On Sat, Jul 25, 2026 at 01:32:12AM +0900, Dominique Martinet wrote:
> > There's no "tk(cbc(aes))" algorithm in the upstream kernel.  So, it's
> > not possible that this ever worked with upstream.  Given that, there's
> > no regression in upstream for this program, and it wouldn't be
> > appropriate to consider a sysctl knob in upstream at this time.
> 
> Bleh, you are correct, it's an NXP patch in
> drivers/crypto/caam/caamalg.c that they've been carrying in their
> tree(s) since 2018[1] and has apparently never been upstreamed...
> [1] https://github.com/nxp-imx/linux-imx/commit/6868c9e49c1854028fb46022daac3b1b10ca2c70
> 
> Sorry for not having checked, I was hoping for better.
> (I should be used to it by now...)
> 
> 
> Regardless of the specific algorithm, most recent SoCs flaunt some
> "secure element" or similiar hardware-backed keys (so one wouldn't be
> able to decrypt $whatever without running on the specific board it was
> intended for); I'm sure _some_ of them are upstream?
> (Never used it so not sure if they are reachable from af_alg, but for
> example drivers/crypto/ccree/cc_cipher.c talks about hardware key...)
> 
> There's not much I can do about the vendor's kernel I'm stuck with, but
> that doesn't make having encryption material not accessible to userspace
> useless as a concept;
> forgetting about the sysctl for now, what are the alternatives API this
> kind of implementations could be based on?
> 
> I guess I should start looking at how tpm backed encryption works,
> some other day, it's getting late here...

First, we should remember that implementing hardware-bound keys via a
standalone crypto engine is a dated approach.  Inline crypto engines and
CPUs, which work much better than and are much easier to use than legacy
standalone crypto engines, can support hardware-bound keys as well.  The
former is already supported, and is already being widely used, in the
kernel via the hardware-wrapped inline crypto keys feature.  For the
latter, see e.g. RISC-V High Assurance Cryptography.  In the CPU case no
UAPI is even needed; userspace can just use it directly.

But with that being said, yes, there are a few in-tree drivers that
register "paes" algorithms with the crypto_skcipher or crypto_aead APIs,
or "phmac" with crypto_ahash.  That made them accessible via AF_ALG.

Of course, no use of these via AF_ALG has actually been confirmed yet.
Note that any such use would be unrelated to any use via dm-crypt or
dm-integrity, as those features call the kernel's crypto code directly.

But if any are confirmed and we end up needing to allowlist any of these
specific hardware-bound key algorithms in AF_ALG for compatibility
reasons, we can do that.  That does not mean we should allowlist
out-of-tree algorithms, or asynchronous algorithms in general.

We should also remember that AF_ALG has never actually supported
creating hardware-bound keys.  Anyone using it actually needs to use a
different UAPI to create the key.  This is driver-specific.  For CAAM it
seems to involve keyctl() calls, whereas for s390 it's /dev/pkey.  Any
userspace program that (theoretically) would be using either one has to
know which type of hardware it's talking to anyway.

So with this being a dated approach and also driver-specific anyway, and
with at least one driver using a char device already, I think the
replacement here (if any is needed for the few standalone crypto engine
drivers that implement this) would just be a driver-specific char device
with the minimum functionality required.  We shouldn't overthink things.

- Eric