linux.git/drivers/crypto/Kconfig, branch v6.16 Linux kernel source tree s390/crypto: Select crypto engine in Kconfig when PAES is chosen 2025-06-02T08:49:52+00:00 Harald Freudenberger freude@linux.ibm.com 2025-05-28T08:30:32+00:00 34a149a02b5f1eb788d1f79252fccc7028e3856b The s390 PAES crypto algorithm has a dependency to the crypto engine. So enable the crypto engine via SELECT CRYPTO_ENGINE in drivers/crypto/Kconfig when CRYPTO_PAES_S390 is chosen. Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support") Reported-by: Thomas Huth <thuth@redhat.com> Closes: https://lore.kernel.org/linux-s390/f958f869-8da3-48d9-a118-f3cf9a9ea75c@redhat.com/ Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250528083032.224430-1-freude@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> 
The s390 PAES crypto algorithm has a dependency to the
crypto engine. So enable the crypto engine via
SELECT CRYPTO_ENGINE in drivers/crypto/Kconfig when
CRYPTO_PAES_S390 is chosen.

Fixes: 6cd87cb5ef6c ("s390/crypto: Rework protected key AES for true asynch support")
Reported-by: Thomas Huth <thuth@redhat.com>
Closes: https://lore.kernel.org/linux-s390/f958f869-8da3-48d9-a118-f3cf9a9ea75c@redhat.com/
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20250528083032.224430-1-freude@linux.ibm.com
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
crypto: cavium/zip - Remove driver 2025-04-07T05:22:25+00:00 Herbert Xu herbert@gondor.apana.org.au 2025-03-19T12:31:47+00:00 d462ae23bb3ca84eb82a53a671c915dc093eab43 Remove cavium/zip as it is obsolete and stands in the way of acomp API work. If this is ever resurrected, please turn it into an acomp driver. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Remove cavium/zip as it is obsolete and stands in the way of
acomp API work.  If this is ever resurrected, please turn it
into an acomp driver.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support 2025-02-09T10:08:11+00:00 Christian Marangi ansuelsmth@gmail.com 2025-01-14T12:36:36+00:00 9739f5f93b7806a684713ba42e6ed2d1df7c8100 Add support for the Inside Secure SafeXcel EIP-93 Crypto Engine used on Mediatek MT7621 SoC and new Airoha SoC. EIP-93 IP supports AES/DES/3DES ciphers in ECB/CBC and CTR modes as well as authenc(HMAC(x), cipher(y)) using HMAC MD5, SHA1, SHA224 and SHA256. EIP-93 provide regs to signal support for specific chipers and the driver dynamically register only the supported one by the chip. Signed-off-by: Richard van Schagen <vschagen@icloud.com> Co-developed-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Add support for the Inside Secure SafeXcel EIP-93 Crypto Engine used on
Mediatek MT7621 SoC and new Airoha SoC.

EIP-93 IP supports AES/DES/3DES ciphers in ECB/CBC and CTR modes as well as
authenc(HMAC(x), cipher(y)) using HMAC MD5, SHA1, SHA224 and SHA256.

EIP-93 provide regs to signal support for specific chipers and the
driver dynamically register only the supported one by the chip.

Signed-off-by: Richard van Schagen <vschagen@icloud.com>
Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: n2 - remove Niagara2 SPU driver 2024-12-14T09:21:43+00:00 Eric Biggers ebiggers@google.com 2024-12-07T19:05:02+00:00 9cda46babdfed9804214b1eecb4219786d91c9c7 Remove the driver for the Stream Processing Unit (SPU) on the Niagara 2. Removing this driver allows removing the support for physical address walks in skcipher_walk. That is a misfeature that is used only by this driver and increases the overhead of the crypto API for everyone else. There is little evidence that anyone cares about this driver. The Niagara 2, a.k.a. the UltraSPARC T2, is a server CPU released in 2007. The SPU is also present on the SPARC T3, released in 2010. However, the SPU went away in SPARC T4, released in 2012, which replaced it with proper cryptographic instructions instead. These newer instructions are supported by the kernel in arch/sparc/crypto/. This driver was completely broken from (at least) 2015 to 2022, from commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") to commit 76a4e8745935 ("crypto: n2 - add missing hash statesize"), since its probe function always returned an error before registering any algorithms. Though, even with that obvious issue fixed, it is unclear whether the driver now works correctly. E.g., there are no indications that anyone has run the self-tests recently. One bug report for this driver in 2017 (https://lore.kernel.org/r/nycvar.YFH.7.76.1712110214220.28416@n3.vanv.qr) complained that it crashed the kernel while being loaded. The reporter didn't seem to care about the functionality of the driver, but rather just the fact that loading it crashed the kernel. In fact not until 2022 was the driver fixed to maybe actually register its algorithms with the crypto API. The 2022 fix does have a Reported-by and Tested-by, but that may similarly have been just about making the error messages go away as opposed to someone actually wanting to use the driver. As such, it seems appropriate to retire this driver in mainline. Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Remove the driver for the Stream Processing Unit (SPU) on the Niagara 2.

