aboutsummaryrefslogtreecommitdiff
path: root/arch/arm64/crypto
Commit message (Collapse)AuthorAgeFilesLines
* Revert "GCC: Fix up for gcc 5+"Moyster2018-11-301-1/+0
| | | | This reverts commit ff505baaf412985af758d5820cd620ed9f1a7e05.
* GCC: Fix up for gcc 5+mydongistiny2018-11-291-0/+1
| | | | | Signed-off-by: mydongistiny <jaysonedson@gmail.com> Signed-off-by: Mister Oyster <oysterized@gmail.com>
* crypto: remove duplicate impl.Mister Oyster2017-12-278-4230/+0
| | | | | | | | | | Revert "crypto: arm64/sha2 - add generated .S files to .gitignore" This reverts commit 9345ccbf273209e3946c3981122d068221a135d2. Revert "crypto: arm64/sha2 - integrate OpenSSL implementations of SHA256/SHA512" This reverts commit 02ea19edc643061fab3b6ea8bd54b96110a9f43b.
* backport: crypto: arm64/chacha20 - implement NEON version based on SSE3 codeArd Biesheuvel2017-12-214-0/+596
| | | | | | | | | | | | | | This is a straight port to arm64/NEON of the x86 SSE3 implementation of the ChaCha20 stream cipher. It uses the new skcipher walksize attribute to process the input in strides of 4x the block size. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> backported to 3.10 the same way arm chacha20 SNEON3 imp. for 3.18 was done : https://android-review.googlesource.com/c/kernel/common/+/551349 Signed-off-by: Mister Oyster <oysterized@gmail.com>
* arm64/crypto: issue aese/aesmc instructions in pairsArd Biesheuvel2017-12-212-13/+9
| | | | | | | | | | | | | | | | | | | This changes the AES core transform implementations to issue aese/aesmc (and aesd/aesimc) in pairs. This enables a micro-architectural optimization in recent Cortex-A5x cores that improves performance by 50-90%. Measured performance in cycles per byte (Cortex-A57): CBC enc CBC dec CTR before 3.64 1.34 1.32 after 1.95 0.85 0.93 Note that this results in a ~5% performance decrease for older cores. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 4a97abd44329bf7b9c57f020224da5f823c9c9ea) Change-Id: I9d6b28b9bd9263bb273607590704111529323ca9
* arm64: crypto: increase AES interleave to 4xArd Biesheuvel2017-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch increases the interleave factor for parallel AES modes to 4x. This improves performance on Cortex-A57 by ~35%. This is due to the 3-cycle latency of AES instructions on the A57's relatively deep pipeline (compared to Cortex-A53 where the AES instruction latency is only 2 cycles). At the same time, disable inline expansion of the core AES functions, as the performance benefit of this feature is negligible. Measured on AMD Seattle (using tcrypt.ko mode=500 sec=1): Baseline (2x interleave, inline expansion) ------------------------------------------ testing speed of async cbc(aes) (cbc-aes-ce) decryption test 4 (128 bit key, 8192 byte blocks): 95545 operations in 1 seconds test 14 (256 bit key, 8192 byte blocks): 68496 operations in 1 seconds This patch (4x interleave, no inline expansion) ----------------------------------------------- testing speed of async cbc(aes) (cbc-aes-ce) decryption test 4 (128 bit key, 8192 byte blocks): 124735 operations in 1 seconds test 14 (256 bit key, 8192 byte blocks): 92328 operations in 1 seconds Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 0eee0fbd41c7b57d01136df2519c92ec1506e333) Change-Id: I0fb82b0cc7f685a13c3d15c919be435917e17429
* arm64/crypto: use crypto instructions to generate AES key scheduleArd Biesheuvel2017-12-215-11/+133
| | | | | | | | | | | | | | This patch implements the AES key schedule generation using ARMv8 Crypto Instructions. It replaces the table based C implementation in aes_generic.ko, which means we can drop the dependency on that module. Tested-by: Steve Capper <steve.capper@linaro.org> Acked-by: Steve Capper <steve.capper@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 12ac3efe74f888a13cb4df88b38bb01e8034dea8) Change-Id: I48488f43e280c4de8256365eb0be40d7be26d418
* crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modesArd Biesheuvel2017-12-211-46/+42
| | | | | | | | | | | | | Update the ARMv8 Crypto Extensions and the plain NEON AES implementations in CBC and CTR modes to return the next IV back to the skcipher API client. This is necessary for chaining to work correctly. Note that for CTR, this is only done if the request is a round multiple of the block size, since otherwise, chaining is impossible anyway. Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* arm64: crypto: reduce priority of core AES cipherArd Biesheuvel2017-12-211-1/+1
| | | | | | | | | | | | | | | The asynchronous, merged implementations of AES in CBC, CTR and XTS modes are preferred when available (i.e., when instantiating ablkciphers explicitly). However, the synchronous core AES cipher combined with the generic CBC mode implementation will produce a 'cbc(aes)' blkcipher that is callable asynchronously as well. To prevent this implementation from being used when the accelerated asynchronous implemenation is also available, lower its priority to 250 (i.e., below the asynchronous module's priority of 300). Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
* crypto: arm64/crc32 - bring in line with generic CRC32Ard Biesheuvel2017-12-211-3/+19
| | | | | | | | | The arm64 CRC32 (not CRC32c) implementation was not quite doing the same thing as the generic one. Fix that. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Steve Capper <steve.capper@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: crc32 - Add ARM64 CRC32 hw accelerated moduleYazen Ghannam2017-12-213-0/+282
| | | | | | | | | | | | | | | | This module registers a crc32 algorithm and a crc32c algorithm that use the optional CRC32 and CRC32C instructions in ARMv8. Tested on AMD Seattle. Improvement compared to crc32c-generic algorithm: TCRYPT CRC32C speed test shows ~450% speedup. Simple dd write tests to btrfs filesystem show ~30% speedup. Signed-off-by: Yazen Ghannam <yazen.ghannam@linaro.org> Acked-by: Steve Capper <steve.capper@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: xts - fix compile errorsStephan Mueller2017-08-311-0/+1
| | | | | | | | Commit 28856a9e52c7 missed the addition of the crypto/xts.h include file for different architecture-specific AES implementations. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: xts - consolidate sanity check for keysStephan Mueller2017-08-311-0/+4
| | | | | | | | | | | | | | | The patch centralizes the XTS key check logic into the service function xts_check_key which is invoked from the different XTS implementations. With this, the XTS implementations in ARM, ARM64, PPC and S390 have now a sanity check for the XTS keys similar to the other arches. In addition, this service function received a check to ensure that the key != the tweak key which is mandated by FIPS 140-2 IG A.9. As the check is not present in the standards defining XTS, it is only enforced in FIPS mode of the kernel. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: arm64/aes-ctr - fix NULL dereference in tail processingArd Biesheuvel2017-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | The AES-CTR glue code avoids calling into the blkcipher API for the tail portion of the walk, by comparing the remainder of walk.nbytes modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight into the tail processing block if they are equal. This tail processing block checks whether nbytes != 0, and does nothing otherwise. However, in case of an allocation failure in the blkcipher layer, we may enter this code with walk.nbytes == 0, while nbytes > 0. In this case, we should not dereference the source and destination pointers, since they may be NULL. So instead of checking for nbytes != 0, check for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in non-error conditions. Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions") Cc: stable@vger.kernel.org Reported-by: xiakaixu <xiakaixu@huawei.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* arm64: crypto: assure that ECB modes don't require an IVJeremy Linton2017-08-311-2/+2
| | | | | | | | | ECB modes don't use an initialization vector. The kernel /proc/crypto interface doesn't reflect this properly. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
* arm64/crypto: remove redundant update of dataColin Ian King2017-08-311-1/+0
| | | | | | | | | | | | | | | Originally found by cppcheck: [arch/arm64/crypto/sha2-ce-glue.c:153]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? Updating data by blocks * SHA256_BLOCK_SIZE at the end of sha2_finup is redundant code and can be removed. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
* crypto: arm64/sha2 - add generated .S files to .gitignoreArd Biesheuvel2017-04-161-0/+2
| | | | | | | | | Add the files that are generated by the recently merged OpenSSL SHA-256/512 implementation to .gitignore so Git disregards them when showing untracked files. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: arm64/sha2 - integrate OpenSSL implementations of SHA256/SHA512Ard Biesheuvel2017-04-167-0/+4228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This integrates both the accelerated scalar and the NEON implementations of SHA-224/256 as well as SHA-384/512 from the OpenSSL project. Relative performance compared to the respective generic C versions: | SHA256-scalar | SHA256-NEON* | SHA512 | ------------+-----------------+--------------+----------+ Cortex-A53 | 1.63x | 1.63x | 2.34x | Cortex-A57 | 1.43x | 1.59x | 1.95x | Cortex-A73 | 1.26x | 1.56x | ? | The core crypto code was authored by Andy Polyakov of the OpenSSL project, in collaboration with whom the upstream code was adapted so that this module can be built from the same version of sha512-armv8.pl. The version in this patch was taken from OpenSSL commit 32bbb62ea634 ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.") * The core SHA algorithm is fundamentally sequential, but there is a secondary transformation involved, called the schedule update, which can be performed independently. The NEON version of SHA-224/SHA-256 only implements this part of the algorithm using NEON instructions, the sequential part is always done using scalar instructions. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* first commitMeizu OpenSource2016-08-1515-0/+3231