crypto: s390/paes - Fix module aliases

Commit Message

Herbert Xu Sept. 18, 2024, 4:01 a.m. UTC

On Tue, Sep 17, 2024 at 11:54:30AM +0200, Ingo Franzki wrote:
>
> I used 'make defconfig' on s390x, so nothing special: 

Thanks, it turns out to be an existing bug but it just happens
to have worked.

---8<---
The paes_s390 module didn't declare the correct aliases for the
algorithms that it registered.  Instead it declared an alias for
the non-existent paes algorithm.

The Crypto API will eventually try to load the paes algorithm, to
construct the cbc(paes) instance.  But because the module does not
actually contain a "paes" algorithm, this will fail.

Previously this failure was hidden and the the cbc(paes) lookup will
be retried.  This was fixed recently, thus exposing the buggy alias
in paes_s390.

Replace the bogus paes alias with aliases for the actual algorithms.

Reported-by: Ingo Franzki <[e-mail]>
Fixes: e7a4142b35ce ("crypto: api - Fix generic algorithm self-test races")
Signed-off-by: Herbert Xu <[e-mail]>

Comments

Ingo Franzki Sept. 18, 2024, 6:50 a.m. UTC | #1

On 18.09.2024 06:01, Herbert Xu wrote:
> On Tue, Sep 17, 2024 at 11:54:30AM +0200, Ingo Franzki wrote:
>>
>> I used 'make defconfig' on s390x, so nothing special: 
> 
> Thanks, it turns out to be an existing bug but it just happens
> to have worked.
> 
> ---8<---
> The paes_s390 module didn't declare the correct aliases for the
> algorithms that it registered.  Instead it declared an alias for
> the non-existent paes algorithm.
> 
> The Crypto API will eventually try to load the paes algorithm, to
> construct the cbc(paes) instance.  But because the module does not
> actually contain a "paes" algorithm, this will fail.
> 
> Previously this failure was hidden and the the cbc(paes) lookup will
> be retried.  This was fixed recently, thus exposing the buggy alias
> in paes_s390.
> 
> Replace the bogus paes alias with aliases for the actual algorithms.
> 
> Reported-by: Ingo Franzki <[e-mail]>
> Fixes: e7a4142b35ce ("crypto: api - Fix generic algorithm self-test races")
> Signed-off-by: Herbert Xu <[e-mail]>
> 
> diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
> index 99ea3f12c5d2..b8d9f385555d 100644
> --- a/arch/s390/crypto/paes_s390.c
> +++ b/arch/s390/crypto/paes_s390.c
> @@ -802,7 +802,10 @@ static int __init paes_s390_init(void)
>  module_init(paes_s390_init);
>  module_exit(paes_s390_fini);
>  
> -MODULE_ALIAS_CRYPTO("paes");
> +MODULE_ALIAS_CRYPTO("ecb(paes)");
> +MODULE_ALIAS_CRYPTO("cbc(paes)");
> +MODULE_ALIAS_CRYPTO("ctr(paes)");
> +MODULE_ALIAS_CRYPTO("xts(paes)");
>  
>  MODULE_DESCRIPTION("Rijndael (AES) Cipher Algorithm with protected keys");
>  MODULE_LICENSE("GPL");

I can confirm that this solves the problem.
Thanks for identifying this!

Tested-by: Ingo Franzki <[e-mail]>
Reviewed-by: Ingo Franzki <[e-mail]>

Trough which tree should we carry this patch forward? 
Through the crypto tree or the s390 tree? 
@Heiko @Harald @Herbert opinions?

Herbert Xu Sept. 18, 2024, 8:20 a.m. UTC | #2

On Wed, Sep 18, 2024 at 08:50:29AM +0200, Ingo Franzki wrote:
>
> Trough which tree should we carry this patch forward? 
> Through the crypto tree or the s390 tree? 
> @Heiko @Harald @Herbert opinions?

I can take this and then push it to Linus.

Thanks,

Patch

diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
index 99ea3f12c5d2..b8d9f385555d 100644
--- a/arch/s390/crypto/paes_s390.c
+++ b/arch/s390/crypto/paes_s390.c
@@ -802,7 +802,10 @@  static int __init paes_s390_init(void)
 module_init(paes_s390_init);
 module_exit(paes_s390_fini);
 
-MODULE_ALIAS_CRYPTO("paes");
+MODULE_ALIAS_CRYPTO("ecb(paes)");
+MODULE_ALIAS_CRYPTO("cbc(paes)");
+MODULE_ALIAS_CRYPTO("ctr(paes)");
+MODULE_ALIAS_CRYPTO("xts(paes)");
 
 MODULE_DESCRIPTION("Rijndael (AES) Cipher Algorithm with protected keys");
 MODULE_LICENSE("GPL");