kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/drivers/crypto/Kconfig

834 lines
25 KiB
Raw Permalink Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 13:07:45 +01:00
Use menuconfig objects: crypto hw Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Cc: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-15 23:39:36 -07:00
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-14 01:50:22 +09:00
Add some help texts to recently-introduced kconfig items Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (edited MACINTOSH_DRIVERS per Geert Uytterhoeven's remark) Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-18 12:56:21 +02:00
Use menuconfig objects: crypto hw Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Cc: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-15 23:39:36 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: allwinner - Add allwinner subdirectory Since a second Allwinner crypto driver will be added, it is better to create a dedicated subdirectory. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23 22:05:03 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] padlock: Make CRYPTO_DEV_PADLOCK a tristate again Turning it into a boolean was unnecessary and caused ALGAPI to be pinned down as a boolean to. This patch makes it a tristate again. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-05-18 13:17:22 +10:00
crypto: padlock - Restore dependency on x86 When we added 64-bit support to padlock the dependency on x86 was lost. This causes build failures on non-x86 architectures. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-04-22 13:00:15 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] padlock: Get rid of padlock-generic.c Merge padlock-generic.c into padlock-aes.c and compile AES as a standalone module. We won't make a monolithic padlock.ko with all supported algorithms, instead we'll compile each driver into its own module. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-08-06 22:46:20 +10:00
s390/pkey: Introduce pkey base with handler registry and handler modules 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>
2024-08-22 11:32:19 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] padlock: Helper module padlock.ko Compile a helper module padlock.ko that will try to autoload all configured padlock algorithms. This also provides backward compatibility with the ancient times before padlock.ko was renamed to padlock-aes.ko Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-08-06 22:50:30 +10:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] padlock: Get rid of padlock-generic.c Merge padlock-generic.c into padlock-aes.c and compile AES as a standalone module. We won't make a monolithic padlock.ko with all supported algorithms, instead we'll compile each driver into its own module. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-08-06 22:46:20 +10:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: padlock/aes - switch to library version of key expansion routine Switch to the new AES library that also provides an implementation of the AES key expansion routine. This removes the dependency on the generic AES cipher, allowing it to be omitted entirely in the future. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-07-02 21:41:25 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CRYPTO] padlock: Get rid of padlock-generic.c Merge padlock-generic.c into padlock-aes.c and compile AES as a standalone module. We won't make a monolithic padlock.ko with all supported algorithms, instead we'll compile each driver into its own module. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-08-06 22:46:20 +10:00
trivial: Kconfig: .ko is normally not included in module names .ko is normally not included in Kconfig help, make it consistent. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-06-05 00:44:53 +02:00
[CRYPTO] padlock: Get rid of padlock-generic.c Merge padlock-generic.c into padlock-aes.c and compile AES as a standalone module. We won't make a monolithic padlock.ko with all supported algorithms, instead we'll compile each driver into its own module. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-08-06 22:46:20 +10:00
[CRYPTO] padlock: Driver for SHA1 / SHA256 algorithms Support for SHA1 / SHA256 algorithms in VIA C7 processors. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-07-12 12:29:38 +10:00
crypto: padlock - Switch sha to shash This patch converts the padlock-sha implementation to shash. In doing so the existing mechanism of storing the data until final is no longer viable as we do not have a way of allocating data in crypto_shash_init and then reliably freeing it. This is just as well because a better way of handling the problem is to hash everything but the last chunk using normal sha code and then provide the intermediate result to the padlock device. This is good enough because the primary application of padlock-sha is IPsec and there the data is laid out in the form of an hmac header followed by the rest of the packet. In essence we can provide all the data to the padlock as the hmac header only needs to be hashed once. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-07-11 18:16:16 +08:00
[CRYPTO] padlock: Driver for SHA1 / SHA256 algorithms Support for SHA1 / SHA256 algorithms in VIA C7 processors. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-07-12 12:29:38 +10:00
trivial: Kconfig: .ko is normally not included in module names .ko is normally not included in Kconfig help, make it consistent. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-06-05 00:44:53 +02:00
[CRYPTO] padlock: Driver for SHA1 / SHA256 algorithms Support for SHA1 / SHA256 algorithms in VIA C7 processors. Signed-off-by: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-07-12 12:29:38 +10:00
[PATCH] crypto: Add support for the Geode LX AES hardware Add a driver to support the AES hardware on the Geode LX processor. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-10-04 18:48:57 +10:00
[CRYPTO] padlock: Remove pointless padlock module When this is compiled in it is run too early to do anything useful: [ 6.052000] padlock: No VIA PadLock drivers have been loaded. [ 6.052000] padlock: Using VIA PadLock ACE for AES algorithm. [ 6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms. When it's a module it isn't doing anything special, the same functionality can be provided in userspace by "probeall padlock padlock-aes padlock-sha" in modules.conf if it is required. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Cc: Michal Ludvig <michal@logix.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-05-02 22:08:26 +10:00
[PATCH] crypto: Add support for the Geode LX AES hardware Add a driver to support the AES hardware on the Geode LX processor. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-10-04 18:48:57 +10:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
[PATCH] crypto: Add support for the Geode LX AES hardware Add a driver to support the AES hardware on the Geode LX processor. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-10-04 18:48:57 +10:00
Fix trivial typos in Kconfig* files Fix several typos in help text in Kconfig* files. Signed-off-by: David Sterba <dave@jikos.cz> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-05-09 07:12:20 +02:00
[PATCH] crypto: Add support for the Geode LX AES hardware Add a driver to support the AES hardware on the Geode LX processor. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-10-04 18:48:57 +10:00
[S390] Kconfig: use common Kconfig files for s390. Disband drivers/s390/Kconfig, use the common Kconfig files. The s390 specific config options from drivers/s390/Kconfig are moved to the respective common Kconfig files. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-05-10 15:46:00 +02:00
s390/zcrypt: Rework CONFIG_ZCRYPT Kconfig text. The CONFIG_ZCRYPT Kconfig entry in drivers/crypto showed outdated hardware whereas the latest cards where missing. Reworked the text to reflect the current abilities of the zcrypt device driver. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-02-20 16:09:51 +01:00
[S390] Kconfig: use common Kconfig files for s390. Disband drivers/s390/Kconfig, use the common Kconfig files. The s390 specific config options from drivers/s390/Kconfig are moved to the respective common Kconfig files. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-05-10 15:46:00 +02:00
s390/ap: modularize ap bus 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>
2024-02-19 18:10:19 +01:00
[S390] zcrypt: add support for large random numbers This patch allows user space applications to access large amounts of truly random data. The random data source is the build-in hardware random number generator on the CEX2C cards. Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2008-04-17 07:46:15 +02:00
[S390] Kconfig: use common Kconfig files for s390. Disband drivers/s390/Kconfig, use the common Kconfig files. The s390 specific config options from drivers/s390/Kconfig are moved to the respective common Kconfig files. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-05-10 15:46:00 +02:00
s390/zcrypt: Rework CONFIG_ZCRYPT Kconfig text. The CONFIG_ZCRYPT Kconfig entry in drivers/crypto showed outdated hardware whereas the latest cards where missing. Reworked the text to reflect the current abilities of the zcrypt device driver. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-02-20 16:09:51 +01:00
s390/zcrypt: remove CEX2 and CEX3 device drivers Remove the legacy device driver code for CEX2 and CEX3 cards. The last machines which are able to handle CEX2 crypto cards are z10 EC first available 2008 and z10 BC first available 2009. The last machines able to handle a CEX3 crypto card are z196 first available 2010 and z114 first available 2011. Please note that this does not imply to drop CEX2 and CEX3 support in general. With older kernels on hardware up to the aforementioned machine models these crypto cards will get support by IBM. The removal of the CEX2 and CEX3 device drivers code opens up some simplifications, for example support for crypto cards without rng support can be removed also. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-06-28 12:36:08 +02:00
s390/zcrypt: New config switch CONFIG_ZCRYPT_DEBUG Introduce a new config switch CONFIG_ZCRYPT_DEBUG which will be used to enable some features for debugging the zcrypt device driver and ap bus system: Another patch will use this for displaying ap card and ap queue state information via sysfs attribute. A furher patch will use this to enable some special treatment for some fields of an crypto request to be able to inject failures and so help debugging with regards to handling of failures. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2020-09-23 09:18:38 +02:00
s390/pkey: Introduce pkey kernel module This patch introcudes a new kernel module pkey which is providing protected key handling and management functions. The pkey API is available within the kernel for other s390 specific code to create and manage protected keys. Additionally the functions are exported to user space via IOCTL calls. The implementation makes extensive use of functions provided by the zcrypt device driver. For generating protected keys from secure keys there is also a CEX coprocessor card needed. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-11-02 14:37:20 +01:00
s390/pkey: Introduce pkey base with handler registry and handler modules 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>
2024-08-22 11:32:19 +02:00
s390/pkey: Introduce pkey kernel module This patch introcudes a new kernel module pkey which is providing protected key handling and management functions. The pkey API is available within the kernel for other s390 specific code to create and manage protected keys. Additionally the functions are exported to user space via IOCTL calls. The implementation makes extensive use of functions provided by the zcrypt device driver. For generating protected keys from secure keys there is also a CEX coprocessor card needed. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-11-02 14:37:20 +01:00
s390/pkey: Introduce pkey base with handler registry and handler modules 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>
2024-08-22 11:32:19 +02:00
s390/pkey: Add new pkey handler module pkey-uv 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>
2024-10-25 12:34:32 +02:00
s390/pkey: Introduce pkey kernel module This patch introcudes a new kernel module pkey which is providing protected key handling and management functions. The pkey API is available within the kernel for other s390 specific code to create and manage protected keys. Additionally the functions are exported to user space via IOCTL calls. The implementation makes extensive use of functions provided by the zcrypt device driver. For generating protected keys from secure keys there is also a CEX coprocessor card needed. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-11-02 14:37:20 +01:00
s390/pkey: Introduce pkey base with handler registry and handler modules 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>
2024-08-22 11:32:19 +02:00
[S390] Kconfig: use common Kconfig files for s390. Disband drivers/s390/Kconfig, use the common Kconfig files. The s390 specific config options from drivers/s390/Kconfig are moved to the respective common Kconfig files. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-05-10 15:46:00 +02:00
s390/pkey: Add new pkey handler module pkey-uv 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>
2024-10-25 12:34:32 +02:00
s390/crypto: fix aes/paes Kconfig dependeny The s390_paes and the s390_aes kernel module used just one config symbol CONFIG_CRYPTO_AES. As paes has a dependency to PKEY and this requires ZCRYPT the aes module also had a dependency to the zcrypt device driver which is not true. Fixed by introducing a new config symbol CONFIG_CRYPTO_PAES which has dependencies to PKEY and ZCRYPT. Removed the dependency for the aes module to ZCRYPT. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-05-11 17:15:54 +02:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
s390/crypto: Select crypto engine in Kconfig when PAES is chosen 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>
2025-05-28 10:30:32 +02:00
s390/crypto: fix aes/paes Kconfig dependeny The s390_paes and the s390_aes kernel module used just one config symbol CONFIG_CRYPTO_AES. As paes has a dependency to PKEY and this requires ZCRYPT the aes module also had a dependency to the zcrypt device driver which is not true. Fixed by introducing a new config symbol CONFIG_CRYPTO_PAES which has dependencies to PKEY and ZCRYPT. Removed the dependency for the aes module to ZCRYPT. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-05-11 17:15:54 +02:00
crypto: s390 - New s390 specific protected key hash phmac Add support for protected key hmac ("phmac") for s390 arch. With the latest machine generation there is now support for protected key (that is a key wrapped by a master key stored in firmware) hmac for sha2 (sha224, sha256, sha384 and sha512) for the s390 specific CPACF instruction kmac. This patch adds support via 4 new ahashes registered as phmac(sha224), phmac(sha256), phmac(sha384) and phmac(sha512). Co-developed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-17 15:44:37 +02:00
[S390] crypto: move s390 Kconfig options. Move s390 crypto Kconfig options to drivers/crypto/Kconfig to have all hardware crypto devices in one place. This also makes messing up the kernel source tree easier for some people. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-01-26 14:11:07 +01:00
crypto: s390 - cleanup s390 Kconfig options Cleanup the remaining s390 crypto options by mentioning the earliest machine type that supports an accelerated algorithm. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-04-19 21:29:19 +02:00
[S390] crypto: move s390 Kconfig options. Move s390 crypto Kconfig options to drivers/crypto/Kconfig to have all hardware crypto devices in one place. This also makes messing up the kernel source tree easier for some people. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-01-26 14:11:07 +01:00
crypto: sl3516 - Add sl3516 crypto engine The cortina/gemini SL3516 SoC has a crypto IP name either (crypto engine/crypto acceleration engine in the datasheet). It support many algorithms like [AES|DES|3DES][ECB|CBC], SHA1, MD5 and some HMAC. This patch adds the core files and support for ecb(aes) and the RNG. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-06-01 15:11:29 +00:00
crypto: sl3516 - Typo s/Stormlink/Storlink/ According to Documentation/devicetree/bindings/arm/gemini.txt, the company was originally named "Storlink Semiconductor", and later renamed to "Storm Semiconductor". Fixes: 46c5338db7bd45b2 ("crypto: sl3516 - Add sl3516 crypto engine") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-06-25 15:27:23 +02:00
crypto: sl3516 - Add dependency on ARCH_GEMINI The Storlink SL3516 crypto engine is only present on Storlink Semiconductor/Storm Semiconductor/Cortina Systems Gemini SoCs. Hence add a dependency on ARCH_GEMINI, to prevent asking the user about this driver when configuring a kernel without Gemini support. While at it, group the dependencies. Fixes: 46c5338db7bd45b2 ("crypto: sl3516 - Add sl3516 crypto engine") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-06-25 15:27:24 +02:00
crypto: sl3516 - Add sl3516 crypto engine The cortina/gemini SL3516 SoC has a crypto IP name either (crypto engine/crypto acceleration engine in the datasheet). It support many algorithms like [AES|DES|3DES][ECB|CBC], SHA1, MD5 and some HMAC. This patch adds the core files and support for ecb(aes) and the RNG. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-06-01 15:11:29 +00:00
[CRYPTO] hifn_795x: HIFN 795x driver This is a driver for HIFN 795x crypto accelerator chips. It passed all tests for AES, DES and DES3_EDE except weak test for DES, since hardware can not determine weak keys. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-26 21:31:14 +08:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
[CRYPTO] hifn795x: Disallow built-in hifn795x when HW_RANDOM is m Currently it is possible to select HW_RANDOM as a module and have hifn795x built-in. This causes a build problem because hifn795x will then call hwrng_register which isn't built-in. This patch introduces a new config option to control the hifn795x RNG which lets us avoid this problem. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-26 09:48:44 +11:00
[CRYPTO] hifn: Make Kconfig option depend on PCI The HIFN driver is currently selectable on s390 but wont compile. Since it looks like HIFN needs PCI make the Kconfig dependent on PCI, which is not available on s390. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Acked-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-12 21:56:38 +08:00
crypto: Make hifn_795x build depend on !ARCH_DMA_ADDR_T_64BIT hifn_795x works only on 32 bit, remove the detection while loading the module and catch non-32 bit systems at build time. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-10-10 12:55:41 +02:00
[CRYPTO] hifn_795x: HIFN 795x driver This is a driver for HIFN 795x crypto accelerator chips. It passed all tests for AES, DES and DES3_EDE except weak test for DES, since hardware can not determine weak keys. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-26 21:31:14 +08:00
[CRYPTO] hifn795x: Disallow built-in hifn795x when HW_RANDOM is m Currently it is possible to select HW_RANDOM as a module and have hifn795x built-in. This causes a build problem because hifn795x will then call hwrng_register which isn't built-in. This patch introduces a new config option to control the hifn795x RNG which lets us avoid this problem. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-01-26 09:48:44 +11:00
[CRYPTO] hifn_795x: HIFN 795x driver This is a driver for HIFN 795x crypto accelerator chips. It passed all tests for AES, DES and DES3_EDE except weak test for DES, since hardware can not determine weak keys. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-26 21:31:14 +08:00
treewide: surround Kconfig file paths with double quotes The Kconfig lexer supports special characters such as '.' and '/' in the parameter context. In my understanding, the reason is just to support bare file paths in the source statement. I do not see a good reason to complicate Kconfig for the room of ambiguity. The majority of code already surrounds file paths with double quotes, and it makes sense since file paths are constant string literals. Make it treewide consistent now. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Ingo Molnar <mingo@kernel.org>
2018-12-11 20:01:04 +09:00
crypto: caam - Add support for the Freescale SEC4/CAAM The SEC4 supercedes the SEC2.x/3.x as Freescale's Integrated Security Engine. Its programming model is incompatible with all prior versions of the SEC (talitos). The SEC4 is also known as the Cryptographic Accelerator and Assurance Module (CAAM); this driver is named caam. This initial submission does not include support for Data Path mode operation - AEAD descriptors are submitted via the job ring interface, while the Queue Interface (QI) is enabled for use by others. Only AEAD algorithms are implemented at this time, for use with IPsec. Many thanks to the Freescale STC team for their contributions to this driver. Signed-off-by: Steve Cornelius <sec@pobox.com> Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-03-13 16:54:26 +08:00
crypto: talitos - Freescale integrated security engine (SEC) driver Add support for the SEC available on a wide range of PowerQUICC devices, e.g. MPC8349E, MPC8548E. This initial version supports authenc(hmac(sha1),cbc(aes)) for use with IPsec. Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-06-23 19:50:15 +08:00
crypto: drivers - Fix Kconfig selects This patch fixes a number of problems in crypto driver Kconfig entries: 1. Select BLKCIPHER instead of BLKCIPHER2. The latter is internal and should not be used outside of the crypto API itself. 2. Do not select ALGAPI unless you use a legacy type like CRYPTO_ALG_TYPE_CIPHER. 3. Select the algorithm type that you are implementing, e.g., AEAD. 4. Do not select generic C code such as CBC/ECB unless you use them as a fallback. 5. Remove default n since that is the default default. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-17 14:58:24 +08:00
crypto: talitos - Freescale integrated security engine (SEC) driver Add support for the SEC available on a wide range of PowerQUICC devices, e.g. MPC8349E, MPC8548E. This initial version supports authenc(hmac(sha1),cbc(aes)) for use with IPsec. Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-06-23 19:50:15 +08:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: drivers - Fix Kconfig selects This patch fixes a number of problems in crypto driver Kconfig entries: 1. Select BLKCIPHER instead of BLKCIPHER2. The latter is internal and should not be used outside of the crypto API itself. 2. Do not select ALGAPI unless you use a legacy type like CRYPTO_ALG_TYPE_CIPHER. 3. Select the algorithm type that you are implementing, e.g., AEAD. 4. Do not select generic C code such as CBC/ECB unless you use them as a fallback. 5. Remove default n since that is the default default. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-17 14:58:24 +08:00
crypto: talitos - Fix build error by selecting LIB_DES The talitos driver needs to select LIB_DES as it needs calls des_expand_key. Fixes: 9d574ae8ebc1 ("crypto: talitos/des - switch to new...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-26 19:28:36 +08:00
crypto: talitos - Freescale integrated security engine (SEC) driver Add support for the SEC available on a wide range of PowerQUICC devices, e.g. MPC8349E, MPC8548E. This initial version supports authenc(hmac(sha1),cbc(aes)) for use with IPsec. Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-06-23 19:50:15 +08:00
crypto: talitos - add sub-choice in talitos CONFIG for SEC1 This patch adds a CONFIG option to select SEC1, SEC2+ or both. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-04-17 16:32:03 +02:00
crypto: amcc - Add crypt4xx driver This patch adds support for AMCC ppc4xx security device driver. This is the initial release that includes the driver framework with AES and SHA1 algorithms support. The remaining algorithms will be released in the near future. Signed-off-by: James Hsiao <jhsiao@amcc.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-05 16:18:13 +11:00
crypto: crypto4xx - prepare for AEAD support This patch enhances existing interfaces and functions to support AEAD ciphers in the next patches. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-10-04 01:00:15 +02:00
crypto: amcc - restore CRYPTO_AES dependency This patch restores the CRYPTO_AES dependency. This is necessary since some of the crypto4xx driver provided modes need functioning software fallbacks for AES-CTR/CCM and GCM. Fixes: da3e7a9715ea ("crypto: amcc - switch to AES library for GCM key derivation") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-27 16:47:47 +01:00
crypto: amcc - switch to AES library for GCM key derivation The AMCC code for GCM key derivation allocates a AES cipher to perform a single block encryption. So let's switch to the new and more lightweight AES library instead. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-07-02 21:41:42 +02:00
crypto: crypto4xx - prepare for AEAD support This patch enhances existing interfaces and functions to support AEAD ciphers in the next patches. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-10-04 01:00:15 +02:00
crypto: crypto4xx - add aes-ctr support This patch adds support for the aes-ctr skcipher. name : ctr(aes) driver : ctr-aes-ppc4xx module : crypto4xx priority : 300 refcnt : 1 selftest : passed internal : no type : skcipher async : yes blocksize : 16 min keysize : 16 max keysize : 32 ivsize : 16 chunksize : 16 walksize : 16 The hardware uses only the last 32-bits as the counter while the kernel tests (aes_ctr_enc_tv_template[4] for example) expect that the whole IV is a counter. To make this work, the driver will fallback if the counter is going to overlow. The aead's crypto4xx_setup_fallback() function is renamed to crypto4xx_aead_setup_fallback. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-04-19 18:41:54 +02:00
crypto: crypto4xx - prepare for AEAD support This patch enhances existing interfaces and functions to support AEAD ciphers in the next patches. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-10-04 01:00:15 +02:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: amcc - Add crypt4xx driver This patch adds support for AMCC ppc4xx security device driver. This is the initial release that includes the driver framework with AES and SHA1 algorithms support. The remaining algorithms will be released in the near future. Signed-off-by: James Hsiao <jhsiao@amcc.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-05 16:18:13 +11:00
crypto4xx: integrate ppc4xx-rng into crypto4xx This patch integrates the ppc4xx-rng driver into the existing crypto4xx. This is because the true random number generator is controlled and part of the security core. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-18 12:57:41 +02:00
crypto: crypto4xx - Avoid linking failure with HW_RANDOM=m It is currently possible to build CONFIG_HW_RANDOM_PPC4XX=y with CONFIG_HW_RANDOM=m which would lead to the inability of linking with devm_hwrng_{register,unregister}. We cannot have the framework modular and the consumer of that framework built-in, so make that dependency explicit. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-30 14:55:38 -08:00
crypto4xx: integrate ppc4xx-rng into crypto4xx This patch integrates the ppc4xx-rng driver into the existing crypto4xx. This is because the true random number generator is controlled and part of the security core. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-18 12:57:41 +02:00
treewide: replace '---help---' in Kconfig files with 'help' Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-14 01:50:22 +09:00
crypto4xx: integrate ppc4xx-rng into crypto4xx This patch integrates the ppc4xx-rng driver into the existing crypto4xx. This is because the true random number generator is controlled and part of the security core. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-18 12:57:41 +02:00
crypto: omap - add base support library for common routines This contains the generic APIs for aligning SG buffers. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 10:35:26 +03:00
crypto: omap-des - add COMPILE_TEST and fix CONFIG_OF=n build CRYPTO_DEV_OMAP_DES only depends on ARCH_OMAP2PLUS, which is ARM-only and selects OF via ARM's USE_OF, making any non-OF code unreachable. Add COMPILE_TEST so the driver can be built with CONFIG_OF=n, making the non-OF code reachable. Fix the resulting non-OF build failures: - omap_des_irq() was defined inside a CONFIG_OF block, but is referenced unconditionally from omap_des_probe(). Move the CONFIG_OF guard so it only covers omap_des_get_of(). - The non-OF omap_des_get_of() stub took a struct device *, while omap_des_probe() passes a struct platform_device *. Make the stub prototype match the OF implementation and the caller. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-17 12:34:14 +02:00
crypto: omap - add base support library for common routines This contains the generic APIs for aligning SG buffers. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 10:35:26 +03:00
crypto: Kconfig - Fix indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-21 04:20:48 +01:00
crypto: omap - add base support library for common routines This contains the generic APIs for aligning SG buffers. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 10:35:26 +03:00
crypto: omap - sha1 & md5 driver Earlier kernel contained omap sha1 and md5 driver, which was not maintained, was not ported to new crypto APIs and removed from the source tree. - implements async crypto API using dma and cpu. - supports multiple sham instances if available - hmac - concurrent requests Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-03 11:10:59 +08:00
crypto: omap-sham - Add SHA384 and SHA512 Support Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224 SHA256 that the omap sha module supports. In order to add the support - Removed hard coded register offsets and passing offsets from pdata - Updating Flag offsets so that they can be used for SHA256 and SHA512 - Adding the algo info. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-07-26 12:29:14 +05:30
crypto: omap-sham - Fix link error without crypto-engine The driver was converted to use the crypto engine helper but is missing the corresponding Kconfig statement to ensure it is available: arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function `omap_sham_probe': omap-sham.c:(.text+0x374): undefined reference to `crypto_engine_alloc_init' arm-linux-gnueabi-ld: omap-sham.c:(.text+0x384): undefined reference to `crypto_engine_start' arm-linux-gnueabi-ld: omap-sham.c:(.text+0x510): undefined reference to `crypto_engine_exit' arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function `omap_sham_finish_req': omap-sham.c:(.text+0x98c): undefined reference to `crypto_finalize_hash_request' arm-linux-gnueabi-ld: omap-sham.c:(.text+0x9a0): undefined reference to `crypto_transfer_hash_request_to_engine' arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function `omap_sham_update': omap-sham.c:(.text+0xf24): undefined reference to `crypto_transfer_hash_request_to_engine' arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function `omap_sham_final': omap-sham.c:(.text+0x1020): undefined reference to `crypto_transfer_hash_request_to_engine' Fixes: 133c3d434d91 ("crypto: omap-sham - convert to use crypto engine") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-01-03 15:03:04 +01:00
crypto: omap - sha1 & md5 driver Earlier kernel contained omap sha1 and md5 driver, which was not maintained, was not ported to new crypto APIs and removed from the source tree. - implements async crypto API using dma and cpu. - supports multiple sham instances if available - hmac - concurrent requests Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-03 11:10:59 +08:00
crypto: omap-sham - Add SHA384 and SHA512 Support Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224 SHA256 that the omap sha module supports. In order to add the support - Removed hard coded register offsets and passing offsets from pdata - Updating Flag offsets so that they can be used for SHA256 and SHA512 - Adding the algo info. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-07-26 12:29:14 +05:30
crypto: omap - sha1 & md5 driver Earlier kernel contained omap sha1 and md5 driver, which was not maintained, was not ported to new crypto APIs and removed from the source tree. - implements async crypto API using dma and cpu. - supports multiple sham instances if available - hmac - concurrent requests Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-03 11:10:59 +08:00
crypto: omap-sham - Add SHA384 and SHA512 Support Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224 SHA256 that the omap sha module supports. In order to add the support - Removed hard coded register offsets and passing offsets from pdata - Updating Flag offsets so that they can be used for SHA256 and SHA512 - Adding the algo info. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-07-26 12:29:14 +05:30
crypto: omap - sha1 & md5 driver Earlier kernel contained omap sha1 and md5 driver, which was not maintained, was not ported to new crypto APIs and removed from the source tree. - implements async crypto API using dma and cpu. - supports multiple sham instances if available - hmac - concurrent requests Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-03 11:10:59 +08:00
crypto: omap-aes - OMAP2/3 AES hw accelerator driver Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-09-03 19:16:02 +08:00
crypto: omap-aes - Kconfig: Add build support for AM437x For AM437x SoC, ARCH_OMAP2 and ARCH_OMAP3 is not enabled in the defconfig. We follow same thing as SHA driver, and add depends on ARCH_OMAP2PLUS so that the config is selectable for AES driver on AM437x SoC builds. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-17 21:42:35 -05:00
crypto: omap-aes - OMAP2/3 AES hw accelerator driver Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-09-03 19:16:02 +08:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: omap-aes - Support crypto engine framework Integrate with the newly added crypto engine to make the crypto hardware engine underutilized as each block needs to be processed before the crypto hardware can start working on the next block. The requests from dm-crypt will be listed into engine queue and processed by engine automatically, so remove the 'queue' and 'queue_task' things in omap aes driver. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-01-26 20:25:40 +08:00
crypto: omap-aes - Add fallback support As setting up the DMA operations is quite costly, add software fallback support for requests smaller than 200 bytes. This change gives some 10% extra performance in ipsec use case. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [t-kristo@ti.com: udpated against latest upstream, to use skcipher mainly] Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-08-04 13:28:44 +03:00
crypto: omap-aes - Add support for GCM mode OMAP AES hw supports AES-GCM mode. This patch adds support for GCM and RFC4106 GCM mode in omap-aes driver. The GCM implementation is mostly written into its own source file, which gets built into the same driver binary as the existing AES support. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [t-kristo@ti.com: forward port to latest upstream kernel, conversion to use omap-crypto lib and some additional fixes] Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 10:35:31 +03:00
crypto: omap-aes - OMAP2/3 AES hw accelerator driver Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-09-03 19:16:02 +08:00
crypto: omap-des - Add config and build options Add config and build options for the omap-des driver. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-02-14 10:49:47 -06:00
crypto: omap-des - Improve wording for CRYPTO_DEV_OMAP_DES in Kconfig Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-03-13 16:15:37 +01:00
crypto: omap-des - add COMPILE_TEST and fix CONFIG_OF=n build CRYPTO_DEV_OMAP_DES only depends on ARCH_OMAP2PLUS, which is ARM-only and selects OF via ARM's USE_OF, making any non-OF code unreachable. Add COMPILE_TEST so the driver can be built with CONFIG_OF=n, making the non-OF code reachable. Fix the resulting non-OF build failures: - omap_des_irq() was defined inside a CONFIG_OF block, but is referenced unconditionally from omap_des_probe(). Move the CONFIG_OF guard so it only covers omap_des_get_of(). - The non-OF omap_des_get_of() stub took a struct device *, while omap_des_probe() passes a struct platform_device *. Make the stub prototype match the OF implementation and the caller. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-17 12:34:14 +02:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: omap-des - Integrate with the crypto engine framework Since the crypto engine framework had been merged, thus this patch integrates with the newly added crypto engine framework to make the crypto hardware engine under utilized as each block needs to be processed before the crypto hardware can start working on the next block. The crypto engine framework can manage and process the requests automatically, so remove the 'queue' and 'queue_task' things in omap des driver. Signed-off-by: Baolin <baolin.wang@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-04-28 14:11:51 +08:00
crypto: omap-des - Add config and build options Add config and build options for the omap-des driver. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-02-14 10:49:47 -06:00
crypto: omap-des - Improve wording for CRYPTO_DEV_OMAP_DES in Kconfig Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-03-13 16:15:37 +01:00
crypto: omap-des - Add config and build options Add config and build options for the omap-des driver. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-02-14 10:49:47 -06:00
crypto: omap - add base support library for common routines This contains the generic APIs for aligning SG buffers. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 10:35:26 +03:00
crypto: sahara - Add driver for SAHARA2 accelerator. SAHARA2 HW module is included in the i.MX27 SoC from Freescale. It is capable of performing cipher algorithms such as AES, 3DES..., hashing and RNG too. This driver provides support for AES-CBC and AES-ECB by now. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-03-01 12:37:53 +01:00
crypto: sahara - remove dependency on EXPERIMENTAL The Kconfig symbol EXPERIMENTAL was removed in v3.9. So this dependency makes it impossible to set CRYPTO_DEV_SAHARA. It's unlikely that this is what is intended, so let's remove this dependency. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-05-12 13:57:19 +02:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: sahara - Add driver for SAHARA2 accelerator. SAHARA2 HW module is included in the i.MX27 SoC from Freescale. It is capable of performing cipher algorithms such as AES, 3DES..., hashing and RNG too. This driver provides support for AES-CBC and AES-ECB by now. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-03-01 12:37:53 +01:00
crypto: sahara - add support for crypto_engine Convert sahara driver to use crypto_engine, rather than doing manual queue management. Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-12-24 10:21:44 +02:00
crypto: sahara - Add driver for SAHARA2 accelerator. SAHARA2 HW module is included in the i.MX27 SoC from Freescale. It is capable of performing cipher algorithms such as AES, 3DES..., hashing and RNG too. This driver provides support for AES-CBC and AES-ECB by now. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-03-01 12:37:53 +01:00
crypto: s5p-sss - add S5PV210 advanced crypto engine support This change adds support for AES encrypting and decrypting using advanced crypto engine found on Samsung S5PV210 and S5PC110 SoCs. Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-04-08 20:40:51 +08:00
crypto: s5p-sss - Let Exynos SoCs select SSS driver This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> CC: David S. Miller <davem@davemloft.net> CC: <linux-samsung-soc@vger.kernel.org> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-08 21:58:14 +08:00
crypto: s5p-sss - Enable COMPILE_TEST Get some build coverage of S5P/Exynos AES H/W acceleration driver. Driver uses DMA and devm_ioremap_resource() so add DMA and IOMEM dependencies for the compile testing. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-03-14 13:20:18 +09:00
crypto: drivers - Remove depends on HAS_DMA in case of platform dependency Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-04-17 19:49:03 +02:00
crypto: s5p-sss - add S5PV210 advanced crypto engine support This change adds support for AES encrypting and decrypting using advanced crypto engine found on Samsung S5PV210 and S5PC110 SoCs. Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-04-08 20:40:51 +08:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: s5p-sss - add S5PV210 advanced crypto engine support This change adds support for AES encrypting and decrypting using advanced crypto engine found on Samsung S5PV210 and S5PC110 SoCs. Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-04-08 20:40:51 +08:00
crypto: s5p-sss - Let Exynos SoCs select SSS driver This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> CC: David S. Miller <davem@davemloft.net> CC: <linux-samsung-soc@vger.kernel.org> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-08 21:58:14 +08:00
crypto: s5p-sss - add S5PV210 advanced crypto engine support This change adds support for AES encrypting and decrypting using advanced crypto engine found on Samsung S5PV210 and S5PC110 SoCs. Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-04-08 20:40:51 +08:00
crypto: s5p-sss - Add HASH support for Exynos Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW. It uses the crypto framework asynchronous hash api. It is based on omap-sham.c driver. S5P has some HW differencies and is not implemented. Modifications in s5p-sss: - Add hash supporting structures and functions. - Modify irq handler to handle both aes and hash signals. - Resize resource end in probe if EXYNOS_HASH is enabled in Kconfig. - Add new copyright line and new author. - Tested on Odroid-U3 with Exynos 4412 CPU, kernel 4.13-rc6 with crypto run-time self test testmgr and with tcrypt module with: modprobe tcrypt sec=1 mode=N where N=402, 403, 404 (MD5, SHA1, SHA256). Modifications in drivers/crypto/Kconfig: - Add new CRYPTO_DEV_EXYNOS_HASH, depend on !EXYNOS_RNG and CRYPTO_DEV_S5P - Select sw algorithms MD5, SHA1 and SHA256 in EXYNOS_HASH as they are needed for fallback. Acked-by: Vladimir Zapolskiy <vz@mleia.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-10-25 17:27:35 +02:00
powerpc/crypto: Build files for the nx device driver These files support configuring and building the nx device driver. Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-04-12 05:39:26 +00:00
crypto: nx - add NX-842 platform frontend driver Add NX-842 frontend that allows using either the pSeries platform or PowerNV platform driver (to be added by later patch) for the NX-842 hardware. Update the MAINTAINERS file to include the new filenames. Update Kconfig files to clarify titles and descriptions, and correct dependencies. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-05-07 13:49:17 -04:00
powerpc/crypto: Build files for the nx device driver These files support configuring and building the nx device driver. Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-04-12 05:39:26 +00:00
crypto: nx - add NX-842 platform frontend driver Add NX-842 frontend that allows using either the pSeries platform or PowerNV platform driver (to be added by later patch) for the NX-842 hardware. Update the MAINTAINERS file to include the new filenames. Update Kconfig files to clarify titles and descriptions, and correct dependencies. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-05-07 13:49:17 -04:00
powerpc/crypto: rework Kconfig This patch creates a new submenu for the NX cryptographic hardware accelerator and breaks the NX options into their own Kconfig file under drivers/crypto/nx/Kconfig. This will permit additional NX functionality to be easily and more cleanly added in the future without touching drivers/crypto/Makefile|Kconfig. Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-19 09:42:38 -05:00
powerpc/crypto: Build files for the nx device driver These files support configuring and building the nx device driver. Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2012-04-12 05:39:26 +00:00
crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes This patchs allows to combine the AES and SHA hardware accelerators on some Atmel SoCs. Doing so, AES blocks are only written to/read from the AES hardware. Those blocks are also transferred from the AES to the SHA accelerator internally, without additionnal accesses to the system busses. Hence, the AES and SHA accelerators work in parallel to process all the data blocks, instead of serializing the process by (de)crypting those blocks first then authenticating them after like the generic crypto/authenc.c driver does. Of course, both the AES and SHA hardware accelerators need to be available before we can start to process the data blocks. Hence we use their crypto request queue to synchronize both drivers. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-01-26 17:07:56 +01:00
crypto: atmel - Fix build error of CRYPTO_AUTHENC If CRYPTO_DEV_ATMEL_AUTHENC is m, CRYPTO_DEV_ATMEL_SHA is m, but CRYPTO_DEV_ATMEL_AES is y, building will fail: drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_init_tfm': atmel-aes.c:(.text+0x670): undefined reference to `atmel_sha_authenc_get_reqsize' atmel-aes.c:(.text+0x67a): undefined reference to `atmel_sha_authenc_spawn' drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_setkey': atmel-aes.c:(.text+0x7e5): undefined reference to `atmel_sha_authenc_setkey' Make CRYPTO_DEV_ATMEL_AUTHENC depend on CRYPTO_DEV_ATMEL_AES, and select CRYPTO_DEV_ATMEL_SHA and CRYPTO_AUTHENC for it under there. Reported-by: Hulk Robot <hulkci@huawei.com> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-13 17:55:50 +08:00
crypto: atmel - refine Kconfig dependencies With the new authenc support, we get a harmless Kconfig warning: warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91) The problem is that each of the options has slightly different dependencies, although they all seem to want the same thing: allow building for real AT91 targets that actually have the hardware, and possibly for compile testing. This makes all four options consistent: instead of depending on a particular dmaengine implementation, we depend on the ARM platform, CONFIG_COMPILE_TEST as an alternative when that is turned off. This makes the 'select' statements work correctly. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-06 13:32:15 +01:00
crypto: atmel - Fix build error of CRYPTO_AUTHENC If CRYPTO_DEV_ATMEL_AUTHENC is m, CRYPTO_DEV_ATMEL_SHA is m, but CRYPTO_DEV_ATMEL_AES is y, building will fail: drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_init_tfm': atmel-aes.c:(.text+0x670): undefined reference to `atmel_sha_authenc_get_reqsize' atmel-aes.c:(.text+0x67a): undefined reference to `atmel_sha_authenc_spawn' drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_setkey': atmel-aes.c:(.text+0x7e5): undefined reference to `atmel_sha_authenc_setkey' Make CRYPTO_DEV_ATMEL_AUTHENC depend on CRYPTO_DEV_ATMEL_AES, and select CRYPTO_DEV_ATMEL_SHA and CRYPTO_AUTHENC for it under there. Reported-by: Hulk Robot <hulkci@huawei.com> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-13 17:55:50 +08:00
crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes This patchs allows to combine the AES and SHA hardware accelerators on some Atmel SoCs. Doing so, AES blocks are only written to/read from the AES hardware. Those blocks are also transferred from the AES to the SHA accelerator internally, without additionnal accesses to the system busses. Hence, the AES and SHA accelerators work in parallel to process all the data blocks, instead of serializing the process by (de)crypting those blocks first then authenticating them after like the generic crypto/authenc.c driver does. Of course, both the AES and SHA hardware accelerators need to be available before we can start to process the data blocks. Hence we use their crypto request queue to synchronize both drivers. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-01-26 17:07:56 +01:00
crypto: atmel - add Atmel AES driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:44 +02:00
crypto: atmel-aes: make it selectable for ARCH_MICROCHIP LAN969x uses the Atmel crypto, so make it selectable for ARCH_MICROCHIP to avoid needing to update depends in future if other Microchip SoC-s use it as well. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2025-08-13 19:44:45 +02:00
crypto: atmel - add Atmel AES driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:44 +02:00
crypto: atmel-aes - add support to GCM mode This patch adds support to the GCM mode. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-12-17 18:13:07 +01:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: atmel - Fix build error of CRYPTO_AUTHENC If CRYPTO_DEV_ATMEL_AUTHENC is m, CRYPTO_DEV_ATMEL_SHA is m, but CRYPTO_DEV_ATMEL_AES is y, building will fail: drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_init_tfm': atmel-aes.c:(.text+0x670): undefined reference to `atmel_sha_authenc_get_reqsize' atmel-aes.c:(.text+0x67a): undefined reference to `atmel_sha_authenc_spawn' drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_setkey': atmel-aes.c:(.text+0x7e5): undefined reference to `atmel_sha_authenc_setkey' Make CRYPTO_DEV_ATMEL_AUTHENC depend on CRYPTO_DEV_ATMEL_AES, and select CRYPTO_DEV_ATMEL_SHA and CRYPTO_AUTHENC for it under there. Reported-by: Hulk Robot <hulkci@huawei.com> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-13 17:55:50 +08:00
crypto: atmel - add Atmel AES driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:44 +02:00
crypto: atmel - add Atmel DES/TDES driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:45 +02:00
crypto: atmel - refine Kconfig dependencies With the new authenc support, we get a harmless Kconfig warning: warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91) The problem is that each of the options has slightly different dependencies, although they all seem to want the same thing: allow building for real AT91 targets that actually have the hardware, and possibly for compile testing. This makes all four options consistent: instead of depending on a particular dmaengine implementation, we depend on the ARM platform, CONFIG_COMPILE_TEST as an alternative when that is turned off. This makes the 'select' statements work correctly. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-06 13:32:15 +01:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: atmel - add Atmel DES/TDES driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:45 +02:00
crypto: atmel - add Atmel SHA1/SHA256 driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:46 +02:00
crypto: atmel-sha - add support for latest release of the IP (0x410) Updates from IP release 0x320 to 0x400: - add DMA support (previous IP revision use PDC) - add DMA double input buffer support - add SHA224 support Update from IP release 0x400 to 0x410: - add SHA384 and SHA512 support Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-02-20 17:10:26 +01:00
crypto: atmel - refine Kconfig dependencies With the new authenc support, we get a harmless Kconfig warning: warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91) The problem is that each of the options has slightly different dependencies, although they all seem to want the same thing: allow building for real AT91 targets that actually have the hardware, and possibly for compile testing. This makes all four options consistent: instead of depending on a particular dmaengine implementation, we depend on the ARM platform, CONFIG_COMPILE_TEST as an alternative when that is turned off. This makes the 'select' statements work correctly. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-06 13:32:15 +01:00
crypto: drivers - Fix Kconfig selects This patch fixes a number of problems in crypto driver Kconfig entries: 1. Select BLKCIPHER instead of BLKCIPHER2. The latter is internal and should not be used outside of the crypto API itself. 2. Do not select ALGAPI unless you use a legacy type like CRYPTO_ALG_TYPE_CIPHER. 3. Select the algorithm type that you are implementing, e.g., AEAD. 4. Do not select generic C code such as CBC/ECB unless you use them as a fallback. 5. Remove default n since that is the default default. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-17 14:58:24 +08:00
crypto: atmel - add Atmel SHA1/SHA256 driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:46 +02:00
crypto: atmel-sha - add support for latest release of the IP (0x410) Updates from IP release 0x320 to 0x400: - add DMA support (previous IP revision use PDC) - add DMA double input buffer support - add SHA224 support Update from IP release 0x400 to 0x410: - add SHA384 and SHA512 support Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-02-20 17:10:26 +01:00
crypto: atmel - add Atmel SHA1/SHA256 driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:46 +02:00
crypto: atmel-sha - add support for latest release of the IP (0x410) Updates from IP release 0x320 to 0x400: - add DMA support (previous IP revision use PDC) - add DMA double input buffer support - add SHA224 support Update from IP release 0x400 to 0x410: - add SHA384 and SHA512 support Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-02-20 17:10:26 +01:00
crypto: atmel - add Atmel SHA1/SHA256 driver Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-01 19:19:46 +02:00
crypto: atmel-ecc - factor out code that can be shared In preparation of adding support for the random number generator in Atmel atsha204a devices, refactor the existing atmel-ecc driver (which drives hardware that is closely related) so we can share the basic I2C and command queuing routines. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-24 18:26:48 +02:00
crypto: atmel-i2c - select CONFIG_BITREVERSE The bitreverse helper is almost always built into the kernel, but in a rare randconfig build it is possible to hit a case in which it is a loadable module while the atmel-i2c driver is built-in: arm-linux-gnueabi-ld: drivers/crypto/atmel-i2c.o: in function `atmel_i2c_checksum': atmel-i2c.c:(.text+0xa0): undefined reference to `byte_rev_table' Add one more 'select' statement to prevent this. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-12-04 00:20:04 +01:00
crypto: atmel-ecc - factor out code that can be shared In preparation of adding support for the random number generator in Atmel atsha204a devices, refactor the existing atmel-ecc driver (which drives hardware that is closely related) so we can share the basic I2C and command queuing routines. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-24 18:26:48 +02:00
crypto: atmel-ecc - introduce Microchip / Atmel ECC driver Add ECDH support for ATECC508A (I2C) device. The device features hardware acceleration for the NIST standard P256 prime curve and supports the complete key life cycle from private key generation to ECDH key agreement. Random private key generation is supported internally within the device to ensure that the private key can never be known outside of the device. If the user wants to use its own private keys, the driver will fallback to the ecdh software implementation. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-05 13:07:59 +03:00
crypto: atmel-ecc - factor out code that can be shared In preparation of adding support for the random number generator in Atmel atsha204a devices, refactor the existing atmel-ecc driver (which drives hardware that is closely related) so we can share the basic I2C and command queuing routines. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-24 18:26:48 +02:00
crypto: atmel-ecc - introduce Microchip / Atmel ECC driver Add ECDH support for ATECC508A (I2C) device. The device features hardware acceleration for the NIST standard P256 prime curve and supports the complete key life cycle from private key generation to ECDH key agreement. Random private key generation is supported internally within the device to ensure that the private key can never be known outside of the device. If the user wants to use its own private keys, the driver will fallback to the ecdh software implementation. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-05 13:07:59 +03:00
crypto: kconfig - fix typos in atmel-ecc and atmel-sha204a help s/Microhip/Microchip/ Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-27 01:17:27 +01:00
crypto: atmel-ecc - introduce Microchip / Atmel ECC driver Add ECDH support for ATECC508A (I2C) device. The device features hardware acceleration for the NIST standard P256 prime curve and supports the complete key life cycle from private key generation to ECDH key agreement. Random private key generation is supported internally within the device to ensure that the private key can never be known outside of the device. If the user wants to use its own private keys, the driver will fallback to the ecdh software implementation. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-05 13:07:59 +03:00
crypto: atmel-i2c - add support for SHA204A random number generator The Linaro/96boards Secure96 mezzanine contains (among other things) an Atmel SHA204A symmetric crypto processor. This chip implements a number of different functionalities, but one that is highly useful for many different 96boards platforms is the random number generator. So let's implement a driver for the SHA204A, and for the time being, implement support for the random number generator only. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-24 18:26:49 +02:00
crypto: atmel-i2c - Fix build error while CRC16 set to m If CRYPTO_DEV_ATMEL_ECC is set m, which select CRC16 to m, while CRYPTO_DEV_ATMEL_SHA204A is set to y, building fails. drivers/crypto/atmel-i2c.o: In function 'atmel_i2c_checksum': atmel-i2c.c:(.text+0x16): undefined reference to 'crc16' Add CRC16 dependency to CRYPTO_DEV_ATMEL_SHA204A Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-31 20:17:49 +08:00
crypto: atmel-i2c - add support for SHA204A random number generator The Linaro/96boards Secure96 mezzanine contains (among other things) an Atmel SHA204A symmetric crypto processor. This chip implements a number of different functionalities, but one that is highly useful for many different 96boards platforms is the random number generator. So let's implement a driver for the SHA204A, and for the time being, implement support for the random number generator only. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-24 18:26:49 +02:00
crypto: kconfig - fix typos in atmel-ecc and atmel-sha204a help s/Microhip/Microchip/ Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-27 01:17:27 +01:00
crypto: atmel-i2c - add support for SHA204A random number generator The Linaro/96boards Secure96 mezzanine contains (among other things) an Atmel SHA204A symmetric crypto processor. This chip implements a number of different functionalities, but one that is highly useful for many different 96boards platforms is the random number generator. So let's implement a driver for the SHA204A, and for the time being, implement support for the random number generator only. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-24 18:26:49 +02:00
crytpo: ccp - CCP device driver build files These files provide the ability to configure and build the AMD CCP device driver and crypto API support. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-11-12 11:46:51 -06:00
crypto: ccp - Introduce the AMD Secure Processor device The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-06 09:59:14 -05:00
crypto: ccp - Add ACPI support Add support for ACPI to the CCP platform driver. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-02-03 13:07:29 -06:00
crytpo: ccp - CCP device driver build files These files provide the ability to configure and build the AMD CCP device driver and crypto API support. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-11-12 11:46:51 -06:00
crypto: ccp - Introduce the AMD Secure Processor device The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-06 09:59:14 -05:00
crytpo: ccp - CCP device driver build files These files provide the ability to configure and build the AMD CCP device driver and crypto API support. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-11-12 11:46:51 -06:00
crypto: mxs - Add Freescale MXS DCP driver Add support for the MXS DCP block. The driver currently supports SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard CRC32 is not yet supported. Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: devicetree@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-12-10 20:26:21 +01:00
crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL MX6SL has the same DCP crypto block as in MX23/MX28, so allow it to be built for ARCH_MXC. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-09-02 12:05:18 -03:00
crypto: mxs-dcp - mxs-dcp is an stmp device The mxs-dcp driver relies on the stmp_reset_block() helper function, which is provided by CONFIG_STMP_DEVICE. This symbol is always set on MXS, but the driver can now also be built for MXC (i.MX6), which results in a built error if no other driver selects STMP_DEVICE: drivers/built-in.o: In function `mxs_dcp_probe': vf610-ocotp.c:(.text+0x3df302): undefined reference to `stmp_reset_block' This adds the 'select', like all other stmp drivers have it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: a2712e6c75f ("crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL") Acked-by: Marek Vasut <marex@denx.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-10-12 15:52:34 +02:00
crypto: mxs - Add Freescale MXS DCP driver Add support for the MXS DCP block. The driver currently supports SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard CRC32 is not yet supported. Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: devicetree@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-12-10 20:26:21 +01:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: drivers - Fix Kconfig selects This patch fixes a number of problems in crypto driver Kconfig entries: 1. Select BLKCIPHER instead of BLKCIPHER2. The latter is internal and should not be used outside of the crypto API itself. 2. Do not select ALGAPI unless you use a legacy type like CRYPTO_ALG_TYPE_CIPHER. 3. Select the algorithm type that you are implementing, e.g., AEAD. 4. Do not select generic C code such as CBC/ECB unless you use them as a fallback. 5. Remove default n since that is the default default. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-17 14:58:24 +08:00
crypto: mxs - Add Freescale MXS DCP driver Add support for the MXS DCP block. The driver currently supports SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard CRC32 is not yet supported. Signed-off-by: Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: devicetree@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-12-10 20:26:21 +01:00
crypto: cavium - Enable CPT options crypto for build Add the CPT options in crypto Kconfig and update the crypto Makefile Update the MAINTAINERS file too. Signed-off-by: George Cherian <george.cherian@cavium.com> Reviewed-by: David Daney <david.daney@cavium.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-07 14:51:15 +00:00
crypto: cavium - Add support for CNN55XX adapters. Add Physical Function driver support for CNN55XX crypto adapters. CNN55XX adapters belongs to Cavium NITROX family series, which accelerate both Symmetric and Asymmetric crypto workloads. These adapters have crypto engines that need firmware to become operational. Signed-off-by: Srikanth Jampala <Jampala.Srikanth@cavium.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-30 17:28:01 +05:30
crypto: marvell - create common Kconfig and Makefile for Marvell Creats common Kconfig and Makefile for Marvell crypto drivers. Signed-off-by: SrujanaChalla <schalla@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-03-13 17:17:05 +05:30
crypto: keembay - Move driver to drivers/crypto/intel/keembay With the growing number of Intel crypto drivers, it makes sense to group them all into a single drivers/crypto/intel/ directory. Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-03-28 10:39:49 -05:00
crypto: qce - Build Qualcomm crypto driver Modify crypto Kconfig and Makefile in order to build the qce driver and adds qce Makefile as well. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25 19:28:58 +03:00
crypto: qce - Mark QCE as BROKEN This driver is harmful: - It is much slower than the CPU [1] [2]. - It Has a history of bugs [2] [3]. - It does not have exclusive access to the hardware [4], causing races with the secure world. - It register its implementations with too low a cra_priority for them to be actually used [5]. Therefore, disable it to ensure that nobody builds it into kernels they intend to ship. In the future, the driver will be used for processing restricted media content. However, the kernel does not currently support this. Since the driver will have future uses, allow building it if COMPILE_TEST is enabled. [1]: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/ [2]: https://lore.kernel.org/r/20250615031807.GA81869@sol/ [3]: https://lore.kernel.org/r/20260706-qce-fix-self-tests-v5-0-86f461ff1829@oss.qualcomm.com/ [4]: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-0-56f67da84c05@oss.qualcomm.com/ [5]: https://lore.kernel.org/r/20260524204537.GB110177@quark/ Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-07-12 17:31:31 -04:00
crypto: drivers - Remove depends on HAS_DMA in case of platform dependency Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-04-17 19:49:03 +02:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Mark QCE as BROKEN This driver is harmful: - It is much slower than the CPU [1] [2]. - It Has a history of bugs [2] [3]. - It does not have exclusive access to the hardware [4], causing races with the secure world. - It register its implementations with too low a cra_priority for them to be actually used [5]. Therefore, disable it to ensure that nobody builds it into kernels they intend to ship. In the future, the driver will be used for processing restricted media content. However, the kernel does not currently support this. Since the driver will have future uses, allow building it if COMPILE_TEST is enabled. [1]: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/ [2]: https://lore.kernel.org/r/20250615031807.GA81869@sol/ [3]: https://lore.kernel.org/r/20260706-qce-fix-self-tests-v5-0-86f461ff1829@oss.qualcomm.com/ [4]: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-0-56f67da84c05@oss.qualcomm.com/ [5]: https://lore.kernel.org/r/20260524204537.GB110177@quark/ Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> Acked-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-07-12 17:31:31 -04:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Build Qualcomm crypto driver Modify crypto Kconfig and Makefile in order to build the qce driver and adds qce Makefile as well. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25 19:28:58 +03:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: qce - Build Qualcomm crypto driver Modify crypto Kconfig and Makefile in order to build the qce driver and adds qce Makefile as well. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25 19:28:58 +03:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - support zero length test vectors crypto test module passes zero length vectors as test input to sha-1 and sha-256. To provide correct output for these vectors, hash zero support has been added as in other crypto drivers. Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-22 11:45:04 +05:30
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Add support for AEAD algorithms Introduce support to enable following algorithms in Qualcomm Crypto Engine. - authenc(hmac(sha1),cbc(des)) - authenc(hmac(sha1),cbc(des3_ede)) - authenc(hmac(sha256),cbc(des)) - authenc(hmac(sha256),cbc(des3_ede)) - authenc(hmac(sha256),cbc(aes)) - ccm(aes) - rfc4309(ccm(aes)) Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-04-29 11:07:04 -04:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Build Qualcomm crypto driver Modify crypto Kconfig and Makefile in order to build the qce driver and adds qce Makefile as well. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25 19:28:58 +03:00
crypto: kconfig - fix a couple of spelling mistakes There are a couple of spelling mistakes in two crypto Kconfig files. Fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-11-14 12:12:27 +00:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Add support for AEAD algorithms Introduce support to enable following algorithms in Qualcomm Crypto Engine. - authenc(hmac(sha1),cbc(des)) - authenc(hmac(sha1),cbc(des3_ede)) - authenc(hmac(sha256),cbc(des)) - authenc(hmac(sha256),cbc(des3_ede)) - authenc(hmac(sha256),cbc(aes)) - ccm(aes) - rfc4309(ccm(aes)) Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-04-29 11:07:04 -04:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Add support for AEAD algorithms Introduce support to enable following algorithms in Qualcomm Crypto Engine. - authenc(hmac(sha1),cbc(des)) - authenc(hmac(sha1),cbc(des3_ede)) - authenc(hmac(sha256),cbc(des)) - authenc(hmac(sha256),cbc(des3_ede)) - authenc(hmac(sha256),cbc(aes)) - ccm(aes) - rfc4309(ccm(aes)) Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-04-29 11:07:04 -04:00
crypto: qce - allow building only hashes/ciphers Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-20 16:02:18 -03:00
crypto: qce - Build Qualcomm crypto driver Modify crypto Kconfig and Makefile in order to build the qce driver and adds qce Makefile as well. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25 19:28:58 +03:00
crypto: qce - use AES fallback for small requests Process small blocks using the fallback cipher, as a workaround for an observed failure (DMA-related, apparently) when computing the GCM ghash key. This brings a speed gain as well, since it avoids the latency of using the hardware engine to process small blocks. Using software for all 16-byte requests would be enough to make GCM work, but to increase performance, a larger threshold would be better. Measuring the performance of supported ciphers with openssl speed, software matches hardware at around 768-1024 bytes. Considering the 256-bit ciphers, software is 2-3 times faster than qce at 256-bytes, 30% faster at 512, and about even at 768-bytes. With 128-bit keys, the break-even point would be around 1024-bytes. This adds the 'aes_sw_max_len' parameter, to set the largest request length processed by the software fallback. Its default is being set to 512 bytes, a little lower than the break-even point, to balance the cost in CPU usage. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-02-07 12:02:26 -03:00
crypto: img-hash - Add Imagination Technologies hw hash accelerator This adds support for the Imagination Technologies hash accelerator which provides hardware acceleration for SHA1 SHA224 SHA256 and MD5 hashes. Signed-off-by: James Hartley <james.hartley@imgtec.com> Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-03-12 23:17:26 +00:00
crypto: img-hash - CRYPTO_DEV_IMGTEC_HASH should depend on HAS_DMA If NO_DMA=y: drivers/built-in.o: In function `img_hash_write_via_dma_stop': img-hash.c:(.text+0xa2b822): undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `img_hash_xmit_dma': img-hash.c:(.text+0xa2b8d8): undefined reference to `dma_map_sg' img-hash.c:(.text+0xa2b948): undefined reference to `dma_unmap_sg' Also move the "depends" section below the "tristate" line while we're at it. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-04-23 20:03:58 +02:00
crypto: img-hash - Add Imagination Technologies hw hash accelerator This adds support for the Imagination Technologies hash accelerator which provides hardware acceleration for SHA1 SHA224 SHA256 and MD5 hashes. Signed-off-by: James Hartley <james.hartley@imgtec.com> Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-03-12 23:17:26 +00:00
crypto: rockchip - add crypto driver for rk3288 Crypto driver support: ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede) You can alloc tags above in your case. And other algorithms and platforms will be added later on. Signed-off-by: Zain Wang <zain.wang@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-11-25 13:43:32 +08:00
crypto: rockchip - add fallback for cipher The hardware does not handle 0 size length request, let's add a fallback. Furthermore fallback will be used for all unaligned case the hardware cannot handle. Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-09-27 07:54:44 +00:00
crypto: rockchip - add crypto driver for rk3288 Crypto driver support: ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede) You can alloc tags above in your case. And other algorithms and platforms will be added later on. Signed-off-by: Zain Wang <zain.wang@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-11-25 13:43:32 +08:00
crypto: rockchip - rework by using crypto_engine Instead of doing manual queue management, let's use the crypto/engine for that. In the same time, rework the requests handling to be easier to understand (and fix all bugs related to them). Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API") Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-09-27 07:54:48 +00:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: rockchip - add hash support for crypto engine in rk3288 Add md5 sha1 sha256 support for crypto engine in rk3288. Signed-off-by: Zain Wang <zain.wang@rock-chips.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-02-16 10:15:01 +08:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: rockchip - add crypto driver for rk3288 Crypto driver support: ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede) You can alloc tags above in your case. And other algorithms and platforms will be added later on. Signed-off-by: Zain Wang <zain.wang@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-11-25 13:43:32 +08:00
crypto: rockchip - add debugfs This patch enable to access usage stats for each algorithm. Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-09-27 07:54:50 +00:00
crypto: tegra - Add Tegra Security Engine driver 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>
2024-04-03 15:30:37 +05:30
crypto: rockchip - add debugfs This patch enable to access usage stats for each algorithm. Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-09-27 07:54:50 +00:00
crypto: xilinx - Add Xilinx AES driver This patch adds AES driver support for the Xilinx ZynqMP SoC. Signed-off-by: Mohan Marutirao Dhanawade <mohan.dhanawade@xilinx.com> Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-02-17 15:56:43 +05:30
crypto: xilinx - Add Xilinx SHA3 driver This patch adds SHA3 driver support for the Xilinx ZynqMP SoC. Xilinx ZynqMP SoC has SHA3 engine used for secure hash calculation. The flow is SHA3 request from Userspace -> SHA3 driver-> ZynqMp driver-> Firmware -> SHA3 HW Engine SHA3 HW engine in Xilinx ZynqMP SoC, does not support parallel processing of 2 hash requests. Therefore, software fallback is being used for init, update, final, export and import in the ZynqMP SHA driver For digest, the calculation of SHA3 hash is done by the hardened SHA3 accelerator in Xilinx ZynqMP SoC. Signed-off-by: Harsha <harsha.harsha@xilinx.com> Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-02-23 16:05:03 +05:30
crypto: xilinx - Turn SHA into a tristate and allow COMPILE_TEST This patch turns the new SHA driver into a tristate and also allows compile testing. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-03-09 15:20:01 +12:00
crypto: xilinx - Add Xilinx SHA3 driver This patch adds SHA3 driver support for the Xilinx ZynqMP SoC. Xilinx ZynqMP SoC has SHA3 engine used for secure hash calculation. The flow is SHA3 request from Userspace -> SHA3 driver-> ZynqMp driver-> Firmware -> SHA3 HW Engine SHA3 HW engine in Xilinx ZynqMP SoC, does not support parallel processing of 2 hash requests. Therefore, software fallback is being used for init, update, final, export and import in the ZynqMP SHA driver For digest, the calculation of SHA3 hash is done by the hardened SHA3 accelerator in Xilinx ZynqMP SoC. Signed-off-by: Harsha <harsha.harsha@xilinx.com> Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-02-23 16:05:03 +05:30
crypto: Added Chelsio Menu to the Kconfig file Adds the config entry for the Chelsio Crypto Driver, Makefile changes for the same. Signed-off-by: Atul Gupta <atul.gupta@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-17 12:33:06 +05:30
crypto: add virtio-crypto driver This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by thebackend crypto accelerators. The second queue is the control queue used to create or destroy sessions for symmetric algorithms and will control some advanced features in the future. The virtio crypto device provides the following cryptoservices: CIPHER, MAC, HASH, and AEAD. For more information about virtio-crypto device, please see: http://qemu-project.org/Features/VirtioCrypto CC: Michael S. Tsirkin <mst@redhat.com> CC: Cornelia Huck <cornelia.huck@de.ibm.com> CC: Stefan Hajnoczi <stefanha@redhat.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Halil Pasic <pasic@linux.vnet.ibm.com> CC: David S. Miller <davem@davemloft.net> CC: Zeng Xin <xin.zeng@intel.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-12-15 10:03:16 +08:00
crypto: brcm - Add Broadcom SPU driver Add Broadcom Secure Processing Unit (SPU) crypto driver for SPU hardware crypto offload. The driver supports ablkcipher, ahash, and aead symmetric crypto operations. Signed-off-by: Steve Lin <steven.lin1@broadcom.com> Signed-off-by: Rob Rice <rob.rice@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-03 12:55:33 -05:00
crypto: brcm - remove BCM_PDC_MBOX dependency in Kconfig SPU driver is dependent on generic MAILBOX API's to communicate with underlying DMA engine driver. So this patch removes BCM_PDC_MBOX "depends on" for SPU driver in Kconfig and adds MAILBOX as dependent module. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Scott Branden <scott.branden@broadcom.com> Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-11 15:50:06 +05:30
crypto: brcm - Add Broadcom SPU driver Add Broadcom Secure Processing Unit (SPU) crypto driver for SPU hardware crypto offload. The driver supports ablkcipher, ahash, and aead symmetric crypto operations. Signed-off-by: Steve Lin <steven.lin1@broadcom.com> Signed-off-by: Rob Rice <rob.rice@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-03 12:55:33 -05:00
crypto: bcm - convert to use crypto_authenc_extractkeys() Convert the bcm crypto driver to use crypto_authenc_extractkeys() so that it picks up the fix for broken validation of rtattr::rta_len. This also fixes the DES weak key check to actually be done on the right key. (It was checking the authentication key, not the encryption key...) Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-12-16 23:23:23 -08:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: brcm - Add Broadcom SPU driver Add Broadcom Secure Processing Unit (SPU) crypto driver for SPU hardware crypto offload. The driver supports ablkcipher, ahash, and aead symmetric crypto operations. Signed-off-by: Steve Lin <steven.lin1@broadcom.com> Signed-off-by: Rob Rice <rob.rice@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-03 12:55:33 -05:00
crypto: bcm-spu - switch to skcipher API Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface") dated 20 august 2015 introduced the new skcipher API which is supposed to replace both blkcipher and ablkcipher. While all consumers of the API have been converted long ago, some producers of the ablkcipher remain, forcing us to keep the ablkcipher support routines alive, along with the matching code to expose [a]blkciphers via the skcipher API. So switch this driver to the skcipher API, allowing us to finally drop the ablkcipher code in the near future. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-09 18:09:35 +01:00
crypto: brcm - Add Broadcom SPU driver Add Broadcom Secure Processing Unit (SPU) crypto driver for SPU hardware crypto offload. The driver supports ablkcipher, ahash, and aead symmetric crypto operations. Signed-off-by: Steve Lin <steven.lin1@broadcom.com> Signed-off-by: Rob Rice <rob.rice@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-03 12:55:33 -05:00
crypto: stm32 - Support for STM32 CRC32 crypto module This module registers a CRC32 ("Ethernet") and a CRC32C (Castagnoli) algorithm that make use of the STMicroelectronics STM32 crypto hardware. Theses algorithms are compatible with the little-endian generic ones. Both algorithms use ~0 as default seed (key). With CRC32C the output is xored with ~0. Using TCRYPT CRC32C speed test, this shows up to 900% speedup compared to the crc32c-generic algorithm. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-21 16:13:28 +01:00
crypto: inside-secure - add SafeXcel EIP197 crypto engine driver Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used for more advanced operations than the ones supported (as of now), but we still need them to pass the data to the internal cryptographic engine. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 16:10:34 +02:00
crypto: inside-secure - add unspecified HAS_IOMEM dependency Currently CONFIG_CRYPTO_DEV_SAFEXCEL=y implicitly depends on CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get the following build error: ld: drivers/crypto/inside-secure/safexcel.o: in function `safexcel_probe': drivers/crypto/inside-secure/safexcel.c:1692: undefined reference to `devm_platform_ioremap_resource' Fix the build error by adding the unspecified dependency. Reported-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-11 11:27:39 -08:00
crypto: safexcel/aes - switch to library version of key expansion routine Switch to the new AES library that also provides an implementation of the AES key expansion routine. This removes the dependency on the generic AES cipher, allowing it to be omitted entirely in the future. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-07-02 21:41:27 +02:00
crypto: inside-secure - authenc(hmac(sha256), cbc(aes)) support This patch adds support for the first AEAD algorithm in the Inside Secure SafeXcel driver, authenc(hmac(sha256),cbc(aes)). As this is the first AEAD algorithm added to this driver, common AEAD functions are added as well. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-05-14 15:11:02 +02:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: inside-secure - add SafeXcel EIP197 crypto engine driver Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used for more advanced operations than the ones supported (as of now), but we still need them to pass the data to the internal cryptographic engine. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 16:10:34 +02:00
crypto: inside-secure - md5 support This patch adds the MD5 algorithm support to the Inside Secure SafeXcel cryptographic engine driver. Signed-off-by: Ofer Heifetz <oferh@marvell.com> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-06-28 17:21:53 +02:00
crypto: inside-secure - add SafeXcel EIP197 crypto engine driver Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used for more advanced operations than the ones supported (as of now), but we still need them to pass the data to the internal cryptographic engine. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 16:10:34 +02:00
crypto: inside-secure - Add CRYPTO_CHACHA20POLY1305 to CRYPTO_DEV_SAFEXCEL Due to the addition of Chacha20-Poly1305 support to the inside-secure driver, it now depends on CRYPTO_CHACHA20POLY1305. Added reference. changes since v1: - added missing dependency to crypto/Kconfig changes since v2: - nothing changes since v3: - nothing Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-09-18 23:25:58 +02:00
crypto: inside-secure - Add CRYPTO_SHA3 to CRYPTO_DEV_SAFEXCEL Due to the addition of SHA3 and HMAC-SHA3 support to the inside-secure driver, it now depends on CRYPTO_SHA3. Added reference. changes since v1: - added missing dependency to crypto/Kconfig Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-09-13 20:56:49 +02:00
crypto: inside-secure - add SafeXcel EIP197 crypto engine driver Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used for more advanced operations than the ones supported (as of now), but we still need them to pass the data to the internal cryptographic engine. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 16:10:34 +02:00
crypto: inside-secure - make driver selectable for non-Marvell hardware While being a generic EIP97/EIP197 driver, the driver was only selectable for Marvell Armada hardware. This fix makes the driver selectable for any Device Tree supporting kernel configuration, allowing it to be used for other compatible hardware by just adding the correct device tree entry. It also allows the driver to be selected for PCI(E) supporting kernel con- figurations, to be able to use it with PCIE based FPGA development boards for pre-silicon driver development by both Inside Secure and its IP custo- mers. Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com> Acked-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-19 16:40:23 +02:00
crypto: inside-secure - add SafeXcel EIP197 crypto engine driver Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used for more advanced operations than the ones supported (as of now), but we still need them to pass the data to the internal cryptographic engine. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-05-24 16:10:34 +02:00
crypto: axis - add ARTPEC-6/7 crypto accelerator driver This is an asynchronous crypto API driver for the accelerator present in the ARTPEC-6 and -7 SoCs from Axis Communications AB. The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash standards. Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-08-10 14:53:53 +02:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: axis - add ARTPEC-6/7 crypto accelerator driver This is an asynchronous crypto API driver for the accelerator present in the ARTPEC-6 and -7 SoCs from Axis Communications AB. The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash standards. Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-08-10 14:53:53 +02:00
crypto: ccree - introduce CryptoCell driver Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-22 09:27:00 +00:00
crypto: ccree - Depend on HAS_IOMEM Add dependency on HAS_IOMEM as the build will fail without it. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303161354.T2OZFUFZ-lkp@intel.com/ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-03-16 13:30:06 +08:00
crypto: ccree - introduce CryptoCell driver Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-22 09:27:00 +00:00
crypto: skcipher - rename the crypto_blkcipher module and kconfig option Now that the blkcipher algorithm type has been removed in favor of skcipher, rename the crypto_blkcipher kernel module to crypto_skcipher, and rename the config options accordingly: CONFIG_CRYPTO_BLKCIPHER => CONFIG_CRYPTO_SKCIPHER CONFIG_CRYPTO_BLKCIPHER2 => CONFIG_CRYPTO_SKCIPHER2 Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-25 12:41:13 -07:00
crypto: des - split off DES library from generic DES cipher driver Another one for the cipher museum: split off DES core processing into a separate module so other drivers (mostly for crypto accelerators) can reuse the code without pulling in the generic DES cipher itself. This will also permit the cipher interface to be made private to the crypto API itself once we move the only user in the kernel (CIFS) to this library interface. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-15 12:01:09 +03:00
crypto: ccree - introduce CryptoCell driver Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-22 09:27:00 +00:00
crypto: ccree,hisilicon - Fix dependencies to correct algorithm Commit d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory") moves the SM3 and SM4 stand-alone library and the algorithm implementation for the Crypto API into the same directory, and the corresponding relationship of Kconfig is modified, CONFIG_CRYPTO_SM3/4 corresponds to the stand-alone library of SM3/4, and CONFIG_CRYPTO_SM3/4_GENERIC corresponds to the algorithm implementation for the Crypto API. Therefore, it is necessary for this module to depend on the correct algorithm. Fixes: d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory") Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: stable@vger.kernel.org # v5.19+ Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-11-25 20:18:11 +08:00
crypto: sm3 - Rename CRYPTO_SM3_GENERIC to CRYPTO_SM3 The kconfig options for generic crypto API modules have traditionally *not* had a "_GENERIC" suffix. Also, the "_GENERIC" suffix will make even less sense once the architecture-optimized SM3 code is moved into lib/crypto/ and the "sm3" crypto_shash is reimplemented on top of that. Thus, rename CRYPTO_SM3_GENERIC to CRYPTO_SM3. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260321040935.410034-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-03-20 21:09:26 -07:00
crypto: ccree - introduce CryptoCell driver Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-22 09:27:00 +00:00
crypto: ccree - add support for older HW revs Add support for the legacy CryptoCell 630 and 710 revs. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-02-19 14:51:23 +00:00
crypto: ccree - add support for CryptoCell 703 Add support for Arm TrustZone CryptoCell 703. The 703 is a variant of the CryptoCell 713 that supports only algorithms certified by the Chinesse Office of the State Commercial Cryptography Administration (OSCCA). Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-11-13 09:40:35 +00:00
crypto: ccree - introduce CryptoCell driver Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-22 09:27:00 +00:00
crypto: hisilicon - SEC security accelerator driver This accelerator is found inside hisilicon hip06 and hip07 SoCs. Each instance provides a number of queues which feed a different number of backend acceleration units. The queues are operating in an out of order mode in the interests of throughput. The silicon does not do tracking of dependencies between multiple 'messages' or update of the IVs as appropriate for training. Hence where relevant we need to do this in software. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-07-23 16:49:54 +01:00
crypto: amlogic - Add crypto accelerator for amlogic GXL This patch adds support for the amlogic GXL cryptographic offloader present on GXL SoCs. This driver supports AES cipher in CBC/ECB mode. Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-17 05:06:25 +00:00
crypto: sa2ul - Add crypto driver Adds a basic crypto driver and currently supports AES/3DES in cbc mode for both encryption and decryption. Signed-off-by: Keerthy <j-keerthy@ti.com> [t-kristo@ti.com: major re-work to fix various bugs in the driver and to cleanup the code] Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-07-13 11:34:22 +03:00
crypto: sa2ul - Select CRYPTO_AUTHENC The sa2ul driver uses crypto_authenc_extractkeys and therefore must select CRYPTO_AUTHENC. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-09-07 16:22:40 +10:00
crypto: sa2ul - Select CRYPTO_DES The SA2UL Crypto driver provides support for couple of DES3 algos "cbc(des3_ede)" and "ecb(des3_ede)", and enabling the crypto selftest throws the following errors (as seen on K3 J721E SoCs): saul-crypto 4e00000.crypto: Error allocating fallback algo cbc(des3_ede) alg: skcipher: failed to allocate transform for cbc-des3-sa2ul: -2 saul-crypto 4e00000.crypto: Error allocating fallback algo ecb(des3_ede) alg: skcipher: failed to allocate transform for ecb-des3-sa2ul: -2 Fix this by selecting CRYPTO_DES which was missed while adding base driver support. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-03-24 20:28:12 +05:30
crypto: sa2ul - add Kconfig selects to fix build error sa2ul.c uses sha{1,256,512}_zero_message_hash, so select the Kconfig symbols that provide those, like other crypto drivers do. Fixes this build error: ld: drivers/crypto/sa2ul.o: in function `sa_sha_digest': sa2ul.c:(.text+0x2b25): undefined reference to `sha512_zero_message_hash' Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: Randy Dunlap <rdunlap@infradead.org> # 2020-07-29 Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: Tero Kristo <t-kristo@ti.com> Cc: Keerthy <j-keerthy@ti.com> Reviewed-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-08-06 08:54:48 -07:00
crypto: sa2ul - Add crypto driver Adds a basic crypto driver and currently supports AES/3DES in cbc mode for both encryption and decryption. Signed-off-by: Keerthy <j-keerthy@ti.com> [t-kristo@ti.com: major re-work to fix various bugs in the driver and to cleanup the code] Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-07-13 11:34:22 +03:00
crypto: aspeed - Add HACE hash driver Hash and Crypto Engine (HACE) is designed to accelerate the throughput of hash data digest, encryption, and decryption. Basically, HACE can be divided into two independently engines - Hash Engine and Crypto Engine. This patch aims to add HACE hash engine driver for hash accelerator. Signed-off-by: Neal Liu <neal_liu@aspeedtech.com> Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com> Reviewed-by: Dhananjay Phadke <dphadke@linux.microsoft.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-08-18 11:59:52 +08:00
crypto: starfive - Add crypto engine support Adding device probe and DMA init for StarFive cryptographic module. Co-developed-by: Huan Feng <huan.feng@starfivetech.com> Signed-off-by: Huan Feng <huan.feng@starfivetech.com> Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-05-15 20:53:53 +08:00
crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support 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>
2025-01-14 13:36:36 +01:00
crypto: ti - Add driver for DTHE V2 AES Engine (ECB, CBC) Add support for ECB and CBC modes in the AES Engine of the DTHE V2 hardware cryptography engine. Signed-off-by: T Pratham <t-pratham@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-08-20 14:42:27 +05:30
crypto: keembay - Add support for Keem Bay OCS AES/SM4 Add support for the AES/SM4 crypto engine included in the Offload and Crypto Subsystem (OCS) of the Intel Keem Bay SoC, thus enabling hardware-acceleration for the following transformations: - ecb(aes), cbc(aes), ctr(aes), cts(cbc(aes)), gcm(aes) and cbc(aes); supported for 128-bit and 256-bit keys. - ecb(sm4), cbc(sm4), ctr(sm4), cts(cbc(sm4)), gcm(sm4) and cbc(sm4); supported for 128-bit keys. The driver passes crypto manager self-tests, including the extra tests (CRYPTO_MANAGER_EXTRA_TESTS=y). Signed-off-by: Mike Healy <mikex.healy@intel.com> Co-developed-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Acked-by: Mark Gross <mgross@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-11-26 11:51:48 +00:00
Use menuconfig objects: crypto hw Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Cc: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-15 23:39:36 -07:00