- 30 Aug, 2019 10 commits
-
-
Pascal van Leeuwen authored
This patch adds support for a PCIE development board with FPGA from Xilinx, to facilitate pre-silicon driver development by both Inside Secure and its IP customers. Since Inside Secure neither produces nor has access to actual silicon, this is required functionality to allow us to contribute. 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>
-
Pascal van Leeuwen authored
This removes some code determine which engine has which algorithms which was effectively redundant (may have been forward-looking?) due to always enabling all algorithms for all currently supported engines. A future patch will use a different, more scalable approach to achieve this. This is removed now because otherwise the next patch will add new hardware which would otherwise have to be added to all algorithms, so now is a convenient time to just get rid of this. Signed-off-by:
-
Pascal van Leeuwen authored
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:
-
Ard Biesheuvel authored
Align the s5p ctr(aes) implementation with other implementations of the same mode, by setting the block size to 1. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
Kamil Konieczny <k.konieczny@partner.samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Ard Biesheuvel authored
The s5p skcipher driver returns -EINVAL for zero length inputs, which deviates from the behavior of the generic ECB template, and causes fuzz tests to fail. In cases where the input is not a multiple of the AES block size (and the chaining mode is not CTR), it prints an error to the kernel log, which is a thing we usually try to avoid in response to situations that can be triggered by unprivileged users. Signed-off-by:
-
Ard Biesheuvel authored
Add an accelerated version of the 'essiv(cbc(aes),sha256)' skcipher, which is used by fscrypt or dm-crypt on systems where CBC mode is signficantly more performant than XTS mode (e.g., when using a h/w accelerator which supports the former but not the latter) This avoids a separate call into the AES cipher for every invocation. Signed-off-by:
-
Ard Biesheuvel authored
The plain CBC driver and the CTS one share some code that iterates over a scatterwalk and invokes the CBC asm code to do the processing. The upcoming ESSIV/CBC mode will clone that pattern for the third time, so let's factor it out first. Signed-off-by:
-
Ard Biesheuvel authored
Add a test vector for the ESSIV mode that is the most widely used, i.e., using cbc(aes) and sha256, in both skcipher and AEAD modes (the latter is used by tcrypt to encapsulate the authenc template or h/w instantiations of the same) Signed-off-by:
-
Ard Biesheuvel authored
When building the new aegis128 NEON code in big endian mode, Clang complains about the const uint8x16_t permute vectors in the following way: crypto/aegis128-neon-inner.c:58:40: warning: vector initializers are not compatible with NEON intrinsics in big endian mode [-Wnonportable-vector-initialization] static const uint8x16_t shift_rows = { ^ crypto/aegis128-neon-inner.c:58:40: note: consider using vld1q_u8() to initialize a vector from memory, or vcombine_u8(vcreate_u8(), vcreate_u8()) to initialize from integer constants Since the same issue applies to the uint8x16x4_t loads of the AES Sbox, update those references as well. However, since GCC does not implement the vld1q_u8_x4() intrinsic, switch from IS_ENABLED() to a preprocessor conditional to conditionally include this code. Reported-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
The help section says that the module will be called 'pipcoxcell_crypto'. This is likely a typo. Use 'picoxcell_crypto' instead Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
- 22 Aug, 2019 30 commits
-
-
Herbert Xu authored
This patch removes the variable flags which is now unused thanks to the new DES helpers. Fixes: 9d574ae8 ("crypto: talitos/des - switch to new...") Signed-off-by:
-
Ard Biesheuvel authored
Fix build breakage caused by the DES library refactor. Fixes: d4b90dbc ("crypto: n2/des - switch to new verification routines") Signed-off-by:
-
Ard Biesheuvel authored
Fix a typo XTS_BLOCKSIZE -> XTS_BLOCK_SIZE, causing the build to break. Fixes: ce68acbc ("crypto: s390/xts-aes - invoke fallback for...") Signed-off-by:
-
Hans de Goede authored
Drop the duplicate generic sha256 (and sha224) implementation from crypto/sha256_generic.c and use the implementation from lib/crypto/sha256.c instead. "diff -u lib/crypto/sha256.c sha256_generic.c" shows that the core sha256_transform function from both implementations is identical and the other code is functionally identical too. Suggested-by:
Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Add sha224 support to the lib/crypto/sha256 library code. This will allow us to replace both the sha256 and sha224 parts of crypto/sha256_generic.c when we remove the code duplication in further patches in this series. Suggested-by:
-
Hans de Goede authored
Before this commit lib/crypto/sha256.c has only been used in the s390 and x86 purgatory code, make it suitable for generic use: * Export interesting symbols * Add -D__DISABLE_EXPORTS to CFLAGS_sha256.o for purgatory builds to avoid the exports for the purgatory builds * Add to lib/crypto/Makefile and crypto/Kconfig Signed-off-by:
-
Hans de Goede authored
Use get/put_unaligned_be32 in lib/crypto/sha256.c to load / store data so that it can be used with unaligned buffers too, making it more generic. And use memzero_explicit for better clearing of sensitive data. Note unlike other patches in this series this commit actually makes functional changes to the sha256 code as used by the purgatory code. This fully aligns the lib/crypto/sha256.c sha256 implementation with the one from crypto/sha256_generic.c allowing us to remove the latter in further patches in this series. Signed-off-by:
-
Hans de Goede authored
Generic crypto implementations belong under lib/crypto not directly in lib, likewise the header should be in include/crypto, not include/linux. Note that the code in lib/crypto/sha256.c is not yet available for generic use after this commit, it is still only used by the s390 and x86 purgatory code. Making it suitable for generic use is done in further patches in this series. Signed-off-by:
-
Hans de Goede authored
Add a bunch of missing spaces after commas and arround operators. Note the main goal of this is to make sha256_transform and its helpers identical in formatting too the duplcate implementation in lib/sha256.c, so that "diff -u" can be used to compare them to prove that no functional changes are made when further patches in this series consolidate the 2 implementations into 1. Signed-off-by:
-
Hans de Goede authored
For some reason after the first 15 steps the last statement of each step ends with "t1+t2", missing spaces around the "+". This commit fixes this. This was done with a 's/= t1+t2/= t1 + t2/' to make sure no functional changes are introduced. Note the main goal of this is to make lib/sha256.c's sha256_transform and its helpers identical in formatting too the duplcate implementation in crypto/sha256_generic.c so that "diff -u" can be used to compare them to prove that no functional changes are made when further patches in this series consolidate the 2 implementations into 1. Signed-off-by:
-
Ard Biesheuvel authored
For correctness and compliance with the XTS-AES specification, we are adding support for ciphertext stealing to XTS implementations, even though no use cases are known that will be enabled by this. Since the Power8 implementation already has a fallback skcipher standby for other purposes, let's use it for this purpose as well. If ciphertext stealing use cases ever become a bottleneck, we can always revisit this. Signed-off-by:
-
Ard Biesheuvel authored
For correctness and compliance with the XTS-AES specification, we are adding support for ciphertext stealing to XTS implementations, even though no use cases are known that will be enabled by this. Since the s390 implementation already has a fallback skcipher standby for other purposes, let's use it for this purpose as well. If ciphertext stealing use cases ever become a bottleneck, we can always revisit this. Signed-off-by:
-
Ard Biesheuvel authored
Align the x86 code with the generic XTS template, which now supports ciphertext stealing as described by the IEEE XTS-AES spec P1619. Tested-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Herbert Xu authored
This patch fixes a printk format warning by replacing %p with %#llx for dma_addr_t. Signed-off-by: -
Ard Biesheuvel authored
Some legacy code in the CIFS driver uses single DES to calculate some password hash, and uses the crypto cipher API to do so. Given that there is no point in invoking an accelerated cipher for doing 56-bit symmetric encryption on a single 8-byte block of input, the flexibility of the crypto cipher API does not add much value here, and so we're much better off using a library call into the generic C implementation. Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
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 authored
Remove the old DES3 verification functions that are no longer used. Signed-off-by:
-
Ard Biesheuvel authored
In preparation of moving the shared key expansion routine into the DES library, move the verification done by __des3_ede_setkey() into its callers. Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Cc: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Ard Biesheuvel authored
Cc: Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
