- 22 Aug, 2019 40 commits
-
-
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 <hdegoede@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
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 <ard.biesheuvel@linaro.org> 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:
-
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:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Cc: Horia Geanta <horia.geanta@nxp.com> Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Signed-off-by:
-
Ard Biesheuvel authored
Switch to the refactored DES key verification routines. While at it, rename the DES encrypt/decrypt routines so they will not conflict with the DES library later on. Signed-off-by:
-
Ard Biesheuvel authored
Switch to the refactored DES key verification routines. While at it, rename the DES encrypt/decrypt routines so they will not conflict with the DES library later on. Reviewed-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
-
Ard Biesheuvel authored
The recently added helper routine to perform key strength validation of triple DES keys is slightly inadequate, since it comes in two versions, neither of which are highly useful for anything other than skciphers (and many drivers still use the older blkcipher interfaces). So let's add a new helper and, considering that this is a helper function that is only intended to be used by crypto code itself, put it in a new des.h header under crypto/internal. While at it, implement a similar helper for single DES, so that we can start replacing the pattern of calling des_ekey() into a temp buffer that occurs in many drivers in drivers/crypto. Signed-off-by:
-
Denis Efremov authored
Fix typo in nx_debugfs.c filepath. File extension changed from .h to .c The file nx_debugfs.h never existed. Cc: Breno Leitão <leitao@debian.org> Cc: Nayna Jain <nayna@linux.ibm.com> Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Denis Efremov <efremov@linux.com> Signed-off-by:
-
Nathan Chancellor authored
Clang errors out when building this macro: lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/mpi/longlong.h:652:20: note: expanded from macro 'umul_ppmm' : "=l" ((USItype)(w0)), \ ~~~~~~~~~~^~~ lib/mpi/generic_mpih-mul1.c:37:3: error: invalid output constraint '=h' in asm umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb); ^ lib/mpi/longlong.h:653:7: note: expanded from macro 'umul_ppmm' "=h" ((USItype)(w1)) \ ^ 2 errors generated. The C version that is used for GCC 4.4 and up works well with clang; however, it is not currently being used because Clang masks itself as GCC 4.2.1 for compatibility reasons. As Nick points out, we require GCC 4.6 and newer in the kernel so we can eliminate all of the versioning checks and just use the C version of umul_ppmm for all supported compilers. Link: https://github.com/ClangBuiltLinux/linux/issues/605Suggested-by:Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
-
Stephen Boyd authored
The kthread calling this function is freezable after commit 03a3bb7a ("hwrng: core - Freeze khwrng thread during suspend") is applied. Unfortunately, this function uses wait_event_interruptible() but doesn't check for the kthread being woken up by the fake freezer signal. When a user suspends the system, this kthread will wake up and if it fails the entropy size check it will immediately go back to sleep and not go into the freezer. Eventually, suspend will fail because the task never froze and a warning message like this may appear: PM: suspend entry (deep) Filesystems sync: 0.000 seconds Freezing user space processes ... (elapsed 0.001 seconds) done. OOM killer disabled. Freezing remaining freezable tasks ... Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): hwrng R running task 0 289 2 0x00000020 [<c08c64c4>] (__schedule) from [<c08c6a10>] (schedule+0x3c/0xc0) [<c08c6a10>] (schedule) from [<c05dbd8c>] (add_hwgenerator_randomness+0xb0/0x100) [<c05dbd8c>] (add_hwgenerator_randomness) from [<bf1803c8>] (hwrng_fillfn+0xc0/0x14c [rng_core]) [<bf1803c8>] (hwrng_fillfn [rng_core]) from [<c015abec>] (kthread+0x134/0x148) [<c015abec>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Check for a freezer signal here and skip adding any randomness if the task wakes up because it was frozen. This should make the kthread freeze properly and suspend work again. Fixes: 03a3bb7a ("hwrng: core - Freeze khwrng thread during suspend") Reported-by:
Keerthy <j-keerthy@ti.com> Tested-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
