[PATCH] crypto: af_alg: Allow cbc(paes)

[PATCH] crypto: af_alg: Allow cbc(paes)

[Richard Weinberger]

Commit 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography")
breaks a special use case.  The cbc-paes-caam driver implements the
algorithm cbc(paes), it offers a way to use AES in CBC mode with key
material unknown to userspace.  Instead of an AES key a CAAM BLOB is
passed to the kernel.  So, this crypto operation cannot be
implemented in a userspace library and needs always help from the
kernel.

Explicitly allow this use case.

Cc: Demi Marie Obenour <demiobenour@gmail.com>
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Fixes: 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography")
Signed-off-by: Richard Weinberger <richard@nod.at>
---
 crypto/algif_skcipher.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index df20bdfe1f1f..035fed7db81f 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -32,6 +32,7 @@
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/net.h>
+#include <linux/string.h>
 #include <net/sock.h>
 
 static int skcipher_sendmsg(struct socket *sock, struct msghdr *msg,
@@ -309,7 +310,12 @@ static struct proto_ops algif_skcipher_ops_nokey = {
 
 static void *skcipher_bind(const char *name)
 {
-	return crypto_alloc_skcipher(name, 0, AF_ALG_CRYPTOAPI_MASK);
+	u32 mask = AF_ALG_CRYPTOAPI_MASK;
+
+	if (strcmp(name, "cbc(paes)") == 0)
+		mask = 0;
+
+	return crypto_alloc_skcipher(name, 0, mask);
 }
 
 static void skcipher_release(void *private)
-- 
2.51.0

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Eric Biggers]

On Sun, Jul 26, 2026 at 09:27:16PM +0200, Richard Weinberger wrote:
> Commit 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography")
> breaks a special use case.  The cbc-paes-caam driver implements the
> algorithm cbc(paes), it offers a way to use AES in CBC mode with key
> material unknown to userspace.  Instead of an AES key a CAAM BLOB is
> passed to the kernel.  So, this crypto operation cannot be
> implemented in a userspace library and needs always help from the
> kernel.
> 
> Explicitly allow this use case.
> 
> Cc: Demi Marie Obenour <demiobenour@gmail.com>
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Fixes: 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography")
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  crypto/algif_skcipher.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index df20bdfe1f1f..035fed7db81f 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -32,6 +32,7 @@
>  #include <linux/mm.h>
>  #include <linux/module.h>
>  #include <linux/net.h>
> +#include <linux/string.h>
>  #include <net/sock.h>
>  
>  static int skcipher_sendmsg(struct socket *sock, struct msghdr *msg,
> @@ -309,7 +310,12 @@ static struct proto_ops algif_skcipher_ops_nokey = {
>  
>  static void *skcipher_bind(const char *name)
>  {
> -	return crypto_alloc_skcipher(name, 0, AF_ALG_CRYPTOAPI_MASK);
> +	u32 mask = AF_ALG_CRYPTOAPI_MASK;
> +
> +	if (strcmp(name, "cbc(paes)") == 0)
> +		mask = 0;
> +
> +	return crypto_alloc_skcipher(name, 0, mask);
>  }

Reviewed-by: Eric Biggers <ebiggers@kernel.org>

I'll note that this overrides userspace's request if they call bind()
with salg_feat=0 && salg_mask=CRYPTO_ALG_KERN_DRIVER_ONLY, expressing an
intent to exclude algorithms that have CRYPTO_ALG_KERN_DRIVER_ONLY set.

However, it doesn't make sense to request that with "cbc(paes)".  Also,
salg_feat and salg_mask seem to be de facto unused anyway: the only
supported flag has ever been CRYPTO_ALG_KERN_DRIVER_ONLY; alg_bind()
returns -EINVAL on anything else.  And it isn't even declared in a UAPI
header.  I think every use of AF_ALG I've seen uses salg_feat=0 &&
salg_mask=0, usually by leaving those fields default-zero-initialized.

So we could go a bit further and integrate this correctly with the
salg_feat and salg_mask.  But I wouldn't consider it essential.

- Eric

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Herbert Xu]

On Sun, Jul 26, 2026 at 09:27:16PM +0200, Richard Weinberger wrote:
> Commit 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography")
> breaks a special use case.  The cbc-paes-caam driver implements the
> algorithm cbc(paes), it offers a way to use AES in CBC mode with key
> material unknown to userspace.  Instead of an AES key a CAAM BLOB is
> passed to the kernel.  So, this crypto operation cannot be
> implemented in a userspace library and needs always help from the
> kernel.
> 
> Explicitly allow this use case.
> 
> Cc: Demi Marie Obenour <demiobenour@gmail.com>
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Fixes: 7524070f26d8 ("crypto: af_alg - Drop support for off-CPU cryptography")
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  crypto/algif_skcipher.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index df20bdfe1f1f..035fed7db81f 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -32,6 +32,7 @@
>  #include <linux/mm.h>
>  #include <linux/module.h>
>  #include <linux/net.h>
> +#include <linux/string.h>
>  #include <net/sock.h>
>  
>  static int skcipher_sendmsg(struct socket *sock, struct msghdr *msg,
> @@ -309,7 +310,12 @@ static struct proto_ops algif_skcipher_ops_nokey = {
>  
>  static void *skcipher_bind(const char *name)
>  {
> -	return crypto_alloc_skcipher(name, 0, AF_ALG_CRYPTOAPI_MASK);
> +	u32 mask = AF_ALG_CRYPTOAPI_MASK;
> +
> +	if (strcmp(name, "cbc(paes)") == 0)
> +		mask = 0;
> +
> +	return crypto_alloc_skcipher(name, 0, mask);
>  }
>  
>  static void skcipher_release(void *private)
> -- 
> 2.51.0

This does not apply against cryptodev.

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

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Richard Weinberger]

On Donnerstag, 30. Juli 2026 09:37 'Herbert Xu' via upstream wrote:
> This does not apply against cryptodev.

This is not material for next/7.3, this is for the current release cycle.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Herbert Xu]

On Thu, Jul 30, 2026 at 09:39:24AM +0200, Richard Weinberger wrote:
> On Donnerstag, 30. Juli 2026 09:37 'Herbert Xu' via upstream wrote:
> > This does not apply against cryptodev.
> 
> This is not material for next/7.3, this is for the current release cycle.

So what am I supposed to do for next? Allow cbc(paes) or deny it?

Because it's not in the white list.

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

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Richard Weinberger]

On Donnerstag, 30. Juli 2026 09:50 Herbert Xu wrote:
> On Thu, Jul 30, 2026 at 09:39:24AM +0200, Richard Weinberger wrote:
> > On Donnerstag, 30. Juli 2026 09:37 'Herbert Xu' via upstream wrote:
> > > This does not apply against cryptodev.
> > 
> > This is not material for next/7.3, this is for the current release cycle.
> 
> So what am I supposed to do for next? Allow cbc(paes) or deny it?
> 
> Because it's not in the white list.

Eric asked me to wait a bit before I send a patch for next:
https://lore.kernel.org/linux-crypto/20260727172004.GA877700@google.com/

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Herbert Xu]

