crypto: Remove arch-optimized des and des3_ede code

DES and 3DES are cryptographically obsolete and insecure by modern standards. Continuing to maintain highly specific, complex assembly and glue code for them, especially when the code isn't testable in QEMU (s390 and sparc), is unnecessary and risky.

Thus, this series removes the architecture-optimized DES and 3DES code for the three architectures that had it: s390, sparc, and x86.

This series is targeting cryptodev/master.

Eric Biggers (3):
crypto: s390 - Remove des and des3_ede code
crypto: sparc - Remove des and des3_ede code
crypto: x86 - Remove des and des3_ede code

 arch/s390/configs/debug_defconfig |   1 -
 arch/s390/configs/defconfig       |   1 -
 arch/s390/crypto/Kconfig          |  16 -
 arch/s390/crypto/Makefile         |   1 -
 arch/s390/crypto/des_s390.c       | 502 ------------------
 arch/sparc/crypto/Kconfig         |  14 -
 arch/sparc/crypto/Makefile        |   2 -
 arch/sparc/crypto/des_asm.S       | 419 ---------------
 arch/sparc/crypto/des_glue.c      | 482 -----------------
 arch/x86/crypto/Kconfig           |  14 -
 arch/x86/crypto/Makefile          |   3 -
 arch/x86/crypto/des3_ede-asm_64.S | 831 ------------------------------
 arch/x86/crypto/des3_ede_glue.c   | 391 --------------
 13 files changed, 2677 deletions(-)
 delete mode 100644 arch/s390/crypto/des_s390.c
 delete mode 100644 arch/sparc/crypto/des_asm.S
 delete mode 100644 arch/sparc/crypto/des_glue.c
 delete mode 100644 arch/x86/crypto/des3_ede-asm_64.S
 delete mode 100644 arch/x86/crypto/des3_ede_glue.c

base-commit: f9bbd547cfb98b1c5e535aab9b0671a2ff22453a

2.53.0

Since DES and Triple DES are obsolete, there is very little point in maintining architecture-optimized code for them. Remove it.

---
 arch/s390/configs/debug_defconfig |   1 -
 arch/s390/configs/defconfig       |   1 -
 arch/s390/crypto/Kconfig          |  16 -
 arch/s390/crypto/Makefile         |   1 -
 arch/s390/crypto/des_s390.c       | 502 ------------------------------
 5 files changed, 521 deletions(-)
 delete mode 100644 arch/s390/crypto/des_s390.c

index 98fd0a2f51c6..74e4bb236623 100644
@@ -809,11 +809,10 @@ CONFIG_CRYPTO_USER_API_HASH=m
 CONFIG_CRYPTO_USER_API_SKCIPHER=m
 CONFIG_CRYPTO_USER_API_RNG=m
 CONFIG_CRYPTO_USER_API_AEAD=m
 CONFIG_CRYPTO_GHASH_S390=m
 CONFIG_CRYPTO_AES_S390=m
-CONFIG_CRYPTO_DES_S390=m
 CONFIG_CRYPTO_HMAC_S390=m
 CONFIG_ZCRYPT=m
 CONFIG_PKEY=m
 CONFIG_PKEY_CCA=m
 CONFIG_PKEY_EP11=m

index 0f4cedcab3ce..5cb7b715ba6b 100644
@@ -794,11 +794,10 @@ CONFIG_CRYPTO_USER_API_HASH=m
 CONFIG_CRYPTO_USER_API_SKCIPHER=m
 CONFIG_CRYPTO_USER_API_RNG=m
 CONFIG_CRYPTO_USER_API_AEAD=m
 CONFIG_CRYPTO_GHASH_S390=m
 CONFIG_CRYPTO_AES_S390=m
-CONFIG_CRYPTO_DES_S390=m
 CONFIG_CRYPTO_HMAC_S390=m
 CONFIG_ZCRYPT=m
 CONFIG_PKEY=m
 CONFIG_PKEY_CCA=m
 CONFIG_PKEY_EP11=m

index 79a2d0034258..4218d21f1f00 100644
@@ -29,26 +29,10 @@ config CRYPTO_AES_S390
 
 	  As of z196 the CTR mode is hardware accelerated for all AES
 	  key sizes and XTS mode is hardware accelerated for 256 and
 	  512 bit keys.
 
