crypto: aes - Fix undesired override of some optimized AES modes
PATCH v3 1/1 crypto: aes - Fix undesired override of some optimized AES modes
The new library APIs for AES encryption modes were wired up to the traditional crypto API via crypto/aes.c. However, for now the kernel is still in a transitional state where various architectures still have architecture-optimized implementations of AES modes in arch/*/crypto/, wired up to the traditional crypto API only. Because of that, the crypto/aes.c algorithms were given a cra_priority of only 110 to prevent them from overriding arch/*/crypto/ in the traditional crypto API.
However, because of how the traditional crypto API works, the cra_priority trick doesn't work in cases where the relevant algorithm isn't directly implemented by arch/*/crypto/ but rather is provided by a template instance using other code in arch/*/crypto/.
For example, x86 doesn't have its own "ccm(aes)" but rather relies on the "ccm" template constructing it from the x86-optimized "ctr(aes)". The existence of the library-based "ccm(aes)" prevents that, even though its priority is lower than what the template would produce.
Thus, "ccm(aes)" ends up using the slower single-block AES code.
Therefore, skip wiring up the relevant library-based code to the traditional crypto API on architectures where this problem can occur, as determined by what exists in arch/*/crypto/ for each architecture.
This is ugly, but it's also temporary: these conditions will go away as architecture-optimized implementations of AES modes are migrated into the library. But until then, we need to prevent performance regressions by ensuring that the optimized code continues to be used.
---
This patch is intended to taken through libcrypto-fixes
v3: Also suppress xts(aes) on SPARC, and improved comments
v2: Fixed PowerPC config option, and resent as standalone patch
crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 47 insertions(+), 4 deletions(-)
crypto/aes.c +47 -4
@@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_cbc_decrypt, },#endif -#if IS_ENABLED (CONFIG_CRYPTO_CTS ) +/* +* Don't register library-based "cts(cbc(aes))" on architectures where +* it might block a "better" implementation from being instantiated via +* the "cts" template. These exclusions are temporary and will go away +* as the arch-optimized AES code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_CTS ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ +IS_ENABLED (CONFIG_ARM64 ) || \ +IS_ENABLED (CONFIG_PPC ) || \ +IS_ENABLED (CONFIG_S390 ) || \ +IS_ENABLED (CONFIG_SPARC )) { .base.cra_name = "cts(cbc(aes))", .base.cra_driver_name = "cts-cbc-aes-lib",
@@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_xctr_crypt, },#endif -#if IS_ENABLED (CONFIG_CRYPTO_XTS ) +/* +* Don't register library-based "xts(aes)" on architectures where it +* might block a "better" implementation from being instantiated via the +* "xts" template. This exclusion is temporary and will go away when +* the library AES-XTS is optimized for SPARC. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_XTS ) && !IS_ENABLED (CONFIG_SPARC ) { .base.cra_name = "xts(aes)", .base.cra_driver_name = "xts-aes-lib",
@@ -980,7 +997,20 @@ static __maybe_unused int crypto_aes_ccm_decrypt(struct aead_request *req) }static struct aead_alg aead_algs[] = { -#if IS_ENABLED(CONFIG_CRYPTO_GCM) +/* +* Don't register library-based "gcm(aes)" and "rfc4106(gcm(aes))" on +* architectures where they might block a "better" implementation from +* being instantiated via the "gcm" and "rfc4106" templates. These +* exclusions are temporary and will go away as the arch-optimized AES +* code is migrated into the library. +*/ +#if IS_ENABLED(CONFIG_CRYPTO_GCM) && \ + !(IS_ENABLED(CONFIG_ARM) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_RISCV) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC)) { .base.cra_name ="gcm(aes)" , .base.cra_driver_name ="gcm-aes-lib" ,
@@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = { .chunksize = AES_BLOCK_SIZE, },#endif /* CONFIG_CRYPTO_GCM */ -#if IS_ENABLED (CONFIG_CRYPTO_CCM ) +/* +* Don't register library-based "ccm(aes)" on architectures where it +* might block a "better" implementation from being instantiated via the +* "ccm" template. These exclusions are temporary and will go away as +* the arch-optimized AES code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_CCM ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ +IS_ENABLED (CONFIG_ARM64 ) || \ +IS_ENABLED (CONFIG_PPC ) || \ +IS_ENABLED (CONFIG_RISCV ) || \ +IS_ENABLED (CONFIG_S390 ) || \ +IS_ENABLED (CONFIG_SPARC ) || \ +IS_ENABLED (CONFIG_X86 )) { .base.cra_name = "ccm(aes)", .base.cra_driver_name = "ccm-aes-lib",
base-commit: 93f51579e7df248780214094418f205253383cc5
Signature · 1 line
2.55.0
Quoted 35 lines · Eric Biggers
The new library APIs for AES encryption modes were wired up to the traditional crypto API via
crypto/aes.c. However, for now the kernel is still in a transitional state where various architectures still have architecture-optimized implementations of AES modes inarch/*/crypto/, wired up to the traditional crypto API only. Because of that, thecrypto/aes.calgorithms were given acra_priorityof only 110 to prevent them from overridingarch/*/crypto/in the traditional crypto API.However, because of how the traditional crypto API works, the
cra_prioritytrick doesn't work in cases where the relevant algorithm isn't directly implemented byarch/*/crypto/but rather is provided by a template instance using other code inarch/*/crypto/.For example, x86 doesn't have its own "ccm(aes)" but rather relies on the "ccm" template constructing it from the x86-optimized "ctr(aes)". The existence of the library-based "ccm(aes)" prevents that, even though its priority is lower than what the template would produce.
Thus, "ccm(aes)" ends up using the slower single-block AES code.
Therefore, skip wiring up the relevant library-based code to the traditional crypto API on architectures where this problem can occur, as determined by what exists in
arch/*/crypto/for each architecture.This is ugly, but it's also temporary: these conditions will go away as architecture-optimized implementations of AES modes are migrated into the library. But until then, we need to prevent performance regressions by ensuring that the optimized code continues to be used.
Fixes 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using library")Fixes 8ca62072faa1 ("crypto: aes - Add GCM support using library")Fixes f70ad727d1d6 ("crypto: aes - Add CCM support using library")Fixes 94efa0c9fb36 ("crypto: aes - Add XTS support using library")Signed-off-by Eric Biggers <[email protected]>
Quoted 7 lines
---
This patch is intended to taken through libcrypto-fixes
v3: Also suppress xts(aes) on SPARC, and improved comments
v2: Fixed PowerPC config option, and resent as standalone patch
Quoted 94 lines
crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 47 insertions(+), 4 deletions(-)crypto/aes.c +3
-1@@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_cbc_decrypt, },#endif -#if IS_ENABLED (CONFIG_CRYPTO_CTS ) +/* +* Don't register library-based "cts(cbc(aes))" on architectures where +* it might block a "better" implementation from being instantiated via
crypto/aes.c +1
-0+* the "cts" template. These exclusions are temporary and will go away
crypto/aes.c +11
-1+* as the arch-optimized AES code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_CTS ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ +IS_ENABLED (CONFIG_ARM64 ) || \ +IS_ENABLED (CONFIG_PPC ) || \ +IS_ENABLED (CONFIG_S390 ) || \ +IS_ENABLED (CONFIG_SPARC )) { .base.cra_name = "cts(cbc(aes))", .base.cra_driver_name = "cts-cbc-aes-lib",@@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_xctr_crypt, },#endif -#if IS_ENABLED (CONFIG_CRYPTO_XTS ) +/* +* Don't register library-based "xts(aes)" on architectures where it +* might block a "better" implementation from being instantiated via the
crypto/aes.c +18
-1+* "xts" template. This exclusion is temporary and will go away when +* the library AES-XTS is optimized for SPARC. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_XTS ) && !IS_ENABLED (CONFIG_SPARC ) { .base.cra_name = "xts(aes)", .base.cra_driver_name = "xts-aes-lib",@@ -980,7 +997,20 @@ static __maybe_unused int crypto_aes_ccm_decrypt(struct aead_request *req) }static struct aead_alg aead_algs[] = { -#if IS_ENABLED(CONFIG_CRYPTO_GCM) +/* +* Don't register library-based "gcm(aes)" and "rfc4106(gcm(aes))" on +* architectures where they might block a "better" implementation from +* being instantiated via the "gcm" and "rfc4106" templates. These +* exclusions are temporary and will go away as the arch-optimized AES +* code is migrated into the library. +*/ +#if IS_ENABLED(CONFIG_CRYPTO_GCM) && \ + !(IS_ENABLED(CONFIG_ARM) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_RISCV) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC)) { .base.cra_name ="gcm(aes)" ,crypto/aes.c +14
-1.base.cra_driver_name = "gcm-aes-lib",@@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = { .chunksize = AES_BLOCK_SIZE, },#endif /* CONFIG_CRYPTO_GCM */ -#if IS_ENABLED (CONFIG_CRYPTO_CCM ) +/* +* Don't register library-based "ccm(aes)" on architectures where it +* might block a "better" implementation from being instantiated via the +* "ccm" template. These exclusions are temporary and will go away as +* the arch-optimized AES code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_CCM ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ +IS_ENABLED (CONFIG_ARM64 ) || \ +IS_ENABLED (CONFIG_PPC ) || \ +IS_ENABLED (CONFIG_RISCV ) || \ +IS_ENABLED (CONFIG_S390 ) || \ +IS_ENABLED (CONFIG_SPARC ) || \ +IS_ENABLED (CONFIG_X86 )) { .base.cra_name = "ccm(aes)", .base.cra_driver_name = "ccm-aes-lib",base-commit:
93f51579e7df248780214094418f205253383cc5Signature · 1 line
2.55.0
Quoted 44 lines · Eric Biggers
The new library APIs for AES encryption modes were wired up to the traditional crypto API via crypto/aes.c. However, for now the kernel is
still in a transitional state where various architectures still have architecture-optimized implementations of AES modes inarch/*/crypto/,
wired up to the traditional crypto API only. Because of that, thecrypto/aes.calgorithms were given acra_priorityof only 110 to prevent
them from overridingarch/*/crypto/in the traditional crypto API.However, because of how the traditional crypto API works, the
cra_prioritytrick doesn't work in cases where the relevant algorithm isn't directly implemented byarch/*/crypto/but rather is provided by a
template instance using other code inarch/*/crypto/.For example, x86 doesn't have its own "ccm(aes)" but rather relies on the "ccm" template constructing it from the x86-optimized "ctr(aes)". The existence of the library-based "ccm(aes)" prevents that, even though
its priority is lower than what the template would produce.Thus, "ccm(aes)" ends up using the slower single-block AES code.
Therefore, skip wiring up the relevant library-based code to the traditional crypto API on architectures where this problem can occur, as
determined by what exists inarch/*/crypto/for each architecture.This is ugly, but it's also temporary: these conditions will go away as
architecture-optimized implementations of AES modes are migrated into the library. But until then, we need to prevent performance regressions
by ensuring that the optimized code continues to be used.Fixes 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support usinglibrary")
Fixes 8ca62072faa1 ("crypto: aes - Add GCM support using library")Fixes f70ad727d1d6 ("crypto: aes - Add CCM support using library")Fixes 94efa0c9fb36 ("crypto: aes - Add XTS support using library")Signed-off-by Eric Biggers <[email protected]>
Quoted 8 lines
---
This patch is intended to taken through libcrypto-fixes
v3: Also suppress xts(aes) on SPARC, and improved comments
v2: Fixed PowerPC config option, and resent as standalone patch
Tested on a SPARC T7-1 (M7) on top of v7.3-rc5. xts(aes) resolves to xts(ecb-aes-sparc64) again. cryptsetup benchmark aes-xts goes from 152/147 MiB/s back to 429/404 (AES-128/AES-256), the 7.2 figures. CRYPTO_SELFTESTS_FULL passes and XTS matches OpenSSL.
Quoted 104 lines
crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++--- -
1 file changed, 47 insertions(+), 4 deletions(-)crypto/aes.c +2
-1@@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_cbc_decrypt, }, #endif -#if IS_ENABLED (CONFIG_CRYPTO_CTS ) +/* +* Don't register library-based "cts(cbc(aes))" on architectures where
crypto/aes.c +1
-0+* it might block a "better" implementation from being instantiated via
crypto/aes.c +1
-0+* the "cts" template. These exclusions are temporary and will go away
crypto/aes.c +1
-0+* as the arch-optimized AES code is migrated into the library.
crypto/aes.c +7
-0+*/ +#if IS_ENABLED (CONFIG_CRYPTO_CTS ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC)){
.base.cra_name = "cts(cbc(aes))", .base.cra_driver_name = "cts-cbc-aes-lib",crypto/aes.c +2
-1@@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_xctr_crypt, }, #endif -#if IS_ENABLED (CONFIG_CRYPTO_XTS ) +/* +* Don't register library-based "xts(aes)" on architectures where it
crypto/aes.c +1
-0+* might block a "better" implementation from being instantiated via the
crypto/aes.c +1
-0+* "xts" template. This exclusion is temporary and will go away when
crypto/aes.c +3
-0+* the library AES-XTS is optimized for SPARC. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_XTS ) && !IS_ENABLED (CONFIG_SPARC ){
.base.cra_name = "xts(aes)", .base.cra_driver_name = "xts-aes-lib",crypto/aes.c +0
-0@@ -980,7 +997,20 @@ static __maybe_unused int crypto_aes_ccm_decrypt(struct aead_request *req) }
static structaead_algaead_algs[] = {crypto/aes.c +2
-1-#if IS_ENABLED (CONFIG_CRYPTO_GCM ) +/* +* Don't register library-based "gcm(aes)" and "rfc4106(gcm(aes))" on
crypto/aes.c +1
-0+* architectures where they might block a "better" implementation from
crypto/aes.c +1
-0+* being instantiated via the "gcm" and "rfc4106" templates. These
crypto/aes.c +1
-0+* exclusions are temporary and will go away as the arch- optimized AES
crypto/aes.c +9
-0+* code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_GCM ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_RISCV) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC)){
.base.cra_name = "gcm(aes)", .base.cra_driver_name = "gcm-aes-lib",crypto/aes.c +2
-1@@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = { .chunksize = AES_BLOCK_SIZE, }, #endif /* CONFIG_CRYPTO_GCM */ -#if IS_ENABLED (CONFIG_CRYPTO_CCM ) +/* +* Don't register library-based "ccm(aes)" on architectures where it
crypto/aes.c +1
-0+* might block a "better" implementation from being instantiated via the
crypto/aes.c +1
-0+* "ccm" template. These exclusions are temporary and will go away as
crypto/aes.c +10
-0+* the arch-optimized AES code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_CCM ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_RISCV) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC) || \ + IS_ENABLED(CONFIG_X86)){
.base.cra_name = "ccm(aes)", .base.cra_driver_name = "ccm-aes-lib",base-commit:
93f51579e7df248780214094418f205253383cc5
Hi Stian,
Quoted 53 lines · Stian Halseth
Quoted 44 lines · Eric Biggers
The new library APIs for AES encryption modes were wired up to the traditional crypto API via crypto/aes.c. However, for now the kernel is
still in a transitional state where various architectures still have architecture-optimized implementations of AES modes inarch/*/crypto/,
wired up to the traditional crypto API only. Because of that, thecrypto/aes.calgorithms were given acra_priorityof only 110 to prevent
them from overridingarch/*/crypto/in the traditional crypto API.However, because of how the traditional crypto API works, the
cra_prioritytrick doesn't work in cases where the relevant algorithm isn't directly implemented byarch/*/crypto/but rather is provided by a
template instance using other code inarch/*/crypto/.For example, x86 doesn't have its own "ccm(aes)" but rather relies on the "ccm" template constructing it from the x86-optimized "ctr(aes)". The existence of the library-based "ccm(aes)" prevents that, even though
its priority is lower than what the template would produce.Thus, "ccm(aes)" ends up using the slower single-block AES code.
Therefore, skip wiring up the relevant library-based code to the traditional crypto API on architectures where this problem can occur, as
determined by what exists inarch/*/crypto/for each architecture.This is ugly, but it's also temporary: these conditions will go away as
architecture-optimized implementations of AES modes are migrated into the library. But until then, we need to prevent performance regressions
by ensuring that the optimized code continues to be used.Fixes 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support usinglibrary")
Fixes 8ca62072faa1 ("crypto: aes - Add GCM support using library")Fixes f70ad727d1d6 ("crypto: aes - Add CCM support using library")Fixes 94efa0c9fb36 ("crypto: aes - Add XTS support using library")Signed-off-by Eric Biggers <[email protected]>Quoted 8 lines
---
This patch is intended to taken through libcrypto-fixes
v3: Also suppress xts(aes) on SPARC, and improved comments
v2: Fixed PowerPC config option, and resent as standalone patch
Quoted 6 lines
Tested on a SPARC T7-1 (M7) on top of v7.3-rc5. xts(aes) resolves to xts(ecb-aes-sparc64) again. cryptsetup benchmark aes-xts goes from 152/147 MiB/s back to 429/404 (AES-128/AES-256), the 7.2 figures.
CRYPTO_SELFTESTS_FULLpasses and XTS matches OpenSSL.Tested-by Stian Halseth [email protected]
Very nice! Do you know which SPARC CPUs support these instructions?
Adrian
Quoted 104 lines
Quoted 104 lines
crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++--- -
1 file changed, 47 insertions(+), 4 deletions(-)crypto/aes.c +2
-1@@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_cbc_decrypt, }, #endif -#if IS_ENABLED (CONFIG_CRYPTO_CTS ) +/* +* Don't register library-based "cts(cbc(aes))" on architectures where
crypto/aes.c +1
-0+* it might block a "better" implementation from being instantiated via
crypto/aes.c +1
-0+* the "cts" template. These exclusions are temporary and will go away
crypto/aes.c +1
-0+* as the arch-optimized AES code is migrated into the library.
crypto/aes.c +7
-0+*/ +#if IS_ENABLED (CONFIG_CRYPTO_CTS ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC)){
.base.cra_name = "cts(cbc(aes))", .base.cra_driver_name = "cts-cbc-aes-lib",crypto/aes.c +2
-1@@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = { .decrypt = crypto_aes_xctr_crypt, }, #endif -#if IS_ENABLED (CONFIG_CRYPTO_XTS ) +/* +* Don't register library-based "xts(aes)" on architectures where it
crypto/aes.c +1
-0+* might block a "better" implementation from being instantiated via the
crypto/aes.c +1
-0+* "xts" template. This exclusion is temporary and will go away when
crypto/aes.c +3
-0+* the library AES-XTS is optimized for SPARC. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_XTS ) && !IS_ENABLED (CONFIG_SPARC ){
.base.cra_name = "xts(aes)", .base.cra_driver_name = "xts-aes-lib",crypto/aes.c +0
-0@@ -980,7 +997,20 @@ static __maybe_unused int crypto_aes_ccm_decrypt(struct aead_request *req) }
static structaead_algaead_algs[] = {crypto/aes.c +2
-1-#if IS_ENABLED (CONFIG_CRYPTO_GCM ) +/* +* Don't register library-based "gcm(aes)" and "rfc4106(gcm(aes))" on
crypto/aes.c +1
-0+* architectures where they might block a "better" implementation from
crypto/aes.c +1
-0+* being instantiated via the "gcm" and "rfc4106" templates. These
crypto/aes.c +1
-0+* exclusions are temporary and will go away as the arch- optimized AES
crypto/aes.c +9
-0+* code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_GCM ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_RISCV) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC)){
.base.cra_name = "gcm(aes)", .base.cra_driver_name = "gcm-aes-lib",crypto/aes.c +2
-1@@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = { .chunksize = AES_BLOCK_SIZE, }, #endif /* CONFIG_CRYPTO_GCM */ -#if IS_ENABLED (CONFIG_CRYPTO_CCM ) +/* +* Don't register library-based "ccm(aes)" on architectures where it
crypto/aes.c +1
-0+* might block a "better" implementation from being instantiated via the
crypto/aes.c +1
-0+* "ccm" template. These exclusions are temporary and will go away as
crypto/aes.c +10
-0+* the arch-optimized AES code is migrated into the library. +*/ +#if IS_ENABLED (CONFIG_CRYPTO_CCM ) && \ + !(IS_ENABLED (CONFIG_ARM ) || \ + IS_ENABLED(CONFIG_ARM64) || \ + IS_ENABLED(CONFIG_PPC) || \ + IS_ENABLED(CONFIG_RISCV) || \ + IS_ENABLED(CONFIG_S390) || \ + IS_ENABLED(CONFIG_SPARC) || \ + IS_ENABLED(CONFIG_X86)){
.base.cra_name = "ccm(aes)", .base.cra_driver_name = "ccm-aes-lib",base-commit:
93f51579e7df248780214094418f205253383cc5
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
Quoted 7 lines · John Paul Adrian Glaubitz
Very nice! Do you know which SPARC CPUs support these instructions?
Adrian
SPARC T4 or later.
The T2 and T3 has a separate crypto unit, but not supported here. Support was removed from the kernel in 6.14. Haven't tested it, as I don't have the hardware.
Also worth noting, it's only used when the firmware lists the machine description's hwcap-list and the CFR has its bit set.
I have no idea about Fujitsu's SPARC64 X family.
Hi Stian,
Quoted 10 lines · Stian Halseth
Quoted 7 lines · John Paul Adrian Glaubitz
Very nice! Do you know which SPARC CPUs support these instructions?
Adrian
SPARC T4 or later.
OK, thanks.
Quoted 3 lines
The T2 and T3 has a separate crypto unit, but not supported here. Support was removed from the kernel in 6.14. Haven't tested it, as I don't have the hardware.
Why was it removed? I'm not happy about such removals as long as the hardware is supported.
Quoted 2 lines
Also worth noting, it's only used when the firmware lists the machine description's hwcap-list and the CFR has its bit set.
Is that not the case by default?
Quoted 1 line
I have no idea about Fujitsu's SPARC64 X family.
I think SPARC64 X is not supported by the Linux kernel at all, is it?
Adrian
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
Quoted 9 lines · John Paul Adrian Glaubitz
Quoted 6 lines
The T2 and T3 has a separate crypto unit, but not supported here. Support was removed from the kernel in 6.14. Haven't tested it, as I
don't have the hardware.Why was it removed? I'm not happy about such removals as long as the hardware is supported.
Looks like there were issues that prompted the removal:
https://github.com/torvalds/linux/commit/9cda46babdfe
Quoted 6 lines
Quoted 4 lines
Also worth noting, it's only used when the firmware lists the machine
description's hwcap-list and the CFR has its bit set.Is that not the case by default?
Yes, on real hardware. Just mentioned to clarify that it doesn't cause problems on hardware that doesn't support it.
Quoted 4 lines
Quoted 1 line
I have no idea about Fujitsu's SPARC64 X family.
I think SPARC64 X is not supported by the Linux kernel at all, is it?
There some chip detection for it, but I've never tested, or heard about anyone actually using it.
sparc64: correctly recognize SPARC64-X chips
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29
cpu hw caps support for sparc64x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f
Hi,
Quoted 31 lines · Stian Halseth
Hi Adrian,
Quoted 9 lines · John Paul Adrian Glaubitz
Quoted 6 lines
The T2 and T3 has a separate crypto unit, but not supported here. Support was removed from the kernel in 6.14. Haven't tested it, as I
don't have the hardware.Why was it removed? I'm not happy about such removals as long as the hardware is supported.
Looks like there were issues that prompted the removal:
https://github.com/torvalds/linux/commit/9cda46babdfeQuoted 6 lines
Quoted 4 lines
Also worth noting, it's only used when the firmware lists the machine
description's hwcap-list and the CFR has its bit set.Is that not the case by default?
Yes, on real hardware. Just mentioned to clarify that it doesn't cause problems on hardware that doesn't support it.
Quoted 4 lines
Quoted 1 line
I have no idea about Fujitsu's SPARC64 X family.
-relocatable-kernelI think SPARC64 X is not supported by the Linux kernel at all, is it?
Quoted 9 lines
There some chip detection for it, but I've never tested, or heard about anyone actually using it.
sparc64: correctly recognize SPARC64-X chips
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29cpu hw caps support for sparc64x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f
I while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much missing in the linux kernel, and some hardware manuals available online gave me the missing pieces. I have an experimental kernel running now with gentoo user-land installed. The box has been running stable for a while now during normal load (building stuff with emerge). I'm doing some final cleanup work with the patches now before I send them out.
Some details below:
m3000 ~ # cat /proc/cpuinfo
cpu : Fujitsu SPARC64 VII / VII+
fpu : Fujitsu SPARC64 VII integrated FPU
pmu : (null)
prom : OBP 4.33.5.d 2012/07/18 06:55
type : sun4u
ncpus probed : 8
ncpus active : 8
D$ parity tl1 : 0
I$ parity tl1 : 0
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus Cpu0ClkTck : 0000000000000000
Cpu1ClkTck : 0000000000000000
Cpu2ClkTck : 0000000000000000
Cpu3ClkTck : 0000000000000000
Cpu4ClkTck : 0000000000000000
Cpu5ClkTck : 0000000000000000
Cpu6ClkTck : 0000000000000000
Cpu7ClkTck : 0000000000000000
MMU Type : Fujitsu SPARC64 VII (experimental)
MMU PGSZs : 8K,64K,512K,4MB
State:
CPU0: online
CPU1: online
CPU2: online
CPU3: online
CPU4: online
CPU5: online
CPU6: online
CPU7: online
m3000 ~ # uname -a
Linux m3000 7.3.0-rc1-m3000-rfc5 #2 SMP Sun Sep 20 18:04:02 CEST 2026 sparc64 sun4u Fujitsu SPARC64 VII / VII+ GNU/Linux
m3000 ~ # cat /proc/meminfo
MemTotal: 16595712 kB MemFree: 16337304 kB MemAvailable: 16440248 kB
Regards
Magnus
Hi Magnus,
Quoted 10 lines · Magnus Lindholm
I while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much
missing in the linux kernel, and some hardware manuals available online
gave me the missing pieces. I have an experimental kernel running now with gentoo user-land installed. The box has been running stable for a while
now during normal load (building stuff with emerge). I'm doing some final
cleanup work with the patches now before I send them out.
Very nice, sounds promising!
/Stian
Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes
In reply to Magnus LindholmQuoted 87 lines · Magnus Lindholm
Hi,
Quoted 31 lines · Stian Halseth
Hi Adrian,
Quoted 9 lines · John Paul Adrian Glaubitz
Quoted 6 lines
The T2 and T3 has a separate crypto unit, but not supported here. Support was removed from the kernel in 6.14. Haven't tested it, as I
don't have the hardware.Why was it removed? I'm not happy about such removals as long as the hardware is supported.
Looks like there were issues that prompted the removal:
https://github.com/torvalds/linux/commit/9cda46babdfeQuoted 6 lines
Quoted 4 lines
Also worth noting, it's only used when the firmware lists the machine
description's hwcap-list and the CFR has its bit set.Is that not the case by default?
Yes, on real hardware. Just mentioned to clarify that it doesn't cause problems on hardware that doesn't support it.
Quoted 4 lines
Quoted 1 line
I have no idea about Fujitsu's SPARC64 X family.
-relocatable-kernelI think SPARC64 X is not supported by the Linux kernel at all, is it?
Quoted 9 lines
There some chip detection for it, but I've never tested, or heard about anyone actually using it.
sparc64: correctly recognize SPARC64-X chips
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29cpu hw caps support for sparc64x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17fI while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much missing in the linux kernel, and some hardware manuals available online gave me the missing pieces. I have an experimental kernel running now with gentoo user-land installed. The box has been running stable for a while now during normal load (building stuff with emerge). I'm doing some final cleanup work with the patches now before I send them out.
Some details below:
m3000 ~ # cat
/proc/cpuinfo
cpu : Fujitsu SPARC64 VII / VII+
fpu : Fujitsu SPARC64 VII integrated FPU
pmu : (null)
prom : OBP 4.33.5.d 2012/07/18 06:55
type : sun4u
ncpus probed : 8
ncpus active : 8
D$ parity tl1 : 0
I$ parity tl1 : 0
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus Cpu0ClkTck : 0000000000000000
Cpu1ClkTck : 0000000000000000
Cpu2ClkTck : 0000000000000000
Cpu3ClkTck : 0000000000000000
Cpu4ClkTck : 0000000000000000
Cpu5ClkTck : 0000000000000000
Cpu6ClkTck : 0000000000000000
Cpu7ClkTck : 0000000000000000
MMU Type : Fujitsu SPARC64 VII (experimental)
MMU PGSZs : 8K,64K,512K,4MB
State:
CPU0: online
CPU1: online
CPU2: online
CPU3: online
CPU4: online
CPU5: online
CPU6: online
CPU7: online
m3000 ~ # uname -a
Linux m3000 7.3.0-rc1-m3000-rfc5 #2 SMP Sun Sep 20 18:04:02 CEST 2026 sparc64 sun4u Fujitsu SPARC64 VII / VII+ GNU/Linux
m3000 ~ # cat/proc/meminfo
Quoted 3 lines
MemTotal: 16595712 kB MemFree: 16337304 kB MemAvailable: 16440248 kB
Dennis Clarke (CC'ed) might be very interested to hear about this. He wanted to install Debian on his M3000 back in 2022 [1]. Maybe Dennis can help testing patches.
Adrian
Quoted 1 line
[1] https://lists.debian.org/debian-sparc/2022/05/msg00003.html
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes
Hi Adrian,
Quoted 93 lines · John Paul Adrian Glaubitz
Quoted 87 lines · Magnus Lindholm
Hi,
Quoted 31 lines · Stian Halseth
Hi Adrian,
Quoted 9 lines · John Paul Adrian Glaubitz
Quoted 6 lines
The T2 and T3 has a separate crypto unit, but not supported here. Support was removed from the kernel in 6.14. Haven't tested it, as I
don't have the hardware.Why was it removed? I'm not happy about such removals as long as the hardware is supported.
Looks like there were issues that prompted the removal:
https://github.com/torvalds/linux/commit/9cda46babdfeQuoted 6 lines
Quoted 4 lines
Also worth noting, it's only used when the firmware lists the machine
description's hwcap-list and the CFR has its bit set.Is that not the case by default?
Yes, on real hardware. Just mentioned to clarify that it doesn't cause problems on hardware that doesn't support it.
Quoted 4 lines
Quoted 1 line
I have no idea about Fujitsu's SPARC64 X family.
-relocatable-kernelI think SPARC64 X is not supported by the Linux kernel at all, is it?
Quoted 9 lines
There some chip detection for it, but I've never tested, or heard about anyone actually using it.
sparc64: correctly recognize SPARC64-X chips
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29cpu hw caps support for sparc64x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17fI while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much missing in the linux kernel, and some hardware manuals available online gave me the missing pieces. I have an experimental kernel running now with gentoo user-land installed. The box has been running stable for a while now during normal load (building stuff with emerge). I'm doing some final cleanup work with the patches now before I send them out.
Some details below:
m3000 ~ # cat
/proc/cpuinfo
cpu : Fujitsu SPARC64 VII / VII+
fpu : Fujitsu SPARC64 VII integrated FPU
pmu : (null)
prom : OBP 4.33.5.d 2012/07/18 06:55
type : sun4u
ncpus probed : 8
ncpus active : 8
D$ parity tl1 : 0
I$ parity tl1 : 0
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus Cpu0ClkTck : 0000000000000000
Cpu1ClkTck : 0000000000000000
Cpu2ClkTck : 0000000000000000
Cpu3ClkTck : 0000000000000000
Cpu4ClkTck : 0000000000000000
Cpu5ClkTck : 0000000000000000
Cpu6ClkTck : 0000000000000000
Cpu7ClkTck : 0000000000000000
MMU Type : Fujitsu SPARC64 VII (experimental)
MMU PGSZs : 8K,64K,512K,4MB
State:
CPU0: online
CPU1: online
CPU2: online
CPU3: online
CPU4: online
CPU5: online
CPU6: online
CPU7: online
m3000 ~ # uname -a
Linux m3000 7.3.0-rc1-m3000-rfc5 #2 SMP Sun Sep 20 18:04:02 CEST 2026 sparc64 sun4u Fujitsu SPARC64 VII / VII+ GNU/Linux
m3000 ~ # cat/proc/meminfoQuoted 3 lines
MemTotal: 16595712 kB MemFree: 16337304 kB MemAvailable: 16440248 kB
Quoted 8 lines
Dennis Clarke (CC'ed) might be very interested to hear about this. He wanted to install Debian on his M3000 back in 2022 [1]. Maybe Dennis can help testing patches.
Adrian
Quoted 1 line
[1] https://lists.debian.org/debian-sparc/2022/05/msg00003.html
Thanks for picking this up, I would very much appreciate some help with testing. Getting in touch with people who have access to M3000 hardware
and are willing to help out in testing would be great.
I'm gonna go over the patches and do some cleaning up, I hope I'll have something
to send out by the weekend.
Magnus
Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes
Quoted 7 lines · Magnus Lindholm
Hi Adrian,
Quoted 3 lines · John Paul Adrian Glaubitz
Quoted 1 line · Magnus Lindholm
Hi,
.
.
. <snip>
.
.
Quoted 10 lines
Thanks for picking this up, I would very much appreciate some help with testing. Getting in touch with people who have access to M3000 hardware
and are willing to help out in testing would be great.I'm gonna go over the patches and do some cleaning up, I hope I'll have something
to send out by the weekend.Magnus
Sadly I tossed that machine into the trash a few months ago. Full of memory and SAS disks and gone out the door to the recycle centre.
I still have a SPARC S7-2 server and a few Netra units.
Signature · 4 lines
-- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes
Hi Dennis,
Quoted 5 lines · Dennis Clarke
Sadly I tossed that machine into the trash a few months ago. Full of memory and SAS disks and gone out the door to the recycle centre.
Oooh no! Missed that by only a few months then? But I understand, My M3000 came close to meeting the same faith a few times, but for some reason I've kept it in the hopes of resurrecting it again some day.
Quoted 3 lines
I still have a SPARC S7-2 server and a few Netra units.
The S7-2 is a really nice machine.
Magnus
Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes
Quoted 5 lines · Magnus Lindholm
Hi Dennis,
Quoted 2 lines · Dennis Clarke
Quoted 8 lines
Quoted 3 lines
Sadly I tossed that machine into the trash a few months ago. Full of memory and SAS disks and gone out the door to the recycle centre.
Oooh no! Missed that by only a few months then? But I understand, My M3000 came close to meeting the same faith a few times, but for some reason I've kept it in the hopes of resurrecting it again some day.
Trust me, you would not even want to pay for the shipping. However it was a fine unit that could *only* run Solaris 10. I do regret that I do not have a decent Fujitsu SPARC64 handy. That can be easily fixed if I also install a proper 220 volt battery backup unit for an M4000.
Quoted 5 lines
Quoted 3 lines
I still have a SPARC S7-2 server and a few Netra units.
The S7-2 is a really nice machine.
It is very loud. Really a screamer. Fantastic cooling.
Has anyone given a try with these snapshots? :
https://cdimage.debian.org/cdimage/ports/snapshots/2026-06-12/
I can spin up a logical hardware domain ( LDOM ) with reasonable stuff and a dedicated 10G network port. See what works or does not. I have not had good success on the S7 with Linux.
Signature · 4 lines
-- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Hi Stian,
Quoted 10 lines · Stian Halseth
Quoted 2 lines
I think SPARC64 X is not supported by the Linux kernel at all, is it?
There some chip detection for it, but I've never tested, or heard about anyone actually using it.
sparc64: correctly recognize SPARC64-X chips
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29cpu hw caps support for sparc64x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f
There is one guy on the debian-sparc mailing list who got one.
Not sure if he's still active these days. I'll try to reach out.
Adrian
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Eric Biggers
AppliedQuoted 37 lines · Eric Biggers
The new library APIs for AES encryption modes were wired up to the traditional crypto API via
crypto/aes.c. However, for now the kernel is still in a transitional state where various architectures still have architecture-optimized implementations of AES modes inarch/*/crypto/, wired up to the traditional crypto API only. Because of that, thecrypto/aes.calgorithms were given acra_priorityof only 110 to prevent them from overridingarch/*/crypto/in the traditional crypto API.However, because of how the traditional crypto API works, the
cra_prioritytrick doesn't work in cases where the relevant algorithm isn't directly implemented byarch/*/crypto/but rather is provided by a template instance using other code inarch/*/crypto/.For example, x86 doesn't have its own "ccm(aes)" but rather relies on the "ccm" template constructing it from the x86-optimized "ctr(aes)". The existence of the library-based "ccm(aes)" prevents that, even though its priority is lower than what the template would produce.
Thus, "ccm(aes)" ends up using the slower single-block AES code.
Therefore, skip wiring up the relevant library-based code to the traditional crypto API on architectures where this problem can occur, as determined by what exists in
arch/*/crypto/for each architecture.This is ugly, but it's also temporary: these conditions will go away as architecture-optimized implementations of AES modes are migrated into the library. But until then, we need to prevent performance regressions by ensuring that the optimized code continues to be used.
Fixes 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using library")Fixes 8ca62072faa1 ("crypto: aes - Add GCM support using library")Fixes f70ad727d1d6 ("crypto: aes - Add CCM support using library")Fixes 94efa0c9fb36 ("crypto: aes - Add XTS support using library")Signed-off-by Eric Biggers <[email protected]>---
Quoted 7 lines
This patch is intended to taken through libcrypto-fixes
v3: Also suppress xts(aes) on SPARC, and improved comments
v2: Fixed PowerPC config option, and resent as standalone patchcrypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 47 insertions(+), 4 deletions(-)
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-fixes
- Eric