summaryrefslogtreecommitdiff
path: root/drivers/crypto/Kconfig
AgeCommit message (Collapse)AuthorFilesLines
2019-05-30crypto: atmel-i2c - add support for SHA204A random number generatorArd Biesheuvel1-0/+14
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-30crypto: atmel-ecc - factor out code that can be sharedArd Biesheuvel1-0/+4
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-30crypto: atmel-ecc - add support for ACPI probing on non-AT91 platformsArd Biesheuvel1-1/+0
The Atmel/Microchip EC508A is a I2C device that could be wired into any platform, and is being used on the Linaro/96boards Secure96 mezzanine adapter. This means it could be found on any platform, even on ones that use ACPI enumeration (via PRP0001 devices). So update the code to enable this use case. This involves tweaking the bus rate discovery code to take ACPI probing into account, which records the maximum bus rate as a property of the slave device. For the atmel-ecc code, this means that the effective bus rate should never exceed the maximum rate, unless we are dealing with buggy firmware. Nonetheless, let's just use the existing plumbing to discover the bus rate and keep the existing logic intact. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-04-16crypto: mxc-scc - Remove broken driverHerbert Xu1-9/+0
This driver has been completely broken since the very beginning because it doesn't even have a setkey function. This means that nobody has ever used it as it would crash during setkey. This patch removes this driver. Fixes: d293b640ebd5 ("crypto: mxc-scc - add basic driver for the...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-01-10crypto: bcm - convert to use crypto_authenc_extractkeys()Eric Biggers1-0/+1
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-30Merge tag 'kconfig-v4.21' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kconfig updates from Masahiro Yamada: - support -y option for merge_config.sh to avoid downgrading =y to =m - remove S_OTHER symbol type, and touch include/config/*.h files correctly - fix file name and line number in lexer warnings - fix memory leak when EOF is encountered in quotation - resolve all shift/reduce conflicts of the parser - warn no new line at end of file - make 'source' statement more strict to take only string literal - rewrite the lexer and remove the keyword lookup table - convert to SPDX License Identifier - compile C files independently instead of including them from zconf.y - fix various warnings of gconfig - misc cleanups * tag 'kconfig-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits) kconfig: surround dbg_sym_flags with #ifdef DEBUG to fix gconf warning kconfig: split images.c out of qconf.cc/gconf.c to fix gconf warnings kconfig: add static qualifiers to fix gconf warnings kconfig: split the lexer out of zconf.y kconfig: split some C files out of zconf.y kconfig: convert to SPDX License Identifier kconfig: remove keyword lookup table entirely kconfig: update current_pos in the second lexer kconfig: switch to ASSIGN_VAL state in the second lexer kconfig: stop associating kconf_id with yylval kconfig: refactor end token rules kconfig: stop supporting '.' and '/' in unquoted words treewide: surround Kconfig file paths with double quotes microblaze: surround string default in Kconfig with double quotes kconfig: use T_WORD instead of T_VARIABLE for variables kconfig: use specific tokens instead of T_ASSIGN for assignments kconfig: refactor scanning and parsing "option" properties kconfig: use distinct tokens for type and default properties kconfig: remove redundant token defines kconfig: rename depends_list to comment_option_list ...
2018-12-21treewide: surround Kconfig file paths with double quotesMasahiro Yamada1-1/+1
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-07crypto: ccree - add support for CryptoCell 703Gilad Ben-Yossef1-1/+1
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-09crypto: ccree - add SM3 supportYael Chemla1-0/+1
Add support for SM3 cipher in CryptoCell 713. Signed-off-by: Yael Chemla <yael.chemla@foss.arm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-11-09crypto: ccree - add SM4 supportGilad Ben-Yossef1-0/+1
Add support for SM4 cipher in CryptoCell 713. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-11-09crypto: ccree - add support for CryptoCell 713Gilad Ben-Yossef1-1/+1
Add support for Arm TrustZone CryptoCell 713. Note that this patch just enables using a 713 in backwards compatible mode to 712. Newer 713 specific features will follow. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-10-08s390/zcrypt: multiple zcrypt device nodes supportHarald Freudenberger1-0/+11
This patch is an extension to the zcrypt device driver to provide, support and maintain multiple zcrypt device nodes. The individual zcrypt device nodes can be restricted in terms of crypto cards, domains and available ioctls. Such a device node can be used as a base for container solutions like docker to control and restrict the access to crypto resources. The handling is done with a new sysfs subdir /sys/class/zcrypt. Echoing a name (or an empty sting) into the attribute "create" creates a new zcrypt device node. In /sys/class/zcrypt a new link will appear which points to the sysfs device tree of this new device. The attribute files "ioctlmask", "apmask" and "aqmask" in this directory are used to customize this new zcrypt device node instance. Finally the zcrypt device node can be destroyed by echoing the name into /sys/class/zcrypt/destroy. The internal structs holding the device info are reference counted - so a destroy will not hard remove a device but only marks it as removable when the reference counter drops to zero. The mask values are bitmaps in big endian order starting with bit 0. So adapter number 0 is the leftmost bit, mask is 0x8000... The sysfs attributes accept 2 different formats: * Absolute hex string starting with 0x like "0x12345678" does set the mask starting from left to right. If the given string is shorter than the mask it is padded with 0s on the right. If the string is longer than the mask an error comes back (EINVAL). * Relative format - a concatenation (done with ',') of the terms +<bitnr>[-<bitnr>] or -<bitnr>[-<bitnr>]. <bitnr> may be any valid number (hex, decimal or octal) in the range 0...255. Here are some examples: "+0-15,+32,-128,-0xFF" "-0-255,+1-16,+0x128" "+1,+2,+3,+4,-5,-7-10" A simple usage examples: # create new zcrypt device 'my_zcrypt': echo "my_zcrypt" >/sys/class/zcrypt/create # go into the device dir of this new device echo "my_zcrypt" >create cd my_zcrypt/ ls -l total 0 -rw-r--r-- 1 root root 4096 Jul 20 15:23 apmask -rw-r--r-- 1 root root 4096 Jul 20 15:23 aqmask -r--r--r-- 1 root root 4096 Jul 20 15:23 dev -rw-r--r-- 1 root root 4096 Jul 20 15:23 ioctlmask lrwxrwxrwx 1 root root 0 Jul 20 15:23 subsystem -> ../../../../class/zcrypt ... # customize this zcrypt node clone # enable only adapter 0 and 2 echo "0xa0" >apmask # enable only domain 6 echo "+6" >aqmask # enable all 256 ioctls echo "+0-255" >ioctls # now the /dev/my_zcrypt may be used # finally destroy it echo "my_zcrypt" >/sys/class/zcrypt/destroy Please note that a very similar 'filtering behavior' also applies to the parent z90crypt device. The two mask attributes apmask and aqmask in /sys/bus/ap act the very same for the z90crypt device node. However the implementation here is totally different as the ap bus acts on bind/unbind of queue devices and associated drivers but the effect is still the same. So there are two filters active for each additional zcrypt device node: The adapter/domain needs to be enabled on the ap bus level and it needs to be active on the zcrypt device node level. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-08-03crypto: hisilicon - SEC security accelerator driverJonathan Cameron1-0/+2
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-27crypto: qcom-rng - Add Qcom prng driverVinod Koul1-0/+11
This ports the Qcom prng from older hw_random driver. No change of functionality and move from hw_random to crypto APIs is done. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-07-08crypto: inside-secure - ecb(des) and cbc(des) supportOfer Heifetz1-0/+1
This patch adds support for two algorithms in the Inside Secure SafeXcel cryptographic engine driver: ecb(des) and cbc(des). 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-07-08crypto: inside-secure - md5 supportOfer Heifetz1-0/+1
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-05-26crypto: inside-secure - authenc(hmac(sha256), cbc(aes)) supportAntoine Tenart1-0/+1
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-04-28crypto: crypto4xx - add aes-ctr supportChristian Lamparter1-0/+1
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-28crypto: drivers - Remove depends on HAS_DMA in case of platform dependencyGeert Uytterhoeven1-10/+4
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-03-23crypto: bfin_crc - remove blackfin CRC driverArnd Bergmann1-7/+0
The blackfin architecture is getting removed, so this driver won't be used any more. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-03-02crypto: ccree - add support for older HW revsGilad Ben-Yossef1-3/+3
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-15crypto: ccree - introduce CryptoCell driverGilad Ben-Yossef1-0/+27
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-25crypto: artpec6 - remove select on non-existing CRYPTO_SHA384Corentin LABBE1-1/+0
Since CRYPTO_SHA384 does not exists, Kconfig should not select it. Anyway, all SHA384 stuff is in CRYPTO_SHA512 which is already selected. Fixes: a21eb94fc4d3i ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-11-03crypto: s5p-sss - Add HASH support for ExynosKamil Konieczny1-0/+14
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-11-03crypto: marvell - Remove the old mv_cesa driverBoris BREZILLON1-19/+3
All defconfigs selecting the old driver have been patched to select the new one instead. We can now remove the old driver along with the allhwsupports module parameter in the new driver that was used to check whether the new driver was allowed to take control of the CESA engine or not. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-10-12crypto: crypto4xx - prepare for AEAD supportChristian Lamparter1-0/+4
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-08-22crypto: axis - add ARTPEC-6/7 crypto accelerator driverLars Persson1-0/+21
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-07-18crypto: ccp - Introduce the AMD Secure Processor deviceBrijesh Singh1-3/+3
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-18crypto: atmel-ecc - introduce Microchip / Atmel ECC driverTudor-Dan Ambarus1-0/+14
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-18crypto: sun4i-ss - support the Security System PRNGCorentin LABBE1-0/+8
The Security System has a PRNG, this patch adds support for it via crypto_rng. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-18crypto: brcm - remove BCM_PDC_MBOX dependency in Kconfigraveendra padasalagi1-1/+1
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-05Merge branch 'linus' of ↵Linus Torvalds1-0/+30
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto updates from Herbert Xu: "Algorithms: - add private key generation to ecdh Drivers: - add generic gcm(aes) to aesni-intel - add SafeXcel EIP197 crypto engine driver - add ecb(aes), cfb(aes) and ecb(des3_ede) to cavium - add support for CNN55XX adapters in cavium - add ctr mode to chcr - add support for gcm(aes) to omap" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (140 commits) crypto: testmgr - Reenable sha1/aes in FIPS mode crypto: ccp - Release locks before returning crypto: cavium/nitrox - dma_mapping_error() returns bool crypto: doc - fix typo in docs Documentation/bindings: Document the SafeXel cryptographic engine driver crypto: caam - fix gfp allocation flags (part II) crypto: caam - fix gfp allocation flags (part I) crypto: drbg - Fixes panic in wait_for_completion call crypto: caam - make of_device_ids const. crypto: vmx - remove unnecessary check crypto: n2 - make of_device_ids const crypto: inside-secure - use the base_end pointer in ring rollback crypto: inside-secure - increase the batch size crypto: inside-secure - only dequeue when needed crypto: inside-secure - get the backlog before dequeueing the request crypto: inside-secure - stop requeueing failed requests crypto: inside-secure - use one queue per hw ring crypto: inside-secure - update the context and request later crypto: inside-secure - align the cipher and hash send functions crypto: inside-secure - optimize DSE bufferability control ...
2017-06-12s390/crypto: fix aes/paes Kconfig dependenyHarald Freudenberger1-1/+14
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-06-10crypto: cavium - Add support for CNN55XX adapters.Srikanth Jampala1-0/+1
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-06-10crypto: inside-secure - add SafeXcel EIP197 crypto engine driverAntoine Ténart1-0/+17
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-06-10crypto: omap-aes - Add support for GCM modeTero Kristo1-0/+1
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-06-10crypto: omap - add base support library for common routinesTero Kristo1-0/+11
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-04-21crypto: exynos - Add new Exynos RNG driverKrzysztof Kozlowski1-0/+15
Replace existing hw_ranndom/exynos-rng driver with a new, reworked one. This is a driver for pseudo random number generator block which on Exynos4 chipsets must be seeded with some value. On newer Exynos5420 chipsets it might seed itself from true random number generator block but this is not implemented yet. New driver is a complete rework to use the crypto ALGAPI instead of hw_random API. Rationale for the change: 1. hw_random interface is for true RNG devices. 2. The old driver was seeding itself with jiffies which is not a reliable source for randomness. 3. Device generates five random 32-bit numbers in each pass but old driver was returning only one 32-bit number thus its performance was reduced. Compatibility with DeviceTree bindings is preserved. New driver does not use runtime power management but manually enables and disables the clock when needed. This is preferred approach because using runtime PM just to toggle clock is huge overhead. Another difference is reseeding itself with generated random data periodically and during resuming from system suspend (previously driver was re-seeding itself again with jiffies). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Stephan Müller <smueller@chronox.de> Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-04-05crypto: stm32 - Support for STM32 CRC32 crypto moduleFabien DESSENNE1-0/+2
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-09crypto: zip - Add ThunderX ZIP driver coreMahipal Challa1-0/+7
Add a driver for the ZIP engine found on Cavium ThunderX SOCs. The ZIP engine supports hardware accelerated compression and decompression. It includes 2 independent ZIP cores and supports: - DEFLATE compression and decompression (RFC 1951) - LZS compression and decompression (RFC 2395 and ANSI X3.241-1994) - ADLER32 and CRC32 checksums for ZLIB (RFC 1950) and GZIP (RFC 1952) The ZIP engine is presented as a PCI device. It supports DMA and scatter-gather. Signed-off-by: Mahipal Challa <Mahipal.Challa@cavium.com> Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-04Merge branch 'linus' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: - vmalloc stack regression in CCM - Build problem in CRC32 on ARM - Memory leak in cavium - Missing Kconfig dependencies in atmel and mediatek - XTS Regression on some platforms (s390 and ppc) - Memory overrun in CCM test vector * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: vmx - Use skcipher for xts fallback crypto: vmx - Use skcipher for cbc fallback crypto: testmgr - Pad aes_ccm_enc_tv_template vector crypto: arm/crc32 - add build time test for CRC instruction support crypto: arm/crc32 - fix build error with outdated binutils crypto: ccm - move cbcmac input off the stack crypto: xts - Propagate NEED_FALLBACK bit crypto: api - Add crypto_requires_off helper crypto: atmel - CRYPTO_DEV_MEDIATEK should depend on HAS_DMA crypto: atmel - CRYPTO_DEV_ATMEL_TDES and CRYPTO_DEV_ATMEL_SHA should depend on HAS_DMA crypto: cavium - fix leak on curr if curr->head fails to be allocated crypto: cavium - Fix couple of static checker errors
2017-02-28Merge branch 'for-linus' of ↵Linus Torvalds1-9/+23
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull more s390 updates from Martin Schwidefsky: "Next to the usual bug fixes (including the TASK_SIZE fix), there is one larger crypto item. It allows to use protected keys with the in-kernel crypto API The protected key support has two parts, the pkey user space API to convert key formats and the paes crypto module that uses a protected key instead of a standard AES key" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: TASK_SIZE for kernel threads s390/crypt: Add protected key AES module s390/dasd: fix spelling mistake: "supportet" -> "supported" s390/pkey: Introduce pkey kernel module s390/zcrypt: export additional symbols s390/zcrypt: Rework CONFIG_ZCRYPT Kconfig text. s390/zcrypt: Cleanup leftover module code. s390/nmi: purge tlbs after control register validation s390/nmi: fix order of register validation s390/crypto: Add PCKMO inline function s390/zcrypt: Enable request count reset for cards and queues. s390/mm: use _SEGMENT_ENTRY_EMPTY in the code s390/chsc: Add exception handler for CHSC instruction s390: opt into HAVE_COPY_THREAD_TLS s390: restore address space when returning to user space s390: rename CIF_ASCE to CIF_ASCE_PRIMARY
2017-02-27crypto: atmel - CRYPTO_DEV_MEDIATEK should depend on HAS_DMAGeert Uytterhoeven1-0/+1
If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/crypto/mediatek/mtk-crypto.ko] undefined! Add a dependency on HAS_DMA to fix this. Fixes: 7dee9f618790d0b7 ("crypto: mediatek - remove ARM dependencies") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-27crypto: atmel - CRYPTO_DEV_ATMEL_TDES and CRYPTO_DEV_ATMEL_SHA should depend ↵Geert Uytterhoeven1-0/+2
on HAS_DMA If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/crypto/atmel-tdes.ko] undefined! ERROR: "bad_dma_ops" [drivers/crypto/atmel-sha.ko] undefined! Add dependencies on HAS_DMA to fix this. Fixes: ceb4afb3086ab08f ("crypto: atmel - refine Kconfig dependencies") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-24s390/crypt: Add protected key AES moduleMartin Schwidefsky1-0/+1
This patch introduces a new in-kernel-crypto blockcipher called 'paes' which implements AES with protected keys. The paes blockcipher can be used similar to the aes blockcipher but uses secure key material to derive the working protected key and so offers an encryption implementation where never a clear key value is exposed in memory. The paes module is only available for the s390 platform providing a minimal hardware support of CPACF enabled with at least MSA level 3. Upon module initialization these requirements are checked. Includes additional contribution from Harald Freudenberger. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-02-23s390/pkey: Introduce pkey kernel moduleHarald Freudenberger1-0/+16
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>
2017-02-23s390/zcrypt: Rework CONFIG_ZCRYPT Kconfig text.Harald Freudenberger1-9/+6
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-11crypto: brcm - Add Broadcom SPU driverRob Rice1-0/+15
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-11crypto: cavium - Enable CPT options crypto for buildGeorge Cherian1-0/+1
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-11crypto: atmel - refine Kconfig dependenciesArnd Bergmann1-4/+5
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>