Removing this driver allows removing the support for physical address
walks in skcipher_walk.  That is a misfeature that is used only by this
driver and increases the overhead of the crypto API for everyone else.

There is little evidence that anyone cares about this driver.  The
Niagara 2, a.k.a. the UltraSPARC T2, is a server CPU released in
2007.  The SPU is also present on the SPARC T3, released in 2010.
However, the SPU went away in SPARC T4, released in 2012, which replaced
it with proper cryptographic instructions instead.  These newer
instructions are supported by the kernel in arch/sparc/crypto/.

This driver was completely broken from (at least) 2015 to 2022, from
commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") to
commit 76a4e8745935 ("crypto: n2 - add missing hash statesize"), since
its probe function always returned an error before registering any
algorithms.  Though, even with that obvious issue fixed, it is unclear
whether the driver now works correctly.  E.g., there are no indications
that anyone has run the self-tests recently.

One bug report for this driver in 2017
(https://lore.kernel.org/r/nycvar.YFH.7.76.1712110214220.28416@n3.vanv.qr)
complained that it crashed the kernel while being loaded.  The reporter
didn't seem to care about the functionality of the driver, but rather
just the fact that loading it crashed the kernel.  In fact not until
2022 was the driver fixed to maybe actually register its algorithms with
the crypto API.  The 2022 fix does have a Reported-by and Tested-by, but
that may similarly have been just about making the error messages go
away as opposed to someone actually wanting to use the driver.

As such, it seems appropriate to retire this driver in mainline.

Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
s390/pkey: Add new pkey handler module pkey-uv 2024-10-29T10:17:18+00:00 Harald Freudenberger freude@linux.ibm.com 2024-10-25T10:34:32+00:00 73dfc79c6b046af252a5d1b7b34a2f1454d6f7f3 This new pkey handler module supports the conversion of Ultravisor retrievable secrets to protected keys. The new module pkey-uv.ko is able to retrieve and verify protected keys backed up by the Ultravisor layer which is only available within protected execution environment. The module is only automatically loaded if there is the UV CPU feature flagged as available. Additionally on module init there is a check for protected execution environment and for UV supporting retrievable secrets. Also if the kernel is not running as a protected execution guest, the module unloads itself with errno ENODEV. The pkey UV module currently supports these Ultravisor secrets and is able to retrieve a protected key for these UV secret types: - UV_SECRET_AES_128 - UV_SECRET_AES_192 - UV_SECRET_AES_256 - UV_SECRET_AES_XTS_128 - UV_SECRET_AES_XTS_256 - UV_SECRET_HMAC_SHA_256 - UV_SECRET_HMAC_SHA_512 - UV_SECRET_ECDSA_P256 - UV_SECRET_ECDSA_P384 - UV_SECRET_ECDSA_P521 - UV_SECRET_ECDSA_ED25519 - UV_SECRET_ECDSA_ED448 Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> 
This new pkey handler module supports the conversion of
Ultravisor retrievable secrets to protected keys.
The new module pkey-uv.ko is able to retrieve and verify
protected keys backed up by the Ultravisor layer which is
only available within protected execution environment.

The module is only automatically loaded if there is the
UV CPU feature flagged as available. Additionally on module
init there is a check for protected execution environment
and for UV supporting retrievable secrets. Also if the kernel
is not running as a protected execution guest, the module
unloads itself with errno ENODEV.

The pkey UV module currently supports these Ultravisor
secrets and is able to retrieve a protected key for these
UV secret types:
  - UV_SECRET_AES_128
  - UV_SECRET_AES_192
  - UV_SECRET_AES_256
  - UV_SECRET_AES_XTS_128
  - UV_SECRET_AES_XTS_256
  - UV_SECRET_HMAC_SHA_256
  - UV_SECRET_HMAC_SHA_512
  - UV_SECRET_ECDSA_P256
  - UV_SECRET_ECDSA_P384
  - UV_SECRET_ECDSA_P521
  - UV_SECRET_ECDSA_ED25519
  - UV_SECRET_ECDSA_ED448

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
s390/pkey: Introduce pkey base with handler registry and handler modules 2024-08-29T20:56:34+00:00 Harald Freudenberger freude@linux.ibm.com 2024-08-22T09:32:19+00:00 8fcc231ce3bea12b78bb94b280cdc03cff342435 Introduce pkey base kernel code with a simple pkey handler registry. Regroup the pkey code into these kernel modules: - pkey is the pkey api supporting the ioctls, sysfs and in-kernel api. Also the pkey base code which offers the handler registry and handler wrapping invocation functions is integrated there. This module is automatically loaded in via CPU feature if the MSA feature is available. - pkey-cca is the CCA related handler code kernel module a offering CCA specific implementation for pkey. This module is loaded in via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available. - pkey-ep11 is the EP11 related handler code kernel module offering an EP11 specific implementation for pkey. This module is loaded in via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available. - pkey-pckmo is the PCKMO related handler code kernel module. This module is loaded in via CPU feature if the MSA feature is available, but on init a check for availability of the pckmo instruction is performed. The handler modules register via a pkey_handler struct at the pkey base code and the pkey customer (that is currently the pkey api code fetches a handler via pkey handler registry functions and calls the unified handler functions via the pkey base handler functions. As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules get independent from each other and it becomes possible to write new handlers which offer another kind of implementation without implicit dependencies to other handler implementations and/or kernel device drivers. For each of these 4 kernel modules there is an individual Kconfig entry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEY CCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler and CONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handler modules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt api of the zcrypt device driver. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> 
Introduce pkey base kernel code with a simple pkey handler registry.
Regroup the pkey code into these kernel modules:
- pkey is the pkey api supporting the ioctls, sysfs and in-kernel api.
  Also the pkey base code which offers the handler registry and
  handler wrapping invocation functions is integrated there. This
  module is automatically loaded in via CPU feature if the MSA feature
  is available.
- pkey-cca is the CCA related handler code kernel module a offering
  CCA specific implementation for pkey. This module is loaded in
  via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.
- pkey-ep11 is the EP11 related handler code kernel module offering an
  EP11 specific implementation for pkey. This module is loaded in via
  MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available.
- pkey-pckmo is the PCKMO related handler code kernel module. This
  module is loaded in via CPU feature if the MSA feature is available,
  but on init a check for availability of the pckmo instruction is
  performed.

The handler modules register via a pkey_handler struct at the pkey
base code and the pkey customer (that is currently the pkey api code
fetches a handler via pkey handler registry functions and calls the
unified handler functions via the pkey base handler functions.

As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules get
independent from each other and it becomes possible to write new
handlers which offer another kind of implementation without implicit
dependencies to other handler implementations and/or kernel device
drivers.

For each of these 4 kernel modules there is an individual Kconfig
entry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEY
CCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler and
CONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handler
modules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt api
of the zcrypt device driver.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Merge tag 'v6.10-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 2024-05-13T21:53:05+00:00 Linus Torvalds torvalds@linux-foundation.org 2024-05-13T21:32:22+00:00 84c7d76b5ab6a52e1b3d8101b9f910c128dca396 Pull crypto updates from Herbert Xu: "API: - Remove crypto stats interface Algorithms: - Add faster AES-XTS on modern x86_64 CPUs - Forbid curves with order less than 224 bits in ecc (FIPS 186-5) - Add ECDSA NIST P521 Drivers: - Expose otp zone in atmel - Add dh fallback for primes > 4K in qat - Add interface for live migration in qat - Use dma for aes requests in starfive - Add full DMA support for stm32mpx in stm32 - Add Tegra Security Engine driver Others: - Introduce scope-based x509_certificate allocation" * tag 'v6.10-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (123 commits) crypto: atmel-sha204a - provide the otp content crypto: atmel-sha204a - add reading from otp zone crypto: atmel-i2c - rename read function crypto: atmel-i2c - add missing arg description crypto: iaa - Use kmemdup() instead of kzalloc() and memcpy() crypto: sahara - use 'time_left' variable with wait_for_completion_timeout() crypto: api - use 'time_left' variable with wait_for_completion_killable_timeout() crypto: caam - i.MX8ULP donot have CAAM page0 access crypto: caam - init-clk based on caam-page0-access crypto: starfive - Use fallback for unaligned dma access crypto: starfive - Do not free stack buffer crypto: starfive - Skip unneeded fallback allocation crypto: starfive - Skip dma setup for zeroed message crypto: hisilicon/sec2 - fix for register offset crypto: hisilicon/debugfs - mask the unnecessary info from the dump crypto: qat - specify firmware files for 402xx crypto: x86/aes-gcm - simplify GCM hash subkey derivation crypto: x86/aes-gcm - delete unused GCM assembly code crypto: x86/aes-xts - simplify loop in xts_crypt_slowpath() hwrng: stm32 - repair clock handling ... 
Pull crypto updates from Herbert Xu:
 "API:
   - Remove crypto stats interface

  Algorithms:
   - Add faster AES-XTS on modern x86_64 CPUs
   - Forbid curves with order less than 224 bits in ecc (FIPS 186-5)
   - Add ECDSA NIST P521

  Drivers:
   - Expose otp zone in atmel
   - Add dh fallback for primes > 4K in qat
   - Add interface for live migration in qat
   - Use dma for aes requests in starfive
   - Add full DMA support for stm32mpx in stm32
   - Add Tegra Security Engine driver

  Others:
   - Introduce scope-based x509_certificate allocation"

* tag 'v6.10-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (123 commits)
  crypto: atmel-sha204a - provide the otp content
  crypto: atmel-sha204a - add reading from otp zone
  crypto: atmel-i2c - rename read function
  crypto: atmel-i2c - add missing arg description
  crypto: iaa - Use kmemdup() instead of kzalloc() and memcpy()
  crypto: sahara - use 'time_left' variable with wait_for_completion_timeout()
  crypto: api - use 'time_left' variable with wait_for_completion_killable_timeout()
  crypto: caam - i.MX8ULP donot have CAAM page0 access
  crypto: caam - init-clk based on caam-page0-access
  crypto: starfive - Use fallback for unaligned dma access
  crypto: starfive - Do not free stack buffer
  crypto: starfive - Skip unneeded fallback allocation
  crypto: starfive - Skip dma setup for zeroed message
  crypto: hisilicon/sec2 - fix for register offset
  crypto: hisilicon/debugfs - mask the unnecessary info from the dump
  crypto: qat - specify firmware files for 402xx
  crypto: x86/aes-gcm - simplify GCM hash subkey derivation
  crypto: x86/aes-gcm - delete unused GCM assembly code
  crypto: x86/aes-xts - simplify loop in xts_crypt_slowpath()
  hwrng: stm32 - repair clock handling
  ...
crypto: tegra - Add Tegra Security Engine driver 2024-04-12T07:07:51+00:00 Akhil R akhilrajeev@nvidia.com 2024-04-03T10:00:37+00:00 0880bb3b00c855fc244b7177ffdaafef4d0aa1e0 Add support for Tegra Security Engine which can accelerate various crypto algorithms. The Engine has two separate instances within for AES and HASH algorithms respectively. The driver registers two crypto engines - one for AES and another for HASH algorithms and these operate independently and both uses the host1x bus. Additionally, it provides hardware-assisted key protection for up to 15 symmetric keys which it can use for the cipher operations. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Add support for Tegra Security Engine which can accelerate various
crypto algorithms. The Engine has two separate instances within for
AES and HASH algorithms respectively.

The driver registers two crypto engines - one for AES and another for
HASH algorithms and these operate independently and both uses the host1x
bus. Additionally, it provides  hardware-assisted key protection for up
to 15 symmetric keys which it can use for the cipher operations.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
s390/ap: rename ap debug configuration option 2024-04-09T15:29:56+00:00 Holger Dengler dengler@linux.ibm.com 2024-02-27T15:49:33+00:00 b3840c8bfc27c1e8dc3953d6a27960ae390d5d80 The configuration option ZCRYPT_DEBUG is used only in ap queue code, so rename it to AP_DEBUG. It also no longer depends on ZCRYPT but on AP. While at it, also update the help text. Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> 
The configuration option ZCRYPT_DEBUG is used only in ap queue code,
so rename it to AP_DEBUG. It also no longer depends on ZCRYPT but on
AP. While at it, also update the help text.

Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
s390/ap: modularize ap bus 2024-04-09T15:29:56+00:00 Holger Dengler dengler@linux.ibm.com 2024-02-19T17:10:19+00:00 123760841a2e5977d4e97f86999b3784df58801d There is no hard requirement to have the ap bus statically in the kernel, so add an option to compile it as module. Cc: Tony Krowiak <akrowiak@linux.ibm.com> Cc: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> 
There is no hard requirement to have the ap bus statically in the
kernel, so add an option to compile it as module.

Cc: Tony Krowiak <akrowiak@linux.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>