On Thu, Jul 30, 2026 at 09:52:44AM +0200, Richard Weinberger wrote:
>
> Eric asked me to wait a bit before I send a patch for next:
> https://lore.kernel.org/linux-crypto/20260727172004.GA877700@google.com/

Well if I'm going to apply your patch I need to know what you want
this to do in next.

Are you happy to leave it as denied for next?

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

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Richard Weinberger]

On Donnerstag, 30. Juli 2026 09:54 Herbert Xu wrote:
> On Thu, Jul 30, 2026 at 09:52:44AM +0200, Richard Weinberger wrote:
> >
> > Eric asked me to wait a bit before I send a patch for next:
> > https://lore.kernel.org/linux-crypto/20260727172004.GA877700@google.com/
> 
> Well if I'm going to apply your patch I need to know what you want
> this to do in next.
> 
> Are you happy to leave it as denied for next?

No.
I'll happily send a patch for next just.

I just did what Eric told me and waited.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] crypto: af_alg: Allow cbc(paes)

[Eric Biggers]

On Thu, Jul 30, 2026 at 09:56:41AM +0200, Richard Weinberger wrote:
> On Donnerstag, 30. Juli 2026 09:54 Herbert Xu wrote:
> > On Thu, Jul 30, 2026 at 09:52:44AM +0200, Richard Weinberger wrote:
> > >
> > > Eric asked me to wait a bit before I send a patch for next:
> > > https://lore.kernel.org/linux-crypto/20260727172004.GA877700@google.com/
> > 
> > Well if I'm going to apply your patch I need to know what you want
> > this to do in next.
> > 
> > Are you happy to leave it as denied for next?
> 
> No.
> I'll happily send a patch for next just.
> 
> I just did what Eric told me and waited.
> 
> Thanks,
> //richard

I assumed it would be:
    
    1. patch crypto/master (for 7.2)
    2. merge crypto/master into cryptodev/master
    3. patch cryptodev/master to add an allowlist entry (for the
       algorithm name, not the mask which was already done by (1))

But Herbert maintains this code, so if he wants them to merge in another
order you'll need to do that.

I'm not sure why my email above is linked to.  That email was about the
implementation, not where/when the patches should go.

- Eric