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

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

[Harald Freudenberger]

> AF_ALG is deprecated and exposed to unprivileged userspace.  Only
> use the least buggy algorithm implementations: the pure software ones.
>

I thought AF_ALG is marked as deprecated but still usable. This patch
now actively disables groups of crypto implementations. Also it just
assumes that all algorithms which are asynchronously implemented or
do not have a fallback are to be disabled via AF_ALG.

There are may reasons for not having a synchronous implementation. For
example if you need to fetch (asynch) some information from a HSM before
doing the job of the algorithm. Also all secure key operations can't
by definition run directly on the CPU but need to be fed into some
hardware. Same is true with just acceleration - and acceleration via
special hardware (crypto hw, or AI hardware for example) is very common
on platforms priced by CPU cycles.

I also can't find any arguments for the statement 'Hardware accelerator
drivers are frequently buggy.' Does this mean that the linux kernel
from now on will not accept any hardware accelerator drivers any more?
Statements about code quality should be addressed to the driver
maintainer but not lead to tagging of groups of drivers.

I can understand that the AF_ALG shall be deprecated and fade away.
But this patch out of the sudden disables the long standing AF_ALG
interface at least for testing purpose and causes some failures in
the s390 crypto test area without any chance to react at all.

> This removes one of the main advantages of AF_ALG, which is the
> ability to use it with off-CPU accelerators.  However, using off-CPU
> accelerators has huge overheads, both in performance and attack surface.
> I have yet to see real-world, performance-critical workloads where using
> an accelerator via AF_ALG is actually a win over doing cryptography in
> userspace.
>
> If using an off-CPU accelerator really does turn out to be a win, a new
> API should be developed that is actually a good fit for it.
>
> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> ---
>  Documentation/crypto/userspace-if.rst |  7 ++++++-
>  crypto/af_alg.c                       |  2 +-
>  crypto/algif_aead.c                   |  4 ++--
>  crypto/algif_hash.c                   |  4 ++--
>  crypto/algif_rng.c                    |  4 ++--
>  crypto/algif_skcipher.c               |  4 ++--
>  include/crypto/if_alg.h               | 14 +++++++++++++-
>  7 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
> index ea1b1b3f4049fd4673528dc2a6234f6376a3489f..b31117d4415dda6ad6ca36275e615bec7df9552e 100644
> --- a/Documentation/crypto/userspace-if.rst
> +++ b/Documentation/crypto/userspace-if.rst
> @@ -9,7 +9,8 @@ symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
>  code.
>
>  AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
> -most kernel developers now consider it to be a mistake.
> +most kernel developers now consider it to be a mistake. Support for hardware
> +accelerators, which was the original purpose of AF_ALG, has been removed.
>
>  AF_ALG continues to be supported only for backwards compatibility. On systems
>  where no programs using AF_ALG remain, the support for it should be disabled by
> @@ -59,6 +60,10 @@ Some of the examples include:
>  - CVE-2013-7421
>  - CVE-2011-4081
>
> +Hardware accelerator drivers are frequently buggy. To reduce attack surface,
> +AF_ALG now only provides access to algorithms implemented in software. This
> +means that AF_ALG no longer fulfills its original purpose.
> +
>  It is recommended that, whenever possible, userspace programs be migrated to
>  userspace crypto code (which again, is what is normally used anyway) and
>  ``CONFIG_CRYPTO_USER_API_*`` be disabled.  On systems that use SELinux, SELinux
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 8ccf7a737cd6ca9a5d5bf47050c9afea0dfd61bf..cce000e8590e469927b5a5a0ceccfdf0ef54633d 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -181,7 +181,7 @@ static int alg_bind(struct socket *sock, struct sockaddr_unsized *uaddr, int add
>	if (IS_ERR(type))
>		return PTR_ERR(type);
>
> -	private = type->bind(sa->salg_name, sa->salg_feat, sa->salg_mask);
> +	private = type->bind(sa->salg_name);
>	if (IS_ERR(private)) {
>		module_put(type->owner);
>		return PTR_ERR(private);
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index 60f06597cb0b13036bc975641a0b02ea8a41ad03..787aac8aeb24eed128f08345ba730478113919b3 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -342,9 +342,9 @@ static struct proto_ops algif_aead_ops_nokey = {
>	.poll		=	af_alg_poll,
>  };
>
> -static void *aead_bind(const char *name, u32 type, u32 mask)
> +static void *aead_bind(const char *name)
>  {
> -	return crypto_alloc_aead(name, type, mask);
> +	return crypto_alloc_aead(name, 0, AF_ALG_CRYPTOAPI_MASK);
>  }
>
>  static void aead_release(void *private)
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 4d3dfc60a16a6d8b677d903d209df18d67202c98..5452ad6c15069c3cb0ff78fe58868fe7ce4b0fc3 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -380,9 +380,9 @@ static struct proto_ops algif_hash_ops_nokey = {
>	.accept		=	hash_accept_nokey,
>  };
>
> -static void *hash_bind(const char *name, u32 type, u32 mask)
> +static void *hash_bind(const char *name)
>  {
> -	return crypto_alloc_ahash(name, type, mask);
> +	return crypto_alloc_ahash(name, 0, AF_ALG_CRYPTOAPI_MASK);
>  }
>
>  static void hash_release(void *private)
> diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
> index a9fb492e929a70c94476f296f5f5e7c42f0313b7..4dfe7899f8fa4ce82d5f2236297230fb44bc35d6 100644
> --- a/crypto/algif_rng.c
> +++ b/crypto/algif_rng.c
> @@ -197,7 +197,7 @@ static struct proto_ops __maybe_unused algif_rng_test_ops = {
>	.sendmsg	=	rng_test_sendmsg,
>  };
>
> -static void *rng_bind(const char *name, u32 type, u32 mask)
> +static void *rng_bind(const char *name)
>  {
>	struct rng_parent_ctx *pctx;
>	struct crypto_rng *rng;
> @@ -206,7 +206,7 @@ static void *rng_bind(const char *name, u32 type, u32 mask)
>	if (!pctx)
>		return ERR_PTR(-ENOMEM);
>
> -	rng = crypto_alloc_rng(name, type, mask);
> +	rng = crypto_alloc_rng(name, 0, AF_ALG_CRYPTOAPI_MASK);
>	if (IS_ERR(rng)) {
>		kfree(pctx);
>		return ERR_CAST(rng);
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index 9dbccabd87b13920c27aff5a450a235cc6a27d59..df20bdfe1f1f4e453782dee3b743dd1939ab4c6c 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -307,9 +307,9 @@ static struct proto_ops algif_skcipher_ops_nokey = {
>	.poll		=	af_alg_poll,
>  };
>
> -static void *skcipher_bind(const char *name, u32 type, u32 mask)
> +static void *skcipher_bind(const char *name)
>  {
> -	return crypto_alloc_skcipher(name, type, mask);
> +	return crypto_alloc_skcipher(name, 0, AF_ALG_CRYPTOAPI_MASK);
>  }
>
>  static void skcipher_release(void *private)
> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
> index 62867daca47d76c9ea1a7ed233188788c5f6c3c0..7643ba954125aba0c06aaf19de087985325885ad 100644
> --- a/include/crypto/if_alg.h
> +++ b/include/crypto/if_alg.h
> @@ -41,7 +41,7 @@ struct af_alg_control {
>  };
>
>  struct af_alg_type {
> -	void *(*bind)(const char *name, u32 type, u32 mask);
> +	void *(*bind)(const char *name);
>	void (*release)(void *private);
>	int (*setkey)(void *private, const u8 *key, unsigned int keylen);
>	int (*setentropy)(void *private, sockptr_t entropy, unsigned int len);
> @@ -243,4 +243,16 @@ int af_alg_get_rsgl(struct sock *sk, struct msghdr *msg, int flags,
>		    struct af_alg_async_req *areq, size_t maxsize,
>		    size_t *outlen);
>
> +/*
> + * Mask used to disable unsupported algorithm implementations.
> + *
> + * This is the same as FSCRYPT_CRYPTOAPI_MASK in fs/crypto/fscrypt_private.h.
> + * In additions to the motivations there, this API is exposed to userspace
> + * that might not be fully trusted.
> + */
> +#define AF_ALG_CRYPTOAPI_MASK                             \
> +	(CRYPTO_ALG_ASYNC | CRYPTO_ALG_ALLOCATES_MEMORY | \
> +	 CRYPTO_ALG_KERN_DRIVER_ONLY)
> +
> +
>  #endif	/* _CRYPTO_IF_ALG_H */
>
> --
> 2.54.0
>

Harald Freudenberger

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

[Dominique Martinet]

Harald Freudenberger wrote on Wed, Jun 03, 2026 at 03:33:12PM +0200:
> > AF_ALG is deprecated and exposed to unprivileged userspace.  Only
> > use the least buggy algorithm implementations: the pure software ones.
> >
> 
> I thought AF_ALG is marked as deprecated but still usable. This patch
> now actively disables groups of crypto implementations. Also it just
> assumes that all algorithms which are asynchronously implemented or
> do not have a fallback are to be disabled via AF_ALG.
> 
> There are may reasons for not having a synchronous implementation. For
> example if you need to fetch (asynch) some information from a HSM before
> doing the job of the algorithm. Also all secure key operations can't
> by definition run directly on the CPU but need to be fed into some
> hardware. Same is true with just acceleration - and acceleration via
> special hardware (crypto hw, or AI hardware for example) is very common
> on platforms priced by CPU cycles.
> 
> I also can't find any arguments for the statement 'Hardware accelerator
> drivers are frequently buggy.' Does this mean that the linux kernel
> from now on will not accept any hardware accelerator drivers any more?
> Statements about code quality should be addressed to the driver
> maintainer but not lead to tagging of groups of drivers.
> 
> I can understand that the AF_ALG shall be deprecated and fade away.
> But this patch out of the sudden disables the long standing AF_ALG
> interface at least for testing purpose and causes some failures in
> the s390 crypto test area without any chance to react at all.

I've also stumbled upon this for our embedded use case: we use CAAM
"blob" keys on NXP socs (specifically i.MX8MP and i.MX8ULP at least),
which pretty much requires af_alg, because the key material is just not
available: it's not a matter of performance (we actually only
encrypt/decrypt a few KB that will be used for LUKS key or similar), the
hardware is required to perform the operation, and the only API
available is through the kernel afaik.

The tool source is available here:
https://github.com/nxp-imx/crypto_af_alg
(which now fails with:
bind(3, {sa_family=AF_ALG, salg_type="skcipher", salg_feat=0, salg_mask=0, salg_name="tk(cbc(aes))"}, 88) = -1 ENOENT (No such file or directory)
)


I don't particularily care for the API used as long as we can keep using
the hardware key, but as far as I can see there's no alternative API --
what's the path forward?

Short term would it make sense to re-enable and make it a sysctl knob
like af_alg_restrict[1]?
[1] https://lore.kernel.org/linux-crypto/20260622234803.6982-1-ebiggers@kernel.org/T/#u

Longer term we don't need many algorithm (the tool only supports
AES-256-CBC), so a much simpler API would do, but some replacement would
be greatly appreciated.. Embedded being embedded we can always kludge
something in, but I'd rather not fall back to that.


(I also second this felt sudden, I only noticed because the sysctl knob
made noise on fedora lists and I wanted to try, and it didn't
cherry-pick cleanly without this patch so that made me try, but I
probably wouldn't have noticed until much later otherwise...)


Thanks,
-- 
Dominique Martinet | Asmadeus

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

[Eric Biggers]

On Sat, Jul 25, 2026 at 12:35:55AM +0900, Dominique Martinet wrote:
> The tool source is available here:
> https://github.com/nxp-imx/crypto_af_alg
> (which now fails with:
> bind(3, {sa_family=AF_ALG, salg_type="skcipher", salg_feat=0, salg_mask=0, salg_name="tk(cbc(aes))"}, 88) = -1 ENOENT (No such file or directory)
> )
> 
> 
> I don't particularily care for the API used as long as we can keep using
> the hardware key, but as far as I can see there's no alternative API --
> what's the path forward?

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.

- Eric

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

[Dominique Martinet]

Eric Biggers wrote on Fri, Jul 24, 2026 at 09:00:34AM -0700:
> On Sat, Jul 25, 2026 at 12:35:55AM +0900, Dominique Martinet wrote:
> > The tool source is available here:
> > https://github.com/nxp-imx/crypto_af_alg
> > (which now fails with:
> > bind(3, {sa_family=AF_ALG, salg_type="skcipher", salg_feat=0, salg_mask=0, salg_name="tk(cbc(aes))"}, 88) = -1 ENOENT (No such file or directory)
> > )
> > 
> > 
> > I don't particularily care for the API used as long as we can keep using
> > the hardware key, but as far as I can see there's no alternative API --
> > what's the path forward?
> 
> 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...


Thank you,
-- 
Dominique Martinet | Asmadeus

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

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 3824 bytes --]

On 7/24/26 12:32, Dominique Martinet wrote:
> Eric Biggers wrote on Fri, Jul 24, 2026 at 09:00:34AM -0700:
>> On Sat, Jul 25, 2026 at 12:35:55AM +0900, Dominique Martinet wrote:
>>> The tool source is available here:
>>> https://github.com/nxp-imx/crypto_af_alg
>>> (which now fails with:
>>> bind(3, {sa_family=AF_ALG, salg_type="skcipher", salg_feat=0, salg_mask=0, salg_name="tk(cbc(aes))"}, 88) = -1 ENOENT (No such file or directory)
>>> )
>>>
>>>
>>> I don't particularily care for the API used as long as we can keep using
>>> the hardware key, but as far as I can see there's no alternative API --
>>> what's the path forward?
>>
>> 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...

I actually had this thought myself, though with a different
use-case: preventing long-term keys (like TLS and SSH keys and
cookie signing/encryption keys) from being accidentally leaked.

I came up with a much simpler API than AF_ALG:

1. Generate a file descriptor and a wrapping key.  The wrapping key
   is used to encrypt data that will be imported.

2. Import an encrypted secret key.  The key contains both the secret
   key and the algorithm it will be used with.

3. Optionally, attach a restriction policy that requires data to
   be signed to start with a certain prefix.  This provides domain
   separation in contexts where the same key is used for multiple
   purposes.

4. Pass the file descriptor to another process via SCM_RIGHTS.

5. The receiving process can use ioctls to perform secret-key
   operations, such as ML-KEM, ML-DSA, XChaCha20-Poly1305, and
   XAES-256-GCM.

6. When the file descriptor is closed, the secret key is securely
   deleted.
   
Compared to AF_ALG, the kernel attack surface is very small.  It's not
quite a "hello world" character device driver, but compared to many
of the other drivers in the kernel, it is tiny.  Furthermore, the
whole thing should be able to be written in safe Rust.

To keep the attack surface minimal, this would only use library
functions, so there would be no support for hardware-wrapped keys.

I don't plan to work on this myself, but I think it's of potential
value in the future.  For asymmetric algorithms, the overhead of a
system call should be fairly small compared to the operation itself.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Dominique Martinet]

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

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

[Simon Richter]

[-- Attachment #1.1: Type: text/plain, Size: 4775 bytes --]

Hi,

On 7/25/26 16:37, Dominique Martinet wrote:

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

The thing is: such an API would have to look completely different from 
the API we have now, and all the existing drivers would need to be 
ported to it.

The current API is designed around the assumption that the hardware can 
be interfaced with minimal overhead. This assumption is no longer true 
for any hardware built in the last ten years at least.

One example for this assumption is the "import" and "export" functions 
in ahash: these are synchronous even though the hash is supposed to be 
asynchronous. That is not a problem for the old hardware, since we can 
just grab the hash state via direct register access, but it makes it 
close to impossible to write a conforming implementation on anything 
more modern.

I've tried on an FPGA, but even with full control over the hardware 
implementation, I need to either serialize all requests and reduce 
performance, or implement an elaborate system where each request context 
goes into a separate virtual queue that can be synchronized without 
affecting other in-flight requests. On the other hand, I need that 
mechanism anyway, because ahash is not expected to return the result via 
DMA -- instead, we are supposed to use an interrupt that collects the 
result and starts the next queued request if there is any.

I don't believe ahash/acomp/acrypt is salvageable, because it is not 
only a problem on the hardware side, but also on the client side. The 
words "if there is any" are doing a lot of heavy lifting here, because 
most clients submit requests sequentially because the context cannot be 
reused until it is idle, except for queuing more data for streaming -- 
so you'd also need a request pool.

We need to both hide that complexity from the clients, and make it also 
optional and subject to negotiation, because the majority of machines 
out there simply do not have crypto hardware, so we want to skip the 
extra overhead there and just use the CPU.

So, for a new common API, a napkin design would look like

  - merged sync and async interfaces
    (completion through a callback, which can be a tail call)
  - same for user API
  - context switches optional
    - CPU implementation runs in userspace via vDSO
    - hardware that supports user virtual addresses (OpenCAPI, IBM NX) 
is programmed from userspace
  - negotiation of DMA requirements
    - CPU: none
    - most engines: 64 bit
    - some engines: 32 bit
  - cheap batch submission
    - cancellation of in-flight requests
    - submission of additional requests while a batch is under way
    - negotiated fallback to single-request submission (for CPU algs)
  - lightweight contexts with asynchronous creation
    - different keys or IVs
    - copies of other contexts

So, the (normal) CPU fallback case would have the client code get a 
(heavyweight) context for the chosen algorithm, which has a flag that 
says "batch submission is not beneficial", the client code would call 
into a function inside this context, submitting a single request and a 
completion callback, the handler function would call into the crypto 
library and subsequently tail call into the completion function

If the callback code is the only processing needed, then the call into 
the function provided by the context could be a tail call already (so 
the return type of the callback and of the crypto function would have to 
be the same, and the callback would have to pinky promise to always 
return success).

The offload case would have different implementations depending on 
whether the hardware supports on-device queues or not, but it would 
likely ask clients to submit a large batch if possible (so if we have an 
1 MB request for file system data, we see more than 4 kB of it).

It may even be possible to make the entry points lightweight enough that 
submission of batches does not even need a separate interface, just 
calling the entry for a single request repeatedly (and maybe another 
"flush" function at the end) may turn out to be sufficient.

That is pretty much the only approach I can come up with that can 
abstract away the hardware differences and still be somewhat usable on 
the client side. As I said, this is a napkin design, and it would need a 
lot of thoughts on the security aspects -- I've been looking at it from 
a "how to keep the pipeline fed" point of view.

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2568 bytes --]

On 7/25/26 03:37, Dominique Martinet wrote:
> 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 Qualcomm Inline Crypto Engine is a type of inline encryption
hardware.  Inline encryption hardware is integrated in the I/O path,
so using it doesn't involve any extra copies or interrupts.  The data
goes from memory to crypto hardware to the I/O target, and from the
I/O target to crypto hardware to memory.  The ciphertext is never
written to memory.

In the case of the Qualcomm Inline Crypto Engine, the I/O target is
the the storage device.  On Android, that's eMMC or UFS.  I would be
very surprised if the Inline Crypto Engine was any slower than the
storage device connected to it.

In Linux, inline storage encryption is exposed via the blk-crypto
framework.  It works very well and is widely used on Android.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eric Biggers]

On Sat, Jul 25, 2026 at 04:37:24PM +0900, Dominique Martinet wrote:
> 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.

I guess I should have written "inline encryption hardware", which is the
vendor-independent term we've been using in the kernel, just in case
anyone thinks "inline crypto engine" means the "Qualcomm Inline Crypto
Engine" specifically (but really, IMO they are just descriptive phrases
that mean the same thing).  There are many different hardware vendors
that have inline encryption hardware for UFS and/or eMMC.

