summaryrefslogtreecommitdiffstats
path: root/crypto
Commit message (Collapse)AuthorAgeFilesLines
...
| * | crypto: scompress - Use per-CPU struct instead multiple variablesSebastian Andrzej Siewior2019-04-081-71/+54Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two per-CPU variables are allocated as pointer to per-CPU memory which then are used as scratch buffers. We could be smart about this and use instead a per-CPU struct which contains the pointers already and then we need to allocate just the scratch buffers. Add a lock to the struct. By doing so we can avoid the get_cpu() statement and gain lockdep coverage (if enabled) to ensure that the lock is always acquired in the right context. On non-preemptible kernels the lock vanishes. It is okay to use raw_cpu_ptr() in order to get a pointer to the struct since it is protected by the spinlock. The diffstat of this is negative and according to size scompress.o: text data bss dec hex filename 1847 160 24 2031 7ef dbg_before.o 1754 232 4 1990 7c6 dbg_after.o 1799 64 24 1887 75f no_dbg-before.o 1703 88 4 1795 703 no_dbg-after.o The overall size increase difference is also negative. The increase in the data section is only four bytes without lockdep. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: scompress - return proper error code for allocation failureSebastian Andrzej Siewior2019-04-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If scomp_acomp_comp_decomp() fails to allocate memory for the destination then we never copy back the data we compressed. It is probably best to return an error code instead 0 in case of failure. I haven't found any user that is using acomp_request_set_params() without the `dst' buffer so there is probably no harm. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: fips - Grammar s/options/option/, s/to/the/Geert Uytterhoeven2019-03-281-2/+2
| | | | | | | | | | | | | | | | | | | | | Fixes: ccb778e1841ce04b ("crypto: api - Add fips_enable flag") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: Kconfig - fix typos AEGSI -> AEGISOndrej Mosnacek2019-03-221-3/+3
| | | | | | | | | | | | | | | | | | | | | Spotted while reviewind patches from Eric Biggers. Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: salsa20-generic - use crypto_xor_cpy()Eric Biggers2019-03-221-5/+4Star
| | | | | | | | | | | | | | | | | | | | | | | | In salsa20_docrypt(), use crypto_xor_cpy() instead of crypto_xor(). This avoids having to memcpy() the src buffer to the dst buffer. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: chacha-generic - use crypto_xor_cpy()Eric Biggers2019-03-221-5/+3Star
| | | | | | | | | | | | | | | | | | | | | | | | In chacha_docrypt(), use crypto_xor_cpy() instead of crypto_xor(). This avoids having to memcpy() the src buffer to the dst buffer. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: testmgr - test the !may_use_simd() fallback codeEric Biggers2019-03-221-24/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All crypto API algorithms are supposed to support the case where they are called in a context where SIMD instructions are unusable, e.g. IRQ context on some architectures. However, this isn't tested for by the self-tests, causing bugs to go undetected. Now that all algorithms have been converted to use crypto_simd_usable(), update the self-tests to test the no-SIMD case. First, a bool testvec_config::nosimd is added. When set, the crypto operation is executed with preemption disabled and with crypto_simd_usable() mocked out to return false on the current CPU. A bool test_sg_division::nosimd is also added. For hash algorithms it's honored by the corresponding ->update(). By setting just a subset of these bools, the case where some ->update()s are done in SIMD context and some are done in no-SIMD context is also tested. These bools are then randomly set by generate_random_testvec_config(). For now, all no-SIMD testing is limited to the extra crypto self-tests, because it might be a bit too invasive for the regular self-tests. But this could be changed later. This has already found bugs in the arm64 AES-GCM and ChaCha algorithms. This would have found some past bugs as well. Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: simd - convert to use crypto_simd_usable()Eric Biggers2019-03-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Replace all calls to may_use_simd() in the shared SIMD helpers with crypto_simd_usable(), in order to allow testing the no-SIMD code paths. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: simd,testmgr - introduce crypto_simd_usable()Eric Biggers2019-03-221-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that the no-SIMD fallback code can be tested by the crypto self-tests, add a macro crypto_simd_usable() which wraps may_use_simd(), but also returns false if the crypto self-tests have set a per-CPU bool to disable SIMD in crypto code on the current CPU. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: chacha-generic - fix use as arm64 no-NEON fallbackEric Biggers2019-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The arm64 implementations of ChaCha and XChaCha are failing the extra crypto self-tests following my patches to test the !may_use_simd() code paths, which previously were untested. The problem is as follows: When !may_use_simd(), the arm64 NEON implementations fall back to the generic implementation, which uses the skcipher_walk API to iterate through the src/dst scatterlists. Due to how the skcipher_walk API works, walk.stride is set from the skcipher_alg actually being used, which in this case is the arm64 NEON algorithm. Thus walk.stride is 5*CHACHA_BLOCK_SIZE, not CHACHA_BLOCK_SIZE. This unnecessarily large stride shouldn't cause an actual problem. However, the generic implementation computes round_down(nbytes, walk.stride). round_down() assumes the round amount is a power of 2, which 5*CHACHA_BLOCK_SIZE is not, so it gives the wrong result. This causes the following case in skcipher_walk_done() to be hit, causing a WARN() and failing the encryption operation: if (WARN_ON(err)) { /* unexpected case; didn't process all bytes */ err = -EINVAL; goto finish; } Fix it by rounding down to CHACHA_BLOCK_SIZE instead of walk.stride. (Or we could replace round_down() with rounddown(), but that would add a slow division operation every time, which I think we should avoid.) Fixes: 2fe55987b262 ("crypto: arm64/chacha - use combined SIMD/ALU routine for more speed") Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: testmgr - remove workaround for AEADs that modify aead_requestEric Biggers2019-03-221-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that all AEAD algorithms (that I have the hardware to test, at least) have been fixed to not modify the user-provided aead_request, remove the workaround from testmgr that reset aead_request::tfm after each AEAD encryption/decryption. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: x86/morus1280 - convert to use AEAD SIMD helpersEric Biggers2019-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the x86 implementations of MORUS-1280 to use the AEAD SIMD helpers, rather than hand-rolling the same functionality. This simplifies the code and also fixes the bug where the user-provided aead_request is modified. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: x86/morus640 - convert to use AEAD SIMD helpersEric Biggers2019-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the x86 implementation of MORUS-640 to use the AEAD SIMD helpers, rather than hand-rolling the same functionality. This simplifies the code and also fixes the bug where the user-provided aead_request is modified. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: x86/aegis256 - convert to use AEAD SIMD helpersEric Biggers2019-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the x86 implementation of AEGIS-256 to use the AEAD SIMD helpers, rather than hand-rolling the same functionality. This simplifies the code and also fixes the bug where the user-provided aead_request is modified. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: x86/aegis128l - convert to use AEAD SIMD helpersEric Biggers2019-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the x86 implementation of AEGIS-128L to use the AEAD SIMD helpers, rather than hand-rolling the same functionality. This simplifies the code and also fixes the bug where the user-provided aead_request is modified. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: x86/aegis128 - convert to use AEAD SIMD helpersEric Biggers2019-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the x86 implementation of AEGIS-128 to use the AEAD SIMD helpers, rather than hand-rolling the same functionality. This simplifies the code and also fixes the bug where the user-provided aead_request is modified. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | crypto: simd - support wrapping AEAD algorithmsEric Biggers2019-03-221-0/+269
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the crypto_simd module to support wrapping AEAD algorithms. Previously it only supported skciphers. The code for each is similar. I'll be converting the x86 implementations of AES-GCM, AEGIS, and MORUS to use this. Currently they each independently implement the same functionality. This will not only simplify the code, but it will also fix the bug detected by the improved self-tests: the user-provided aead_request is modified. This is because these algorithms currently reuse the original request, whereas the crypto_simd helpers build a new request in the original request's context. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | | crypto: lrw - Fix atomic sleep when walking skcipherHerbert Xu2019-04-181-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we perform a walk in the completion function, we need to ensure that it is atomic. Fixes: ac3c8f36c31d ("crypto: lrw - Do not use auxiliary buffer") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | | crypto: xts - Fix atomic sleep when walking skcipherHerbert Xu2019-04-181-1/+5
| |/ |/| | | | | | | | | | | | | | | | | | | | | When we perform a walk in the completion function, we need to ensure that it is atomic. Reported-by: syzbot+6f72c20560060c98b566@syzkaller.appspotmail.com Fixes: 78105c7e769b ("crypto: xts - Drop use of auxiliary buffer") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: x86/poly1305 - fix overflow during partial reductionEric Biggers2019-04-081-1/+43
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The x86_64 implementation of Poly1305 produces the wrong result on some inputs because poly1305_4block_avx2() incorrectly assumes that when partially reducing the accumulator, the bits carried from limb 'd4' to limb 'h0' fit in a 32-bit integer. This is true for poly1305-generic which processes only one block at a time. However, it's not true for the AVX2 implementation, which processes 4 blocks at a time and therefore can produce intermediate limbs about 4x larger. Fix it by making the relevant calculations use 64-bit arithmetic rather than 32-bit. Note that most of the carries already used 64-bit arithmetic, but the d4 -> h0 carry was different for some reason. To be safe I also made the same change to the corresponding SSE2 code, though that only operates on 1 or 2 blocks at a time. I don't think it's really needed for poly1305_block_sse2(), but it doesn't hurt because it's already x86_64 code. It *might* be needed for poly1305_2block_sse2(), but overflows aren't easy to reproduce there. This bug was originally detected by my patches that improve testmgr to fuzz algorithms against their generic implementation. But also add a test vector which reproduces it directly (in the AVX2 case). Fixes: b1ccc8f4b631 ("crypto: poly1305 - Add a four block AVX2 variant for x86_64") Fixes: c70f4abef07a ("crypto: poly1305 - Add a SSE2 SIMD variant for x86_64") Cc: <stable@vger.kernel.org> # v4.3+ Cc: Martin Willi <martin@strongswan.org> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Martin Willi <martin@strongswan.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* lib/lzo: separate lzo-rle from lzoDave Rodgman2019-03-083-3/+178
| | | | | | | | | | | | | | | | | | | | To prevent any issues with persistent data, separate lzo-rle from lzo so that it is treated as a separate algorithm, and lzo is still available. Link: http://lkml.kernel.org/r/20190205155944.16007-3-dave.rodgman@arm.com Signed-off-by: Dave Rodgman <dave.rodgman@arm.com> Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com> Cc: Matt Sealey <matt.sealey@arm.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Nitin Gupta <nitingupta910@gmail.com> Cc: Richard Purdie <rpurdie@openedhand.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Sonny Rao <sonnyrao@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'linus' of ↵Linus Torvalds2019-03-0533-8975/+6499Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto update from Herbert Xu: "API: - Add helper for simple skcipher modes. - Add helper to register multiple templates. - Set CRYPTO_TFM_NEED_KEY when setkey fails. - Require neither or both of export/import in shash. - AEAD decryption test vectors are now generated from encryption ones. - New option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS that includes random fuzzing. Algorithms: - Conversions to skcipher and helper for many templates. - Add more test vectors for nhpoly1305 and adiantum. Drivers: - Add crypto4xx prng support. - Add xcbc/cmac/ecb support in caam. - Add AES support for Exynos5433 in s5p. - Remove sha384/sha512 from artpec7 as hardware cannot do partial hash" [ There is a merge of the Freescale SoC tree in order to pull in changes required by patches to the caam/qi2 driver. ] * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (174 commits) crypto: s5p - add AES support for Exynos5433 dt-bindings: crypto: document Exynos5433 SlimSSS crypto: crypto4xx - add missing of_node_put after of_device_is_available crypto: cavium/zip - fix collision with generic cra_driver_name crypto: af_alg - use struct_size() in sock_kfree_s() crypto: caam - remove redundant likely/unlikely annotation crypto: s5p - update iv after AES-CBC op end crypto: x86/poly1305 - Clear key material from stack in SSE2 variant crypto: caam - generate hash keys in-place crypto: caam - fix DMA mapping xcbc key twice crypto: caam - fix hash context DMA unmap size hwrng: bcm2835 - fix probe as platform device crypto: s5p-sss - Use AES_BLOCK_SIZE define instead of number crypto: stm32 - drop pointless static qualifier in stm32_hash_remove() crypto: chelsio - Fixed Traffic Stall crypto: marvell - Remove set but not used variable 'ivsize' crypto: ccp - Update driver messages to remove some confusion crypto: adiantum - add 1536 and 4096-byte test vectors crypto: nhpoly1305 - add a test vector with len % 16 != 0 crypto: arm/aes-ce - update IV after partial final CTR block ...
| * crypto: af_alg - use struct_size() in sock_kfree_s()Gustavo A. R. Silva2019-02-281-2/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, change the following form: sizeof(*sgl) + sizeof(sgl->sg[0]) * (MAX_SGL_ENTS + 1) to : struct_size(sgl, sg, MAX_SGL_ENTS + 1) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: adiantum - add 1536 and 4096-byte test vectorsEric Biggers2019-02-221-0/+2860
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 1536 and 4096-byte Adiantum test vectors so that the case where there are multiple NH hashes is tested. This is already tested by the nhpoly1305 test vectors, but it should be tested at the Adiantum level too. Moreover the 4096-byte case is especially important. As with the other Adiantum test vectors, these were generated by the reference Python implementation at https://github.com/google/adiantum and then automatically formatted for testmgr by a script. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: nhpoly1305 - add a test vector with len % 16 != 0Eric Biggers2019-02-221-0/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed to test that the end of the message is zero-padded when the length is not a multiple of 16 (NH_MESSAGE_UNIT). It's already tested indirectly by the 31-byte Adiantum test vector, but it should be tested directly at the nhpoly1305 level too. As with the other nhpoly1305 test vectors, this was generated by the reference Python implementation at https://github.com/google/adiantum and then automatically formatted for testmgr by a script. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - add iv_out to all CTR test vectorsEric Biggers2019-02-221-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test that all CTR implementations update the IV buffer to contain the next counter block, aka the IV to continue the encryption/decryption of a larger message. When the length processed is a multiple of the block size, users may rely on this for chaining. When the length processed is *not* a multiple of the block size, simple chaining doesn't work. However, as noted in commit 88a3f582bea9 ("crypto: arm64/aes - don't use IV buffer to return final keystream block"), the generic CCM implementation assumes that the CTR IV is handled in some sane way, not e.g. overwritten with part of the keystream. Since this was gotten wrong once already, it's desirable to test for it. And, the most straightforward way to do this is to enforce that all CTR implementations have the same behavior as the generic implementation, which returns the *next* counter following the final partial block. This behavior also has the advantage that if someone does misuse this case for chaining, then the keystream won't be repeated. Thus, this patch makes the tests expect this behavior. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - add iv_out to all CBC test vectorsEric Biggers2019-02-221-0/+48
| | | | | | | | | | | | | | | | | | Test that all CBC implementations update the IV buffer to contain the last ciphertext block, aka the IV to continue the encryption/decryption of a larger message. Users may rely on this for chaining. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - support checking skcipher output IVEric Biggers2019-02-222-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | Allow skcipher test vectors to declare the value the IV buffer should be updated to at the end of the encryption or decryption operation. (This check actually used to be supported in testmgr, but it was never used and therefore got removed except for the AES-Keywrap special case. But it will be used by CBC and CTR now, so re-add it.) Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - remove extra bytes from 3DES-CTR IVsEric Biggers2019-02-221-4/+2Star
| | | | | | | | | | | | | | | | 3DES only has an 8-byte block size, but the 3DES-CTR test vectors use 16-byte IVs. Remove the unused 8 bytes from the ends of the IVs. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: export arc4 definesIuliana Prodan2019-02-151-4/+1Star
| | | | | | | | | | | | | | | | | | | | Some arc4 cipher algorithm defines show up in two places: crypto/arc4.c and drivers/crypto/bcm/cipher.h. Let's export them in a common header and update their users. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - check for aead_request corruptionEric Biggers2019-02-081-0/+44
| | | | | | | | | | | | | | | | | | Check that algorithms do not change the aead_request structure, as users may rely on submitting the request again (e.g. after copying new data into the same source buffer) without reinitializing everything. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - check for skcipher_request corruptionEric Biggers2019-02-081-0/+41
| | | | | | | | | | | | | | | | | | Check that algorithms do not change the skcipher_request structure, as users may rely on submitting the request again (e.g. after copying new data into the same source buffer) without reinitializing everything. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - convert hash testing to use testvec_configsEric Biggers2019-02-082-550/+352Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert alg_test_hash() to use the new test framework, adding a list of testvec_configs to test by default. When the extra self-tests are enabled, randomly generated testvec_configs are tested as well. This improves hash test coverage mainly because now all algorithms have a variety of data layouts tested, whereas before each algorithm was responsible for declaring its own chunked test cases which were often missing or provided poor test coverage. The new code also tests both the MAY_SLEEP and !MAY_SLEEP cases and buffers that cross pages. This already found bugs in the hash walk code and in the arm32 and arm64 implementations of crct10dif. I removed the hash chunked test vectors that were the same as non-chunked ones, but left the ones that were unique. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - convert aead testing to use testvec_configsEric Biggers2019-02-082-475/+185Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert alg_test_aead() to use the new test framework, using the same list of testvec_configs that skcipher testing uses. This significantly improves AEAD test coverage mainly because previously there was only very limited test coverage of the possible data layouts. Now the data layouts to test are listed in one place for all algorithms and optionally are also randomly generated. In fact, only one AEAD algorithm (AES-GCM) even had a chunked test case before. This already found bugs in all the AEGIS and MORUS implementations, the x86 AES-GCM implementation, and the arm64 AES-CCM implementation. I removed the AEAD chunked test vectors that were the same as non-chunked ones, but left the ones that were unique. Note: the rewritten test code allocates an aead_request just once per algorithm rather than once per encryption/decryption, but some AEAD algorithms incorrectly change the tfm pointer in the request. It's nontrivial to fix these, so to move forward I'm temporarily working around it by resetting the tfm pointer. But they'll need to be fixed. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - convert skcipher testing to use testvec_configsEric Biggers2019-02-082-523/+245Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert alg_test_skcipher() to use the new test framework, adding a list of testvec_configs to test by default. When the extra self-tests are enabled, randomly generated testvec_configs are tested as well. This improves skcipher test coverage mainly because now all algorithms have a variety of data layouts tested, whereas before each algorithm was responsible for declaring its own chunked test cases which were often missing or provided poor test coverage. The new code also tests both the MAY_SLEEP and !MAY_SLEEP cases, different IV alignments, and buffers that cross pages. This has already found a bug in the arm64 ctr-aes-neonbs algorithm. It would have easily found many past bugs. I removed the skcipher chunked test vectors that were the same as non-chunked ones, but left the ones that were unique. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - implement random testvec_config generationEric Biggers2019-02-081-0/+117
| | | | | | | | | | | | | | | | Add functions that generate a random testvec_config, in preparation for using it for randomized fuzz tests. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - introduce CONFIG_CRYPTO_MANAGER_EXTRA_TESTSEric Biggers2019-02-082-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To achieve more comprehensive crypto test coverage, I'd like to add fuzz tests that use random data layouts and request flags. To be most effective these tests should be part of testmgr, so they automatically run on every algorithm registered with the crypto API. However, they will take much longer to run than the current tests and therefore will only really be intended to be run by developers, whereas the current tests have a wider audience. Therefore, add a new kconfig option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS that can be set by developers to enable these extra, expensive tests. Similar to the regular tests, also add a module parameter cryptomgr.noextratests to support disabling the tests. Finally, another module parameter cryptomgr.fuzz_iterations is added to control how many iterations the fuzz tests do. Note: for now setting this to 0 will be equivalent to cryptomgr.noextratests=1. But I opted for separate parameters to provide more flexibility to add other types of tests under the "extra tests" category in the future. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - add testvec_config struct and helper functionsEric Biggers2019-02-081-15/+437
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Crypto algorithms must produce the same output for the same input regardless of data layout, i.e. how the src and dst scatterlists are divided into chunks and how each chunk is aligned. Request flags such as CRYPTO_TFM_REQ_MAY_SLEEP must not affect the result either. However, testing of this currently has many gaps. For example, individual algorithms are responsible for providing their own chunked test vectors. But many don't bother to do this or test only one or two cases, providing poor test coverage. Also, other things such as misaligned IVs and CRYPTO_TFM_REQ_MAY_SLEEP are never tested at all. Test code is also duplicated between the chunked and non-chunked cases, making it difficult to make other improvements. To improve the situation, this patch series basically moves the chunk descriptions into the testmgr itself so that they are shared by all algorithms. However, it's done in an extensible way via a new struct 'testvec_config', which describes not just the scaled chunk lengths but also all other aspects of the crypto operation besides the data itself such as the buffer alignments, the request flags, whether the operation is in-place or not, the IV alignment, and for hash algorithms when to do each update() and when to use finup() vs. final() vs. digest(). Then, this patch series makes skcipher, aead, and hash algorithms be tested against a list of default testvec_configs, replacing the current test code. This improves overall test coverage, without reducing test performance too much. Note that the test vectors themselves are not changed, except for removing the chunk lists. This series also adds randomized fuzz tests, enabled by a new kconfig option intended for developer use only, where skcipher, aead, and hash algorithms are tested against many randomly generated testvec_configs. This provides much more comprehensive test coverage. These improved tests have already exposed many bugs. To start it off, this initial patch adds the testvec_config and various helper functions that will be used by the skcipher, aead, and hash test code that will be converted to use the new testvec_config framework. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ahash - fix another early termination in hash walkEric Biggers2019-02-081-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and "michael_mic", fail the improved hash tests because they sometimes produce the wrong digest. The bug is that in the case where a scatterlist element crosses pages, not all the data is actually hashed because the scatterlist walk terminates too early. This happens because the 'nbytes' variable in crypto_hash_walk_done() is assigned the number of bytes remaining in the page, then later interpreted as the number of bytes remaining in the scatterlist element. Fix it. Fixes: 900a081f6912 ("crypto: ahash - Fix early termination in hash walk") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: morus - fix handling chunked inputsEric Biggers2019-02-082-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The generic MORUS implementations all fail the improved AEAD tests because they produce the wrong result with some data layouts. The issue is that they assume that if the skcipher_walk API gives 'nbytes' not aligned to the walksize (a.k.a. walk.stride), then it is the end of the data. In fact, this can happen before the end. Fix them. Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: aegis - fix handling chunked inputsEric Biggers2019-02-083-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The generic AEGIS implementations all fail the improved AEAD tests because they produce the wrong result with some data layouts. The issue is that they assume that if the skcipher_walk API gives 'nbytes' not aligned to the walksize (a.k.a. walk.stride), then it is the end of the data. In fact, this can happen before the end. Fix them. Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations") Cc: <stable@vger.kernel.org> # v4.18+ Cc: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - use kmemdupChristopher Diaz Riveros2019-02-081-6/+3Star
| | | | | | | | | | | | | | | | | | | | | | Fixes coccinnelle alerts: /crypto/testmgr.c:2112:13-20: WARNING opportunity for kmemdup /crypto/testmgr.c:2130:13-20: WARNING opportunity for kmemdup /crypto/testmgr.c:2152:9-16: WARNING opportunity for kmemdup Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - mark crc32 checksum as FIPS allowedMilan Broz2019-02-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The CRC32 is not a cryptographic hash algorithm, so the FIPS restrictions should not apply to it. (The CRC32C variant is already allowed.) This CRC32 variant is used for in dm-crypt legacy TrueCrypt IV implementation (tcw); detected by cryptsetup test suite failure in FIPS mode. Signed-off-by: Milan Broz <gmazyland@gmail.com> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: testmgr - skip crc32c context test for ahash algorithmsEric Biggers2019-02-011-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instantiating "cryptd(crc32c)" causes a crypto self-test failure because the crypto_alloc_shash() in alg_test_crc32c() fails. This is because cryptd(crc32c) is an ahash algorithm, not a shash algorithm; so it can only be accessed through the ahash API, unlike shash algorithms which can be accessed through both the ahash and shash APIs. As the test is testing the shash descriptor format which is only applicable to shash algorithms, skip it for ahash algorithms. (Note that it's still important to fix crypto self-test failures even for weird algorithm instantiations like cryptd(crc32c) that no one would really use; in fips_enabled mode unprivileged users can use them to panic the kernel, and also they prevent treating a crypto self-test failure as a bug when fuzzing the kernel.) Fixes: 8e3ee85e68c5 ("crypto: crc32c - Test descriptor context format") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: seqiv - Use kmemdup in seqiv_aead_encrypt()YueHaibing2019-02-011-4/+3Star
| | | | | | | | | | | | | | Use kmemdup rather than duplicating its implementation Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: clarify name of WEAK_KEY request flagEric Biggers2019-01-253-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak keys be forbidden (for algorithms that have the notion of "weak keys"; currently only DES and XTS do). Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which it can be easily confused. (This in fact happened in the UX500 driver, though just in some debugging messages.) Therefore, make the intent clear by renaming it to CRYPTO_TFM_REQ_FORBID_WEAK_KEYS. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: chacha20poly1305 - use template array registering API to simplify ↵Xiongfeng Wang2019-01-251-23/+14Star
| | | | | | | | | | | | | | | | | | | | the code Use crypto template array registering API to simplify the code. Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ctr - use template array registering API to simplify the codeXiongfeng Wang2019-01-251-28/+14Star
| | | | | | | | | | | | | | | | Use crypto template array registering API to simplify the code. Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: gcm - use template array registering API to simplify the codeXiongfeng Wang2019-01-251-50/+23Star
| | | | | | | | | | | | | | | | Use crypto template array registering API to simplify the code. Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: ccm - use template array registering API to simplify the codeXiongfeng Wang2019-01-251-55/+23Star
| | | | | | | | | | | | | | | | Use crypto template array registering API to simplify the code. Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-06-08 19:43:20 +0200