-config CRYPTO_DES_S390
-	tristate "Ciphers: DES and Triple DES EDE, modes: ECB, CBC, CTR"
-	select CRYPTO_ALGAPI
-	select CRYPTO_SKCIPHER
-	select CRYPTO_LIB_DES
-	help
-	  Block ciphers: DES (FIPS 46-2) cipher algorithm
-	  Block ciphers: Triple DES EDE (FIPS 46-3) cipher algorithm
-	  Length-preserving ciphers: DES with ECB, CBC, and CTR modes
-	  Length-preserving ciphers: Triple DES EDED with ECB, CBC, and CTR modes
-
-	  Architecture: s390
-
-	  As of z990 the ECB and CBC mode are hardware accelerated.
-	  As of z196 the CTR mode is hardware accelerated.
-
 config CRYPTO_HMAC_S390
 	tristate "Keyed-hash message authentication code: HMAC"
 	select CRYPTO_HASH
 	help
 	  s390 specific HMAC hardware support for SHA224, SHA256, SHA384 and

index 387a229e1038..bf5e061ebf13 100644
@@ -1,11 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 # Cryptographic API
 #
 
-obj-$(CONFIG_CRYPTO_DES_S390) += des_s390.o
 obj-$(CONFIG_CRYPTO_AES_S390) += aes_s390.o
 obj-$(CONFIG_CRYPTO_PAES_S390) += paes_s390.o
 obj-$(CONFIG_S390_PRNG) += prng.o
 obj-$(CONFIG_CRYPTO_GHASH_S390) += ghash_s390.o
 obj-$(CONFIG_CRYPTO_HMAC_S390) += hmac_s390.o

2.53.0

Hi Eric,

Are there plans to completely remove des/3des in-kernel crypto support from the kernel or is it just the arch-specific code, that is removed?

In fact there are still customers using des/3des (unbelievable!), but the valid question is, do they also using the in-kernel crypto for their workloads. I'll try to figure that out. Unfortunately, Harald is a few days off and I need to discuss the removal with him as well.

Regarding the testing: in our CI we're running all in-kernel crypto modules every night, including des/3des. So there is some test coverage.

Regarding qemu: we're currently investigating if we can provide qemu-support for the s390 crypto instructions, but, to be honest, des/3des was not on our top-priority list until now... ;)

We'll come back to you in a week or so. I hope, that's ok...

Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
[email protected]

Just the arch-specific code for now. It will just make these like RC4 and MD4 which are still implemented for compatibility reasons but only with generic C code. Someday (years from now) we should remove all of these entirely, but for now the best we can hope for is simplifying the implementations to just the generic C code.

- Eric

Wouldn't it actually make sense to keep the old crypto code so we get additional coverage for QEMU's emulation of crypto instructions?

Adrian

 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Hi Adrian,

For qemu test coverage on s390, I would prefer the libica [1] test cases, which covers mostly all functions codes of the CPACF instructions.

If you want to use the kernel code for testing in addition, you may stay with a kernel version before the code removal.

[1] https://github.com/opencryptoki/libica

Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
[email protected]

Yes, the kernel is not a test suite for QEMU. QEMU tests belong in the QEMU repository itself or in other projects. We don't keep code around in the kernel purely to exercise functionality in QEMU.

- Eric

Since DES and Triple DES are obsolete, there is very little point in maintining architecture-optimized code for them. Remove it.

---
 arch/sparc/crypto/Kconfig    |  14 -
 arch/sparc/crypto/Makefile   |   2 -
 arch/sparc/crypto/des_asm.S  | 419 ------------------------------
 arch/sparc/crypto/des_glue.c | 482 -----------------------------------
 4 files changed, 917 deletions(-)
 delete mode 100644 arch/sparc/crypto/des_asm.S
 delete mode 100644 arch/sparc/crypto/des_glue.c

index c1932ce46c7f..8db3f6eea5dc 100644
@@ -1,23 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 
 menu "Accelerated Cryptographic Algorithms for CPU (sparc64)"
 
-config CRYPTO_DES_SPARC64
-	tristate "Ciphers: DES and Triple DES EDE, modes: ECB/CBC"
-	depends on SPARC64
-	select CRYPTO_ALGAPI
-	select CRYPTO_LIB_DES
-	select CRYPTO_SKCIPHER
-	help
-	  Block cipher: DES (FIPS 46-2) cipher algorithm
-	  Block cipher: Triple DES EDE (FIPS 46-3) cipher algorithm
-	  Length-preserving ciphers: DES with ECB and CBC modes
-	  Length-preserving ciphers: Tripe DES EDE with ECB and CBC modes
-
-	  Architecture: sparc64
-
 config CRYPTO_AES_SPARC64
 	tristate "Ciphers: AES, modes: ECB, CBC, CTR"
 	depends on SPARC64
 	select CRYPTO_LIB_AES
 	select CRYPTO_SKCIPHER

