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

[Dominique Martinet <asmadeus@codewreck.org>]

Thank you both for your time replying

Eric Biggers wrote on Fri, Jul 24, 2026 at 06:09:51PM +0000:
> On Sat, Jul 25, 2026 at 01:32:12AM +0900, Dominique Martinet wrote:
> > 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.

Thank you, this is exactly what I was asking about - my background isn't
crypto and ultimately whatever direction is implemented will depend on
$vendor and I'll just be following along, but I'll read up on this.

"Inline crypto engine" seems to be a qualcomm marketing term, but from
looking at their doc the API seems to be PKCS#11 smart card?
Having worked on these for some other hardware I can't say I find it
easier to use than af alg, but it's definitely something that can be
worked out.

"The CPU case" (looking at the RISC-V High Assurance Cryptography) would
be some CPU instructions (ISA) reserved for crypto ops?
That's interesting, I had never seen this but I can see this would
likely provide the best performance.. And if the ISA gain enough
traction having them supported out of the box by OpenSSL or whatsnot
might actually be possible, that'd be a great step forward.


> 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.

Right, sorry for asking about an out-of-tree driver, I hadn't realized
since caam itself has been upstream for a while.

I was just curious about the double-take approach taken with these two patches:
 crypto: af_alg - Drop support for off-CPU cryptography (this)
 crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1 ([4])
[4] https://lore.kernel.org/linux-crypto/20260622234803.6982-1-ebiggers@kernel.org/T/#u

I assume part of it was just that the whitelist wasn't ready yet when
this patch was merged, but as far as I understand if the whitelist
sysctl is implemented this is basically noop?
(Well, I guess it'll allow code simplification over time, but these
hopefully won't be backported to stable kernels too aggressively.. While
I fully expect to see this "Drop support for off-CPU crypto" patch to
show up in a couple of weeks in older stable trees; and for practical
purposes I don't see much way around just reverting it for now)

Thanks for putting up with me.

> 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.

Right, the program I rely on actually uses a /dev/caam-keygen device
from another NXP non-upstreamed patch, but you are correct that there is
driver specific glue already.

> 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.

So this is basically what Demi Marie suggested as well, and I'm sure we
can come up with driver specific APIs that are simpler than af alg,
but these are actually a pain to support for me (in my position of
"device integrator" building OS blocks for a variety of platforms)

I'm also "supporting" SE050 and ATECC608A out of chip "secure elements",
as well as looking at i.MX in-chip "edgelock secure enclave" as well as
the caam algorithm I was talking about here, and they all require some
sort of middleware that's far from trivial to configure and get to play
nice together
(if someone's curious, these three:
 https://github.com/NXP/plug-and-trust
 https://github.com/microchiptech/cryptoauthlib
 https://github.com/nxp-imx/imx-secure-enclave
)

So being selfish I'd very much appreciate some effort to have a standard
API everyone could use to simplify my userspace, but given vendors will
never spend this kind of time I guess it's a pipe dream and I'll be
stuck with custom drivers and/or framework for the forseeable future...
But it's not like complaining about this to either of you is any help,
I'm grateful you took the time to answer so far.


Thanks,
-- 
Dominique Martinet | Asmadeus