[PATCH v2] crypto: arm64: use simd_skcipher_create() when registering aes internal algs

[PATCH v2] crypto: arm64: use simd_skcipher_create() when registering aes internal algs

[Liam Kearney]

The arm64 crypto drivers duplicate driver names when adding simd
variants, which after backported commit 27016f75f5ed ("crypto: api -
Disallow identical driver names"), causes an error that leads to the
aes algs not being installed. On weaker processors this results in hangs
due to falling back to SW crypto.
Use simd_skcipher_create() as it will properly namespace the new algs.
This issue does not exist in mainline/latest (and stable v6.1+) as the
driver has been refactored to remove the simd algs from this code path.

Fixes: 27016f75f5ed ("crypto: api - Disallow identical driver names")
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: stable@vger.kernel.org
Signed-off-by: Liam Kearney <liam.kearney@canonical.com>
---
v2:
 - No changes
---
 arch/arm64/crypto/aes-glue.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index aa13344a3a5e..af862e52a36b 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -1028,7 +1028,6 @@ static int __init aes_init(void)
 	struct simd_skcipher_alg *simd;
 	const char *basename;
 	const char *algname;
-	const char *drvname;
 	int err;
 	int i;
 
@@ -1045,9 +1044,8 @@ static int __init aes_init(void)
 			continue;
 
 		algname = aes_algs[i].base.cra_name + 2;
-		drvname = aes_algs[i].base.cra_driver_name + 2;
 		basename = aes_algs[i].base.cra_driver_name;
-		simd = simd_skcipher_create_compat(algname, drvname, basename);
+		simd = simd_skcipher_create(algname, basename);
 		err = PTR_ERR(simd);
 		if (IS_ERR(simd))
 			goto unregister_simds;
-- 
2.40.1

Re: [PATCH v2] crypto: arm64: use simd_skcipher_create() when registering aes internal algs

[Greg KH]

On Wed, May 22, 2024 at 01:58:37PM +1000, Liam Kearney wrote:
> The arm64 crypto drivers duplicate driver names when adding simd
> variants, which after backported commit 27016f75f5ed ("crypto: api -
> Disallow identical driver names"), causes an error that leads to the
> aes algs not being installed. On weaker processors this results in hangs
> due to falling back to SW crypto.

But that commit has already been reverted in the stable releases, right?

> Use simd_skcipher_create() as it will properly namespace the new algs.
> This issue does not exist in mainline/latest (and stable v6.1+) as the
> driver has been refactored to remove the simd algs from this code path.
> 
> Fixes: 27016f75f5ed ("crypto: api - Disallow identical driver names")
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: stable@vger.kernel.org
> Signed-off-by: Liam Kearney <liam.kearney@canonical.com>

What kernel tree(s) are you thinking this needs to go to?

thanks,

greg k-h

Re: [PATCH v2] crypto: arm64: use simd_skcipher_create() when registering aes internal algs

[Liam Kearney]

On Wed, May 22, 2024 at 06:18:54AM +0200, Greg KH wrote:
> On Wed, May 22, 2024 at 01:58:37PM +1000, Liam Kearney wrote:
> > The arm64 crypto drivers duplicate driver names when adding simd
> > variants, which after backported commit 27016f75f5ed ("crypto: api -
> > Disallow identical driver names"), causes an error that leads to the
> > aes algs not being installed. On weaker processors this results in hangs
> > due to falling back to SW crypto.
> 
> But that commit has already been reverted in the stable releases, right?
>

Ah yes, my apologies, I seem to have missed the revert. I've been away
for a few weeks, and this was just bumping the submission I made at the
beginning of May.

In that case, feel free to ignore this.

> > Use simd_skcipher_create() as it will properly namespace the new algs.
> > This issue does not exist in mainline/latest (and stable v6.1+) as the
> > driver has been refactored to remove the simd algs from this code path.
> > 
> > Fixes: 27016f75f5ed ("crypto: api - Disallow identical driver names")
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Liam Kearney <liam.kearney@canonical.com>
> 
> What kernel tree(s) are you thinking this needs to go to?
> 
> thanks,
> 
> greg k-h

It would be any pre 6.x, so 4.19, 5.4, 5.10, 5.15
But no need now since offending has been reverted.

(group replying for posterity)

Thanks,
Liam Kearney