Their interface is quite simple and doesn't use PKCS#11 at all.  I don't
know where you're seeing anything about PKCS#11.

See also the documentation in Documentation/block/inline-encryption.rst

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

Yes, and similar developments are also occurring on other CPU
architectures, like Intel's Key Locker.

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

Neither of these patches is tagged with 'Cc stable', and I don't expect
them to be backported to stable kernels soon.  That being said, it seems
the people using LLMs to find vulnerabilities haven't focused much on
drivers/crypto/ yet.  Once they do, well, they will of course find
vulnerabilities everywhere (accessible from unprivileged userspace via
AF_ALG), and when that happens there may be little choice.

The addition of the af_alg_restrict sysctl (and the possibility of
userspace explicitly choosing to disable restrictions by setting
af_alg_restrict=0) doesn't necessarily mean that problematic
functionality should be, or should have been, moved under
af_alg_restrict=0 rather than removed outright.  It's just an option
that can be used if needed for compatibility reasons, if actual user
reports come in.  If something is not needed at all it can just be
dropped right away.  This actually happens way more often than people
might think, due to the immense amount of unnecessary functionality that
AF_ALG has: *many* crypto algorithms have been removed from AF_ALG over
the years without any complaints, since they were never used.

I'll also note that hardware crypto "decelerator" driver authors are
actually now *depending* on the drivers no longer being usable from
AF_ALG in mainline in order to argue for more relaxed driver inclusion
criteria.  I don't think they can have it both ways!

