Patchwork [v3,4/4] crypto: add CRYPTO_TFM_REQ_IV_SERIALIZE flag

login
register
mail settings
Submitter Stephan Mueller
Date Feb. 9, 2018, 10:04 p.m.
Message ID <3191772.GlMloJJ0Yf@positron.chronox.de>
Download mbox | patch
Permalink /patch/10210043/
State Changes Requested
Delegated to: Herbert Xu
Headers show

Comments

Stephan Mueller - Feb. 9, 2018, 10:04 p.m.
Crypto drivers may implement a streamlined serialization support for AIO
requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to
the crypto user. When the user decides that he wants to send multiple
AIO requests concurrently and wants the crypto driver to handle the
serialization, the caller has to set CRYPTO_TFM_REQ_IV_SERIALIZE to notify
the crypto driver.

Only when this flag is enabled, the crypto driver shall apply its
serialization logic for handling IV updates between requests. If this
flag is not provided, the serialization logic shall not be applied by
the driver as the caller decides that it does not need it (because no
parallel AIO requests are sent) or that it performs its own
serialization.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/algif_aead.c     | 15 ++++++++++++---
 crypto/algif_skcipher.c | 15 ++++++++++++---
 include/linux/crypto.h  |  1 +
 3 files changed, 25 insertions(+), 6 deletions(-)
