diff mbox series

[09/30] crypto: talitos - remove unnecessary alignmask for ahashes

Message ID 20231022081100.123613-10-ebiggers@kernel.org (mailing list archive)
State Accepted
Delegated to: Herbert Xu
Headers show
Series crypto: reduce ahash API overhead | expand

Commit Message

Eric Biggers Oct. 22, 2023, 8:10 a.m. UTC
From: Eric Biggers <ebiggers@google.com>

The crypto API's support for alignmasks for ahash algorithms is nearly
useless, as its only effect is to cause the API to align the key and
result buffers.  The drivers that happen to be specifying an alignmask
for ahash rarely actually need it.  When they do, it's easily fixable,
especially considering that these buffers cannot be used for DMA.

In preparation for removing alignmask support from ahash, this patch
makes the talitos driver no longer use it.  This driver didn't actually
rely on it; it only writes to the result buffer in
common_nonsnoop_hash_unmap(), simply using memcpy().  And this driver's
"ahash_setkey()" function does not assume any alignment for the key
buffer.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/crypto/talitos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Christophe Leroy Nov. 29, 2023, 3 p.m. UTC | #1
Le 22/10/2023 à 10:10, Eric Biggers a écrit :
> From: Eric Biggers <ebiggers@google.com>
> 
> The crypto API's support for alignmasks for ahash algorithms is nearly
> useless, as its only effect is to cause the API to align the key and
> result buffers.  The drivers that happen to be specifying an alignmask
> for ahash rarely actually need it.  When they do, it's easily fixable,
> especially considering that these buffers cannot be used for DMA.
> 
> In preparation for removing alignmask support from ahash, this patch
> makes the talitos driver no longer use it.  This driver didn't actually
> rely on it; it only writes to the result buffer in
> common_nonsnoop_hash_unmap(), simply using memcpy().  And this driver's
> "ahash_setkey()" function does not assume any alignment for the key
> buffer.

I can't really see the link between your explanation and commit 
c9cca7034b34 ("crypto: talitos - Align SEC1 accesses to 32 bits 
boundaries.").

Was that commit wrong ?

Christophe


> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>   drivers/crypto/talitos.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 4ca4fbd227bce..e8f710d87007b 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -3252,21 +3252,21 @@ static struct talitos_crypto_alg *talitos_alg_alloc(struct device *dev,
>   		dev_err(dev, "unknown algorithm type %d\n", t_alg->algt.type);
>   		devm_kfree(dev, t_alg);
>   		return ERR_PTR(-EINVAL);
>   	}
>   
>   	alg->cra_module = THIS_MODULE;
>   	if (t_alg->algt.priority)
>   		alg->cra_priority = t_alg->algt.priority;
>   	else
>   		alg->cra_priority = TALITOS_CRA_PRIORITY;
> -	if (has_ftr_sec1(priv))
> +	if (has_ftr_sec1(priv) && t_alg->algt.type != CRYPTO_ALG_TYPE_AHASH)
>   		alg->cra_alignmask = 3;
>   	else
>   		alg->cra_alignmask = 0;
>   	alg->cra_ctxsize = sizeof(struct talitos_ctx);
>   	alg->cra_flags |= CRYPTO_ALG_KERN_DRIVER_ONLY;
>   
>   	t_alg->dev = dev;
>   
>   	return t_alg;
>   }
Eric Biggers Nov. 29, 2023, 8:46 p.m. UTC | #2
On Wed, Nov 29, 2023 at 03:00:48PM +0000, Christophe Leroy wrote:
> 
> 
> Le 22/10/2023 à 10:10, Eric Biggers a écrit :
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > The crypto API's support for alignmasks for ahash algorithms is nearly
> > useless, as its only effect is to cause the API to align the key and
> > result buffers.  The drivers that happen to be specifying an alignmask
> > for ahash rarely actually need it.  When they do, it's easily fixable,
> > especially considering that these buffers cannot be used for DMA.
> > 
> > In preparation for removing alignmask support from ahash, this patch
> > makes the talitos driver no longer use it.  This driver didn't actually
> > rely on it; it only writes to the result buffer in
> > common_nonsnoop_hash_unmap(), simply using memcpy().  And this driver's
> > "ahash_setkey()" function does not assume any alignment for the key
> > buffer.
> 
> I can't really see the link between your explanation and commit 
> c9cca7034b34 ("crypto: talitos - Align SEC1 accesses to 32 bits 
> boundaries.").
> 
> Was that commit wrong ?
> 
> Christophe

Commit c9cca7034b34 ("crypto: talitos - Align SEC1 accesses to 32 bits
boundaries.") added an alignmask to all algorithm types: skcipher, aead, and
ahash.  The commit did not explain why it was needed for each algorithm type,
and its true necessity may have varied by algorithm type.  In the case of
ahashes, the alignmask may have been needed originally, but commit 7a6eda5b8d9d
("crypto: talitos - fix hash result for VMAP_STACK") made it unnecessary.

- Eric
diff mbox series

Patch

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 4ca4fbd227bce..e8f710d87007b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -3252,21 +3252,21 @@  static struct talitos_crypto_alg *talitos_alg_alloc(struct device *dev,
 		dev_err(dev, "unknown algorithm type %d\n", t_alg->algt.type);
 		devm_kfree(dev, t_alg);
 		return ERR_PTR(-EINVAL);
 	}
 
 	alg->cra_module = THIS_MODULE;
 	if (t_alg->algt.priority)
 		alg->cra_priority = t_alg->algt.priority;
 	else
 		alg->cra_priority = TALITOS_CRA_PRIORITY;
-	if (has_ftr_sec1(priv))
+	if (has_ftr_sec1(priv) && t_alg->algt.type != CRYPTO_ALG_TYPE_AHASH)
 		alg->cra_alignmask = 3;
 	else
 		alg->cra_alignmask = 0;
 	alg->cra_ctxsize = sizeof(struct talitos_ctx);
 	alg->cra_flags |= CRYPTO_ALG_KERN_DRIVER_ONLY;
 
 	t_alg->dev = dev;
 
 	return t_alg;
 }