aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-02-10crypto: arm64/aes-ccm - Rewrite skcipher walker loopHerbert Xu1-31/+26
An often overlooked aspect of the skcipher walker API is that an error is not just indicated by a non-zero return value, but by the fact that walk->nbytes is zero. Thus it is an error to call skcipher_walk_done after getting back walk->nbytes == 0 from the previous interaction with the walker. This is because when walk->nbytes is zero the walker is left in an undefined state and any further calls to it may try to free uninitialised stack memory. The arm64 ccm code has to deal with zero-length messages, and it needs to process data even when walk->nbytes == 0 is returned. It doesn't have this bug because there is an explicit check for walk->nbytes != 0 prior to the skcipher_walk_done call. However, the loop is still sufficiently different from the usual layout and it appears to have been copied into other code which then ended up with this bug. This patch rewrites it to follow the usual convention of checking walk->nbytes. Signed-off-by: Herbert Xu <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-10MAINTAINERS: repair file entry for STARFIVE TRNG DRIVERLukas Bulwahn1-1/+1
Commit c388f458bc34 ("hwrng: starfive - Add TRNG driver for StarFive SoC") adds the STARFIVE TRNG DRIVER section to MAINTAINERS, but refers to the non-existing file drivers/char/hw_random/starfive-trng.c rather than to the actually added file drivers/char/hw_random/jh7110-trng.c in this commit. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Repair this file entry in STARFIVE TRNG DRIVER. Fixes: c388f458bc34 ("hwrng: starfive - Add TRNG driver for StarFive SoC") Signed-off-by: Lukas Bulwahn <[email protected]> Acked-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-10Documentation: qat: change kernel versionMeadhbh1-2/+2
Change kernel version from 5.20 to 6.0, as 5.20 is not a release. Signed-off-by: Meadhbh Fitzpatrick <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Reviewed-by: Vladis Dronov <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03hwrng: starfive - Enable compile testingHerbert Xu1-2/+1
Enable compile testing for jh7110. Also remove the dependency on HW_RANDOM. Signed-off-by: Herbert Xu <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Reviewed-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: ux500/hash - delete driverLinus Walleij7-2414/+0
It turns out we can just modify the newer STM32 HASH driver to be used with Ux500 and now that we have done that, delete the old and sparsely maintained Ux500 HASH driver. Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: stm32/hash - Support Ux500 hashLinus Walleij1-35/+219
The Ux500 has a hash block which is an ancestor to the STM32 hash block. With some minor code path additions we can support also this variant in the STM32 driver. Differences: - Ux500 only supports SHA1 and SHA256 (+/- MAC) so we split up the algorithm registration per-algorithm and register each algorithm along with its MAC variant separately. - Ux500 does not have an interrupt to indicate that hash calculation is complete, so we add code paths to handle polling for completion if the interrupt is missing in the device tree. - Ux500 is lacking the SR status register, to check if an operating is complete, we need to poll the HASH_STR_DCAL bit in the HASH_STR register instead. - Ux500 had the resulting hash at address offset 0x0c and 8 32bit registers ahead. We account for this with a special code path when reading out the hash digest. - Ux500 need a special bit set in the control register before performing the final hash calculation on an empty message. - Ux500 hashes on empty messages will be performed if the above bit is set, but are incorrect. For this reason we just make an inline synchronous hash using a fallback hash. Tested on the Ux500 Golden device with the extended tests. Acked-by: Lionel Debieve <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: stm32/hash - Wait for idle before final CPU xmitLinus Walleij1-0/+3
When calculating the hash using the CPU, right before the final hash calculation, heavy testing on Ux500 reveals that it is wise to wait for the hardware to go idle before calculating the final hash. The default test vectors mostly worked fine, but when I used the extensive tests and stress the hardware I ran into this problem. Acked-by: Lionel Debieve <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: stm32/hash - Use existing busy poll functionLinus Walleij1-2/+4
When exporting state we are waiting indefinitely in the same was as the ordinary stm32_hash_wait_busy() poll-for-completion function but without a timeout, which means we could hang in an eternal loop. Fix this by waiting for completion like the rest of the code. Acked-by: Lionel Debieve <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: stm32/hash - Simplify codeLinus Walleij1-2/+1
We are passing (rctx->flags & HASH_FLAGS_FINUP) as indicator for the final request but we already know this to be true since we are in the (final) arm of an if-statement set from the same flag. Just open-code it as true. Acked-by: Lionel Debieve <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03dt-bindings: crypto: Let STM32 define Ux500 HASHLinus Walleij1-1/+22
This adds device tree bindings for the Ux500 HASH block as a compatible in the STM32 HASH bindings. The Ux500 HASH binding has been used for ages in the kernel device tree for Ux500 but was never documented, so fill in the gap by making it a sibling of the STM32 HASH block, which is what it is. The relationship to the existing STM32 HASH block is pretty obvious when looking at the register map, and I have written patches to reuse the STM32 HASH driver on the Ux500. The main difference from the outside is that the Ux500 HASH lacks the interrupt line, so some special if-clauses are needed to accomodate this in the binding. Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: marvell/cesa - Use crypto_wait_reqHerbert Xu1-33/+8
This patch replaces the custom crypto completion function with crypto_req_done. Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: img-hash - Fix sparse endianness warningHerbert Xu1-4/+4
Use cpu_to_be32 instead of be32_to_cpu in img_hash_read_result_queue to silence sparse. The generated code should be identical. Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: ccp - Flush the SEV-ES TMR memory before giving it to firmwareTom Lendacky1-1/+5
Perform a cache flush on the SEV-ES TMR memory after allocation to prevent any possibility of the firmware encountering an error should dirty cache lines be present. Use clflush_cache_range() to flush the SEV-ES TMR memory. Fixes: 97f9ac3db661 ("crypto: ccp - Add support for SEV-ES to the PSP driver") Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: qat - add qat_zlib_deflateLucas Segarra Fernandez1-12/+154
The ZLIB format (RFC 1950) is made of deflate compressed data surrounded by a header and a footer. The QAT accelerators support only the deflate algorithm, therefore the header and the footer need to be inserted in software. This adds logic in the QAT driver to support the ZLIB format. In particular: * Generalize the function qat_comp_alg_compress_decompress() to allow skipping an initial region (header) of the source and/or destination scatter lists. * Add logic to register the qat_zlib_deflate algorithm into the acomp framework. * For ZLIB compression, skip the initial portion of the destination buffer before sending the job to the QAT accelerator and insert the ZLIB header and footer in the callback, after the QAT request has been processed. * For ZLIB decompression, parse the header in the input buffer provided by the user and verify its validity before attempting the decompression of the buffer with QAT. Then submit the buffer to QAT for decompression. In the callback verify the correctness of the footer by comparing the value of the ADLER produced by QAT with the one in the destination buffer. Signed-off-by: Lucas Segarra Fernandez <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: qat - extend buffer list logic interfaceLucas Segarra Fernandez3-5/+37
Extend qat_bl_sgl_to_bufl() to allow skipping the mapping of a region of the source and the destination scatter lists starting from byte zero. This is to support the ZLIB format (RFC 1950) in the qat driver. The ZLIB format is made of deflate compressed data surrounded by a header and a footer. The QAT accelerators support only the deflate algorithm, therefore the header should not be mapped since it is inserted in software. Signed-off-by: Lucas Segarra Fernandez <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-02-03Revert "crypto: rsa-pkcs1pad - Replace GFP_ATOMIC with GFP_KERNEL in ↵Herbert Xu1-1/+1
pkcs1pad_encrypt_sign_complete" This reverts commit 1ca2809897155f1adc43e4859b4a3582e235c09a. While the akcipher API as a whole is designed to be called only from thread context, its completion path is still called from softirq context as usual. Therefore we must not use GFP_KERNEL on that path. Signed-off-by: Herbert Xu <[email protected]>
2023-02-03crypto: x86 - exit fpu context earlier in ECB/CBC macrosPeter Lafreniere1-4/+15
Currently the ecb/cbc macros hold fpu context unnecessarily when using scalar cipher routines (e.g. when handling odd sizes of blocks per walk). Change the macros to drop fpu context as soon as the fpu is out of use. No performance impact found (on Intel Haswell). Signed-off-by: Peter Lafreniere <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: engine - Fix excess parameter doc warningHerbert Xu1-1/+1
The engine parameter should not be marked for kernel doc as it triggers a warning. Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: xts - Handle EBUSY correctlyHerbert Xu1-4/+4
As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. Fixes: 8083b1bf8163 ("crypto: xts - add support for ciphertext stealing") Signed-off-by: Herbert Xu <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: caam - Use ahash_request_completeHerbert Xu2-6/+6
Instead of calling the base completion function directly, use the correct ahash helper which is ahash_request_complete. Signed-off-by: Herbert Xu <[email protected]> Reviewed-by: Gaurav Jain <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: bcm - Use subrequest for fallbackHerbert Xu2-70/+37
Instead of doing saving and restoring on the AEAD request object for fallback processing, use a subrequest instead. Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: cryptd - Remove unnecessary skcipher_request_zeroHerbert Xu1-2/+0
Previously the child skcipher request was stored on the stack and therefore needed to be zeroed. As it is now dynamically allocated we no longer need to do so. Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: aspeed - Use devm_platform_get_and_ioremap_resource()ye xingchen1-4/+1
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: ye xingchen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: aspeed - change aspeed_acry_akcipher_algs to staticYang Yingliang1-1/+1
aspeed_acry_akcipher_algs is only used in aspeed-acry.c now, change it to static. Signed-off-by: Yang Yingliang <[email protected]> Acked-by: Andrew Jeffery <[email protected]> Reviewed-by: Neal Liu <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: testmgr - disallow certain DRBG hash functions in FIPS modeVladis Dronov1-4/+0
According to FIPS 140-3 IG, section D.R "Hash Functions Acceptable for Use in the SP 800-90A DRBGs", modules certified after May 16th, 2023 must not support the use of: SHA-224, SHA-384, SHA512-224, SHA512-256, SHA3-224, SHA3-384. Disallow HMAC and HASH DRBGs using SHA-384 in FIPS mode. Signed-off-by: Vladis Dronov <[email protected]> Reviewed-by: Stephan Müller <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27hwrng: starfive - Add TRNG driver for StarFive SoCJia Jie Ho4-0/+411
This adds driver support for the hardware random number generator in Starfive SoCs and adds StarFive TRNG entry to MAINTAINERS. Co-developed-by: Jenny Zhang <[email protected]> Signed-off-by: Jenny Zhang <[email protected]> Signed-off-by: Jia Jie Ho <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27dt-bindings: rng: Add StarFive TRNG moduleJia Jie Ho1-0/+55
Add documentation to describe Starfive true random number generator module. Co-developed-by: Jenny Zhang <[email protected]> Signed-off-by: Jenny Zhang <[email protected]> Signed-off-by: Jia Jie Ho <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: ccp - Add a firmware definition for EPYC gen 4 processorsTom Lendacky1-0/+1
Add a new MODULE_FIRMWARE() entry for 4th generation EPYC processors. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-27crypto: ccp - Provide MMIO register naming for documenationTom Lendacky1-23/+23
Add comments next to the version data MMIO register values to identify the register name being used. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: x86/aria-avx512 - fix build failure with old binutilsTaehee Yoo1-1/+1
The minimum version of binutils for kernel build is currently 2.23 and it doesn't support GFNI. So, it fails to build the aria-avx512 if the old binutils is used. aria-avx512 requires GFNI, so it should not be allowed to build if the old binutils is used. The AS_AVX512 and AS_GFNI are added to the Kconfig to disable build aria-avx512 if the old binutils is used. Fixes: c970d42001f2 ("crypto: x86/aria - implement aria-avx512") Reported-by: Jan Beulich <[email protected]> Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: x86/aria-avx2 - fix build failure with old binutilsTaehee Yoo2-2/+12
The minimum version of binutils for kernel build is currently 2.23 and it doesn't support GFNI. So, it fails to build the aria-avx2 if the old binutils is used. The code using GFNI is an optional part of aria-avx2. So, it disables GFNI part in it when the old binutils is used. Fixes: 37d8d3ae7a58 ("crypto: x86/aria - implement aria-avx2") Reported-by: Jan Beulich <[email protected]> Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: x86/aria-avx - fix build failure with old binutilsTaehee Yoo3-1/+18
The minimum version of binutils for kernel build is currently 2.23 and it doesn't support GFNI. So, it fails to build the aria-avx if the old binutils is used. The code using GFNI is an optional part of aria-avx. So, it disables GFNI part in it when the old binutils is used. In order to check whether the using binutils is supporting GFNI or not, AS_GFNI is added. Fixes: ba3579e6e45c ("crypto: aria-avx - add AES-NI/AVX/x86_64/GFNI assembler implementation of aria cipher") Reported-by: Jan Beulich <[email protected]> Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: seqiv - Handle EBUSY correctlyHerbert Xu1-1/+1
As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. Fixes: 0a270321dbf9 ("[CRYPTO] seqiv: Add Sequence Number IV Generator") Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: essiv - Handle EBUSY correctlyHerbert Xu1-1/+6
As it is essiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of essiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. Fixes: be1eb7f78aa8 ("crypto: essiv - create wrapper template...") Signed-off-by: Herbert Xu <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: atmel-i2c - avoid defines prefixed with CONFIGLukas Bulwahn2-2/+2
Defines prefixed with "CONFIG" should be limited to proper Kconfig options, that are introduced in a Kconfig file. Here, a definition for the driver's configuration zone is named CONFIG_ZONE. Rename this local definition to CONFIGURATION_ZONE to avoid defines prefixed with "CONFIG". No functional change. Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: qat - fix spelling mistakes from 'bufer' to 'buffer'Meadhbh Fitzpatrick3-45/+45
Fix spelling mistakes from 'bufer' to 'buffer' in qat_common. Also fix indentation issue caused by the spelling change. Signed-off-by: Meadhbh Fitzpatrick <[email protected]> Reviewed-by: Ilpo Järvinen <[email protected]> Reviewed-by: Giovanni Cabiddu <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: hisilicon - remove redundant config PCI dependency for some ↵Lukas Bulwahn1-4/+4
CRYPTO_DEV_HISI configs While reviewing dependencies in some Kconfig files, I noticed the redundant dependency "depends on PCI && PCI_MSI". The config PCI_MSI has always, since its introduction, been dependent on the config PCI. So, it is sufficient to just depend on PCI_MSI, and know that the dependency on PCI is implicitly implied. Reduce the dependencies of configs CRYPTO_DEV_HISI_SEC2, CRYPTO_DEV_HISI_QM, CRYPTO_DEV_HISI_ZIP and CRYPTO_DEV_HISI_HPRE. No functional change and effective change of Kconfig dependendencies. Signed-off-by: Lukas Bulwahn <[email protected]> Acked-by: Weili Qian <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: stm32 - Use accelerated readsl/writeslLinus Walleij1-26/+11
When reading or writing crypto buffers the inner loops can be replaced with readsl and writesl which will on ARM result in a tight assembly loop, speeding up encryption/decryption a little bit. This optimization was in the Ux500 driver so let's carry it over to the STM32 driver. Cc: Maxime Coquelin <[email protected]> Cc: Alexandre Torgue <[email protected]> Cc: Lionel Debieve <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: aspeed - Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
Zero-length arrays are deprecated[1] and we are moving towards adopting C99 flexible-array members instead. So, replace zero-length array declaration in struct aspeed_sham_ctx with flex-array member. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [2]. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Neal Liu <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: ccp - Failure on re-initialization due to duplicate sysfs filenameKoba Ko1-4/+17
The following warning appears during the CCP module re-initialization: [ 140.965403] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:07.1/0000:03:00.2/dma/dma0chan0' [ 140.975736] CPU: 0 PID: 388 Comm: kworker/0:2 Kdump: loaded Not tainted 6.2.0-0.rc2.18.eln124.x86_64 #1 [ 140.985185] Hardware name: HPE ProLiant DL325 Gen10/ProLiant DL325 Gen10, BIOS A41 07/17/2020 [ 140.993761] Workqueue: events work_for_cpu_fn [ 140.998151] Call Trace: [ 141.000613] <TASK> [ 141.002726] dump_stack_lvl+0x33/0x46 [ 141.006415] sysfs_warn_dup.cold+0x17/0x23 [ 141.010542] sysfs_create_dir_ns+0xba/0xd0 [ 141.014670] kobject_add_internal+0xba/0x260 [ 141.018970] kobject_add+0x81/0xb0 [ 141.022395] device_add+0xdc/0x7e0 [ 141.025822] ? complete_all+0x20/0x90 [ 141.029510] __dma_async_device_channel_register+0xc9/0x130 [ 141.035119] dma_async_device_register+0x19e/0x3b0 [ 141.039943] ccp_dmaengine_register+0x334/0x3f0 [ccp] [ 141.045042] ccp5_init+0x662/0x6a0 [ccp] [ 141.049000] ? devm_kmalloc+0x40/0xd0 [ 141.052688] ccp_dev_init+0xbb/0xf0 [ccp] [ 141.056732] ? __pci_set_master+0x56/0xd0 [ 141.060768] sp_init+0x70/0x90 [ccp] [ 141.064377] sp_pci_probe+0x186/0x1b0 [ccp] [ 141.068596] local_pci_probe+0x41/0x80 [ 141.072374] work_for_cpu_fn+0x16/0x20 [ 141.076145] process_one_work+0x1c8/0x380 [ 141.080181] worker_thread+0x1ab/0x380 [ 141.083953] ? __pfx_worker_thread+0x10/0x10 [ 141.088250] kthread+0xda/0x100 [ 141.091413] ? __pfx_kthread+0x10/0x10 [ 141.095185] ret_from_fork+0x2c/0x50 [ 141.098788] </TASK> [ 141.100996] kobject_add_internal failed for dma0chan0 with -EEXIST, don't try to register things with the same name in the same directory. [ 141.113703] ccp 0000:03:00.2: ccp initialization failed The /dma/dma0chan0 sysfs file is not removed since dma_chan object has been released in ccp_dma_release() before releasing dma device. A correct procedure would be: release dma channels first => unregister dma device => release ccp dma object. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216888 Fixes: 68dbe80f5b51 ("crypto: ccp - Release dma channels before dmaengine unrgister") Tested-by: Vladis Dronov <[email protected]> Signed-off-by: Koba Ko <[email protected]> Reviewed-by: Vladis Dronov <[email protected]> Acked-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: aead - fix inaccurate documentationArd Biesheuvel1-10/+10
The AEAD documentation conflates associated data and authentication tags: the former (along with the ciphertext) is authenticated by the latter. Fix the doc accordingly. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: tcrypt - include larger key sizes in RFC4106 benchmarkArd Biesheuvel2-5/+5
RFC4106 wraps AES in GCM mode, and can be used with larger key sizes than 128/160 bits, just like AES itself. So add these to the tcrypt recipe so they will be benchmarked as well. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-20crypto: arm64/gcm - add RFC4106 supportArd Biesheuvel1-38/+107
Add support for RFC4106 ESP encapsulation to the accelerated GCM implementation. This results in a ~10% speedup for IPsec frames of typical size (~1420 bytes) on Cortex-A53. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-18crypto: p10-aes-gcm - Revert implementationHerbert Xu7-6330/+0
Revert the changes that added p10-aes-gcm: 0781bbd7eaca ("crypto: p10-aes-gcm - A perl script to process PowerPC assembler source") 41a6437ab415 ("crypto: p10-aes-gcm - Supporting functions for ghash") 3b47eccaaff4 ("crypto: p10-aes-gcm - Supporting functions for AES") ca68a96c37eb ("crypto: p10-aes-gcm - An accelerated AES/GCM stitched implementation") cc40379b6e19 ("crypto: p10-aes-gcm - Glue code for AES/GCM stitched implementation") 3c657e8689ab ("crypto: p10-aes-gcm - Update Kconfig and Makefile") These changes fail to build in many configurations and are not ready for prime time. Signed-off-by: Herbert Xu <[email protected]>
2023-01-13crypto: sun8i-ce - Add TRNG clock to the D1 variantSamuel Holland2-1/+2
At least the D1 variant requires a separate clock for the TRNG. Without this clock enabled, reading from /dev/hwrng reports: sun8i-ce 3040000.crypto: DMA timeout for TRNG (tm=96) on flow 3 Experimentation shows that the necessary clock is the SoC's internal RC oscillator. This makes sense, as noise from the oscillator can be used as a source of entropy. Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Acked-by: Corentin Labbe <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-13dt-bindings: crypto: sun8i-ce: Add compatible for D1Samuel Holland1-8/+25
D1 has a crypto engine similar to the one in other Allwinner SoCs. Like H6, it has a separate MBUS clock gate. It also requires the internal RC oscillator to be enabled for the TRNG to return data, presumably because noise from the oscillator is used as an entropy source. This is likely the case for earlier variants as well, but it really only matters for H616 and newer SoCs, as H6 provides no way to disable the internal oscillator. Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Acked-by: Corentin Labbe <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-13dt-bindings: bus: add documentation for Aspeed AHBCNeal Liu1-0/+37
Add device tree binding documentation for the Aspeed Advanced High-Performance Bus (AHB) Controller. Signed-off-by: Neal Liu <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-13dt-bindings: crypto: add documentation for Aspeed ACRYNeal Liu2-1/+50
Add device tree binding documentation for the Aspeed ECDSA/RSA ACRY Engines Controller. Signed-off-by: Neal Liu <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-13ARM: dts: aspeed: Add ACRY/AHBC device controller nodeNeal Liu1-0/+13
Add acry & ahbc node to device tree for AST2600. Signed-off-by: Neal Liu <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-01-13crypto: aspeed - Add ACRY RSA driverNeal Liu3-0/+841
ACRY Engine is designed to accelerate the throughput of ECDSA/RSA signature and verification. This patch aims to add ACRY RSA engine driver for hardware acceleration. Signed-off-by: Neal Liu <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.