- Eric

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

[Richard Weinberger]

On Fri, Jul 24, 2026 at 6:41 PM Dominique Martinet
<asmadeus@codewreck.org> 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...)

Sorry for joining the party so late, you're killing AF_ALG faster than
I can follow all the mails.
Speaking of CAAM, there is a legit usecase which exists mainline. No
vendor patches needed.

You can create a CAAM BLOB (a generated and sealed key) using the
trusted keys subsystem and use this BLOB
later in AF_ALG to perform AES with a key invisible to userspace.

e.g.
kid=$(keyctl add trusted mykey "new 32 pk" @s)
keyctl print $kid | xxd -r -p > blob.bin
Then just create a caam_pkey_info in userspace and feed it into AF_ALG
and perform AES with it.

So, pretty please,  if you kill AF_ALG and all this, offer some way to
achieve the same in userspace.

-
Thanks,
//richard

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

[Eric Biggers]

On Sat, Jul 25, 2026 at 10:55:03PM +0200, Richard Weinberger wrote:
> Speaking of CAAM, there is a legit usecase which exists mainline. No
> vendor patches needed.
> 
> You can create a CAAM BLOB (a generated and sealed key) using the
> trusted keys subsystem and use this BLOB
> later in AF_ALG to perform AES with a key invisible to userspace.
> 
> e.g.
> kid=$(keyctl add trusted mykey "new 32 pk" @s)
> keyctl print $kid | xxd -r -p > blob.bin
> Then just create a caam_pkey_info in userspace and feed it into AF_ALG
> and perform AES with it.

Well, specifically AES-CBC.  That's the only one that is in the driver.

> So, pretty please,  if you kill AF_ALG and all this, offer some way to
> achieve the same in userspace.

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.

- Eric

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

[Eric Biggers]

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