index cdf9f4b3efbb..ab4a7765babf 100644
@@ -2,11 +2,9 @@
 #
 # Arch-specific CryptoAPI modules.
 #
 
 obj-$(CONFIG_CRYPTO_AES_SPARC64) += aes-sparc64.o
-obj-$(CONFIG_CRYPTO_DES_SPARC64) += des-sparc64.o
 obj-$(CONFIG_CRYPTO_CAMELLIA_SPARC64) += camellia-sparc64.o
 
 aes-sparc64-y := aes_glue.o
-des-sparc64-y := des_asm.o des_glue.o
 camellia-sparc64-y := camellia_asm.o camellia_glue.o

2.53.0

Since DES and Triple DES are obsolete, there is very little point in maintining architecture-optimized code for them. Remove it.

---
 arch/x86/crypto/Kconfig           |  14 -
 arch/x86/crypto/Makefile          |   3 -
 arch/x86/crypto/des3_ede-asm_64.S | 831 ------------------------------
 arch/x86/crypto/des3_ede_glue.c   | 391 --------------
 4 files changed, 1239 deletions(-)
 delete mode 100644 arch/x86/crypto/des3_ede-asm_64.S
 delete mode 100644 arch/x86/crypto/des3_ede_glue.c

index 7fb2319a0916..03c5cdfe8eb0 100644
@@ -97,24 +97,10 @@ config CRYPTO_CAST6_AVX_X86_64
 	  Architecture: x86_64 using:
 	  - AVX (Advanced Vector Extensions)
 
 	  Processes eight blocks in parallel.
 
-config CRYPTO_DES3_EDE_X86_64
-	tristate "Ciphers: Triple DES EDE with modes: ECB, CBC"
-	depends on 64BIT
-	select CRYPTO_SKCIPHER
-	select CRYPTO_LIB_DES
-	imply CRYPTO_CTR
-	help
-	  Block cipher: Triple DES EDE (FIPS 46-3) cipher algorithm
-	  Length-preserving ciphers: Triple DES EDE with ECB and CBC modes
-
-	  Architecture: x86_64
-
-	  Processes one or three blocks in parallel.
-
 config CRYPTO_SERPENT_SSE2_X86_64
 	tristate "Ciphers: Serpent with modes: ECB, CBC (SSE2)"
 	depends on 64BIT
 	select CRYPTO_SKCIPHER
 	select CRYPTO_SERPENT

index b21ad0978c52..cb07260f7f4f 100644
@@ -18,13 +18,10 @@ serpent-sse2-x86_64-y := serpent-sse2-x86_64-asm_64.o serpent_sse2_glue.o
 obj-$(CONFIG_CRYPTO_SERPENT_AVX_X86_64) += serpent-avx-x86_64.o
 serpent-avx-x86_64-y := serpent-avx-x86_64-asm_64.o serpent_avx_glue.o
 obj-$(CONFIG_CRYPTO_SERPENT_AVX2_X86_64) += serpent-avx2.o
 serpent-avx2-y := serpent-avx2-asm_64.o serpent_avx2_glue.o
 
-obj-$(CONFIG_CRYPTO_DES3_EDE_X86_64) += des3_ede-x86_64.o
-des3_ede-x86_64-y := des3_ede-asm_64.o des3_ede_glue.o
-
 obj-$(CONFIG_CRYPTO_CAMELLIA_X86_64) += camellia-x86_64.o
 camellia-x86_64-y := camellia-x86_64-asm_64.o camellia_glue.o
 obj-$(CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64) += camellia-aesni-avx-x86_64.o
 camellia-aesni-avx-x86_64-y := camellia-aesni-avx-asm_64.o camellia_aesni_avx_glue.o
 obj-$(CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64) += camellia-aesni-avx2.o

2.53.0

We're working on getting crypto instructions added to QEMU though.

Adrian

 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

In general that's good of course, but DES and 3DES? Really? Why is effort going into these obsolete algorithms at all?

- Eric

I would suggest focusing your efforts on more modern algorithms, like AES (which has its own SPARC instructions and code), and not worrying about DES and 3DES. It's just not worth it anymore. Note that I'm proposing dropping the x86 DES and 3DES code as well.

- Eric

Hi,

If there's dedicated instructions, we need to emulate them, even if the kernel stops using them, because userspace might still use them. The alternative is implementing them as a trap in the kernel that delegates to the crypto subsystem, and nobody wants that. O_O