Harsh Jain - Feb. 14, 2018, 5:50 a.m.
On 10-02-2018 03:34, Stephan Müller wrote:
> Crypto drivers may implement a streamlined serialization support for AIO
> requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to
> the crypto user. When the user decides that he wants to send multiple
> AIO requests concurrently and wants the crypto driver to handle the
> serialization, the caller has to set CRYPTO_TFM_REQ_IV_SERIALIZE to notify
> the crypto driver.
Will crypto_alloc_* API takes cares of this flag?. For Kernel Crypto user IV Synchronization logic depends on weather tfm allocated supports IV Serialisation or not.
>
> Only when this flag is enabled, the crypto driver shall apply its
> serialization logic for handling IV updates between requests. If this
> flag is not provided, the serialization logic shall not be applied by
> the driver as the caller decides that it does not need it (because no
> parallel AIO requests are sent) or that it performs its own
> serialization.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
>  crypto/algif_aead.c     | 15 ++++++++++++---
>  crypto/algif_skcipher.c | 15 ++++++++++++---
>  include/linux/crypto.h  |  1 +
>  3 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index 619147792cc9..5ec4dec6e6a1 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -66,13 +66,22 @@ static int aead_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>  {
>  	struct sock *sk = sock->sk;
>  	struct alg_sock *ask = alg_sk(sk);
> +	struct af_alg_ctx *ctx = ask->private;
>  	struct sock *psk = ask->parent;
>  	struct alg_sock *pask = alg_sk(psk);
>  	struct aead_tfm *aeadc = pask->private;
> -	struct crypto_aead *tfm = aeadc->aead;
> -	unsigned int ivsize = crypto_aead_ivsize(tfm);
> +	struct crypto_aead *aead = aeadc->aead;
> +	struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> +	unsigned int ivsize = crypto_aead_ivsize(aead);
> +	int ret = af_alg_sendmsg(sock, msg, size, ivsize);
> +
> +	if (ret < 0)
> +		return ret;
>  
> -	return af_alg_sendmsg(sock, msg, size, ivsize);
> +	if (ctx->iiv == ALG_IV_SERIAL_PROCESSING)
> +		tfm->crt_flags |= CRYPTO_TFM_REQ_IV_SERIALIZE;
> +
> +	return ret;
>  }
>  
>  static int crypto_aead_copy_sgl(struct crypto_skcipher *null_tfm,
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index cf27dda6a181..fd2a0ba32feb 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -43,12 +43,21 @@ static int skcipher_sendmsg(struct socket *sock, struct msghdr *msg,
>  {
>  	struct sock *sk = sock->sk;
>  	struct alg_sock *ask = alg_sk(sk);
> +	struct af_alg_ctx *ctx = ask->private;
>  	struct sock *psk = ask->parent;
>  	struct alg_sock *pask = alg_sk(psk);
> -	struct crypto_skcipher *tfm = pask->private;
> -	unsigned ivsize = crypto_skcipher_ivsize(tfm);
> +	struct crypto_skcipher *skc = pask->private;
> +	struct crypto_tfm *tfm = crypto_skcipher_tfm(skc);
> +	unsigned int ivsize = crypto_skcipher_ivsize(skc);
> +	int ret = af_alg_sendmsg(sock, msg, size, ivsize);
> +
> +	if (ret < 0)
> +		return ret;
>  
> -	return af_alg_sendmsg(sock, msg, size, ivsize);
> +	if (ctx->iiv == ALG_IV_SERIAL_PROCESSING)
> +		tfm->crt_flags |= CRYPTO_TFM_REQ_IV_SERIALIZE;
> +
> +	return ret;
>  }
>  
>  static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 4860aa2c9be4..4d54f2b30692 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -133,6 +133,7 @@
>  #define CRYPTO_TFM_REQ_WEAK_KEY		0x00000100
>  #define CRYPTO_TFM_REQ_MAY_SLEEP	0x00000200
>  #define CRYPTO_TFM_REQ_MAY_BACKLOG	0x00000400
> +#define CRYPTO_TFM_REQ_IV_SERIALIZE	0x00000800
>  #define CRYPTO_TFM_RES_WEAK_KEY		0x00100000
>  #define CRYPTO_TFM_RES_BAD_KEY_LEN   	0x00200000
>  #define CRYPTO_TFM_RES_BAD_KEY_SCHED 	0x00400000
Stephan Mueller - Feb. 14, 2018, 12:47 p.m.
Am Mittwoch, 14. Februar 2018, 06:50:38 CET schrieb Harsh Jain:

Hi Harsh,

> On 10-02-2018 03:34, Stephan Müller wrote:
> > Crypto drivers may implement a streamlined serialization support for AIO
> > requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to
> > the crypto user. When the user decides that he wants to send multiple
> > AIO requests concurrently and wants the crypto driver to handle the
> > serialization, the caller has to set CRYPTO_TFM_REQ_IV_SERIALIZE to notify
> > the crypto driver.
> 
> Will crypto_alloc_* API takes cares of this flag?. For Kernel Crypto user IV
> Synchronization logic depends on weather tfm allocated supports IV
> Serialisation or not.

The alloc API calls are not related to this flag. This flag is set in the 
request sent to the driver. If the driver sees this flag, it shall perform its 
serialization.

The idea is the following: the driver reports CRYPTO_ALG_SERIALIZES_IV_ACCESS 
if it can serialize requests. In this case, the higher level functions (like 
AF_ALG) would not serialize the request. Now, the higher level functions must 
inform the driver that its serialization function shall be performed which 
implemented with CRYPTO_TFM_REQ_IV_SERIALIZE.

Note, the higher level functions may decide that no serialization is necessary 
(e.g. in the case the inline IV handling is followed by AF_ALG). This implies 
that the CRYPTO_TFM_REQ_IV_SERIALIZE flag would not be set even though the 
driver is capable of serializing (and thus would report 
CRYPTO_ALG_SERIALIZES_IV_ACCESS).

Ciao
Stephan
Gilad Ben-Yossef - Feb. 18, 2018, 2:25 p.m.
On Sat, Feb 10, 2018 at 12:04 AM, Stephan Müller <smueller@chronox.de> wrote:
> Crypto drivers may implement a streamlined serialization support for AIO
> requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to
> the crypto user. When the user decides that he wants to send multiple
> AIO requests concurrently and wants the crypto driver to handle the
> serialization, the caller has to set CRYPTO_TFM_REQ_IV_SERIALIZE to notify
> the crypto driver.
>
> Only when this flag is enabled, the crypto driver shall apply its
> serialization logic for handling IV updates between requests. If this
> flag is not provided, the serialization logic shall not be applied by
> the driver as the caller decides that it does not need it (because no
> parallel AIO requests are sent) or that it performs its own
> serialization.

Tested and it is working with the ccree driver which supports IV serialization.

Tested-by: Gilad Ben-Yossef <gilad@benyossef.com>

Gilad
Stephan Mueller - Feb. 19, 2018, 12:24 p.m.
Am Sonntag, 18. Februar 2018, 15:25:27 CET schrieb Gilad Ben-Yossef:

Hi Gilad,

> On Sat, Feb 10, 2018 at 12:04 AM, Stephan Müller <smueller@chronox.de> 
wrote:
> > Crypto drivers may implement a streamlined serialization support for AIO
> > requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to
> > the crypto user. When the user decides that he wants to send multiple
> > AIO requests concurrently and wants the crypto driver to handle the
> > serialization, the caller has to set CRYPTO_TFM_REQ_IV_SERIALIZE to notify
> > the crypto driver.
> > 
> > Only when this flag is enabled, the crypto driver shall apply its
> > serialization logic for handling IV updates between requests. If this
> > flag is not provided, the serialization logic shall not be applied by
> > the driver as the caller decides that it does not need it (because no
> > parallel AIO requests are sent) or that it performs its own
> > serialization.
> 
> Tested and it is working with the ccree driver which supports IV
> serialization.
> 
> Tested-by: Gilad Ben-Yossef <gilad@benyossef.com>

Thank you.
> 
> Gilad



Ciao
Stephan

Patch

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 619147792cc9..5ec4dec6e6a1 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -66,13 +66,22 @@  static int aead_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
 {
 	struct sock *sk = sock->sk;
 	struct alg_sock *ask = alg_sk(sk);
+	struct af_alg_ctx *ctx = ask->private;
 	struct sock *psk = ask->parent;
 	struct alg_sock *pask = alg_sk(psk);
 	struct aead_tfm *aeadc = pask->private;
-	struct crypto_aead *tfm = aeadc->aead;
-	unsigned int ivsize = crypto_aead_ivsize(tfm);
+	struct crypto_aead *aead = aeadc->aead;
+	struct crypto_tfm *tfm = crypto_aead_tfm(aead);
+	unsigned int ivsize = crypto_aead_ivsize(aead);
+	int ret = af_alg_sendmsg(sock, msg, size, ivsize);
+
+	if (ret < 0)
+		return ret;
 
-	return af_alg_sendmsg(sock, msg, size, ivsize);
+	if (ctx->iiv == ALG_IV_SERIAL_PROCESSING)
+		tfm->crt_flags |= CRYPTO_TFM_REQ_IV_SERIALIZE;
+
+	return ret;
 }
 
 static int crypto_aead_copy_sgl(struct crypto_skcipher *null_tfm,
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index cf27dda6a181..fd2a0ba32feb 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -43,12 +43,21 @@  static int skcipher_sendmsg(struct socket *sock, struct msghdr *msg,
 {
 	struct sock *sk = sock->sk;
 	struct alg_sock *ask = alg_sk(sk);
+	struct af_alg_ctx *ctx = ask->private;
 	struct sock *psk = ask->parent;
 	struct alg_sock *pask = alg_sk(psk);
-	struct crypto_skcipher *tfm = pask->private;
-	unsigned ivsize = crypto_skcipher_ivsize(tfm);
+	struct crypto_skcipher *skc = pask->private;
+	struct crypto_tfm *tfm = crypto_skcipher_tfm(skc);
+	unsigned int ivsize = crypto_skcipher_ivsize(skc);
+	int ret = af_alg_sendmsg(sock, msg, size, ivsize);
+
+	if (ret < 0)
+		return ret;
 
-	return af_alg_sendmsg(sock, msg, size, ivsize);
+	if (ctx->iiv == ALG_IV_SERIAL_PROCESSING)
+		tfm->crt_flags |= CRYPTO_TFM_REQ_IV_SERIALIZE;
+
+	return ret;
 }
 
 static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 4860aa2c9be4..4d54f2b30692 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -133,6 +133,7 @@ 
 #define CRYPTO_TFM_REQ_WEAK_KEY		0x00000100
 #define CRYPTO_TFM_REQ_MAY_SLEEP	0x00000200
 #define CRYPTO_TFM_REQ_MAY_BACKLOG	0x00000400
+#define CRYPTO_TFM_REQ_IV_SERIALIZE	0x00000800
 #define CRYPTO_TFM_RES_WEAK_KEY		0x00100000
 #define CRYPTO_TFM_RES_BAD_KEY_LEN   	0x00200000
 #define CRYPTO_TFM_RES_BAD_KEY_SCHED 	0x00400000