I wonder if it would make sense to split between "crypto" and "offload" subsystems, so the "crypto" side can focus on a small number of contemporary algorithms and give them simple, easily auditable interfaces, and move all the complexity of asynchronous request processing in offload hardware over to the "offloading" side. The userspace API would also move to the "offloading" subsystem.

This would give the offloading subsystem a bit more flexibility in API design as well, so we could maybe represent offload capabilities in network or storage hardware as well, or allow userspace to set policies or find an optimized routing, without compromising security in the crypto subsystem.

However, even from the "crypto" perspective I believe that we can't get around support for asynchronous offload devices, because of mobile devices. I suspect no one would be building dedicated silicon for asynchronous AES into mobile CPUs if that wasn't worth it somehow -- so if such a device is present, we want to use it as much as possible, because the expectation is that while the difference in performance compared to the CPU is hardly noticeable, the difference in battery lifetime is (that's why dropping async request support from fscrypt makes it largely useless on mobile).

Most of the other offload scenarios are already handled bypassing the crypto subsystem: the network stack has its own offloading mechanism, while nx-gzip is a regular device driver and does not even register an acomp algorithm (even though that would be really cool for zram/zswap, and would benefit dozens (dozens!) of users).

A lot of the resistance to changes in the crypto subsystem comes from the long tail, either hardware that is somewhat seldom, or built for some special purpose where the crypto APIs are already a limiting factor, and further consolidation towards standard PCs is making the situation worse.

I can certainly see that the complexity in the API that would be needed to support all the interesting use cases is somewhat undesirable, hence the idea to split off generic transforms and allow the interfaces there to become more expressive (on-device dmabufs, in-place operation, device-side contexts, device-side queues, device-to-device transfer offload, ...).

The current state where these use cases are technically inside the scope of the crypto subsystem, but deemed out of scope by the crypto subsystem leaves them in a kind of limbo, and that is very frustrating.

I don't know if it will be worth it to dedicate a weekend to implementing nx-gzip support as an acomp module, or nx-aes support as acrypt, or if that work would be rejected or removed in half a year, and I'm sure maintainers of ports to older hardware feel similar.

Simon

While I appreciate the sudden eagerness to implement these instructions in QEMU after them not being supported for 15 years, I'd suggest that the instructions for the more modern algorithms should be prioritized.

lib/crypto/ and crypto/ already largely provides that distinction, no?

The kernel already has perfectly good support for inline storage encryption in the block layer. See Documentation/block/inline-encryption.rst. It's a completely different model from non-inline crypto engines. Trying to create some common abstraction is not going to succeed.

They do it anyway. It's a checkbox feature. I.e. the purpose is for it to be advertised on a list of features.

I'm quite familiar with how fscrypt is being used on mobile, thanks. Most people do use hardware offload with fscrypt, but it is *inline* hardware offload. That remains fully supported via blk-crypto and is unrelated to the crypto API. The rest just use the CPU.

I've only ever heard of one case almost a decade ago where someone intentionally used a non-inline offload engine with fscrypt. And I even recently showed that on the same line of SoCs that was being used in that case, it is no longer worth it, if it ever was.

Every other case has just been someone using one by mistake and getting their performance tanked or encountering driver bugs as a result.

Anyway, this seems very off-topic for this thread, which is about whether the architecture-optimized DES and 3DES code should be removed.

- Eric

...

Often, h/w crypto IP blocks are part of the SoC-specific authenticated/confidential boot chain, which is anchored in the mask ROM. Nobody wants to put software implementations of RSA and AES in there, and so it offloads the crypto processing to a h/w block instead. Since the h/w block is there, it can be used by the OS too, but that doesn't mean doing so makes any sense.

Only h/w accelerators with multiple internal queues can generally keep up with the CPUs and network/block I/O in a meaningful manner, and those are quite rare IME.

Hi Adrian

I am about to implement some of the cpacf instructions for qemu.
Eric and others complained about being unable to test the s390 in-kernel crypto implementations and thus I am about to improve this. As soon as my patch series is in a good shape I'll forward it to you. As of now my main focus is on AES (ECB, CTR, CBC, XTS) with and without protected key support.
Please let us not do this work twice - so get in contact with me and Holger about possible s390 specific crypto implementations for qemu.

Harald Freudenberger

Hi Harald,

Thanks a lot for working on this. I would be interested to see the first patches as these might help us to work on the implementation for SPARC.

Adrian

 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

All applied. Thanks.

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt