summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* crypto: caam - use len instead of nents for bulding HW S/G tableHoria Geantă2019-06-208-99/+105
| | | | | | | | | | | | | | | | | | | | Currently, conversion of SW S/G table into HW S/G layout relies on nents returned by sg_nents_for_len(sg, len). However this leaves the possibility of HW S/G referencing more data then needed: since buffer length in HW S/G entries is filled using sg_dma_len(sg), the last entry in HW S/G table might have a length that is bigger than needed for the crypto request. This way of S/G table conversion is fine, unless after converting a table more entries have to be appended to the HW S/G table. In this case, crypto engine would access data from the S/G entry having the incorrect length, instead of advancing in the S/G table. This situation doesn't exist, but the upcoming implementation of IV update for skcipher algorithms needs to add a S/G entry after req->dst S/G (corresponding to output IV). Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* hwrng: iproc-rng200 - Add support for 7211Florian Fainelli2019-06-201-0/+1
| | | | | | | | BCM7211 features a RNG200 hardware random number generator block, add support for this chip by matching the chip-specific compatible string. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* dt-bindings: rng: Document BCM7211 RNG compatible stringFlorian Fainelli2019-06-201-0/+1
| | | | | | | | BCM7211 features a RNG200 block, document its compatible string. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Herbert Xu2019-06-206-129/+100
|\ | | | | | | Merge crypto tree to pick up vmx changes.
| * crypto: hmac - fix memory leak in hmac_init_tfm()Eric Biggers2019-05-301-1/+3
| | | | | | | | | | | | | | | | | | | | When I added the sanity check of 'descsize', I missed that the child hash tfm needs to be freed if the sanity check fails. Of course this should never happen, hence the use of WARN_ON(), but it should be fixed. Fixes: e1354400b25d ("crypto: hash - fix incorrect HASH_MAX_DESCSIZE") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: jitterentropy - change back to module_init()Eric Biggers2019-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "jitterentropy_rng" doesn't have any other implementations, nor is it tested by the crypto self-tests. So it was unnecessary to change it to subsys_initcall. Also it depends on the main clocksource being initialized, which may happen after subsys_initcall, causing this error: jitterentropy: Initialization failed with host not compliant with requirements: 2 Change it back to module_init(). Fixes: c4741b230597 ("crypto: run initcalls for generic implementations earlier") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: vmx - ghash: do nosimd fallback manuallyDaniel Axtens2019-05-171-125/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VMX ghash was using a fallback that did not support interleaving simd and nosimd operations, leading to failures in the extended test suite. If I understood correctly, Eric's suggestion was to use the same data format that the generic code uses, allowing us to call into it with the same contexts. I wasn't able to get that to work - I think there's a very different key structure and data layout being used. So instead steal the arm64 approach and perform the fallback operations directly if required. Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module") Cc: stable@vger.kernel.org # v4.1+ Reported-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Daniel Axtens <dja@axtens.net> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: vmx - CTR: always increment IV as quadwordDaniel Axtens2019-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel self-tests picked up an issue with CTR mode: alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep" Test vector 3 has an IV of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD, so after 3 increments it should wrap around to 0. In the aesp8-ppc code from OpenSSL, there are two paths that increment IVs: the bulk (8 at a time) path, and the individual path which is used when there are fewer than 8 AES blocks to process. In the bulk path, the IV is incremented with vadduqm: "Vector Add Unsigned Quadword Modulo", which does 128-bit addition. In the individual path, however, the IV is incremented with vadduwm: "Vector Add Unsigned Word Modulo", which instead does 4 32-bit additions. Thus the IV would instead become FFFFFFFFFFFFFFFFFFFFFFFF00000000, throwing off the result. Use vadduqm. This was probably a typo originally, what with q and w being adjacent. It is a pretty narrow edge case: I am really impressed by the quality of the kernel self-tests! Fixes: 5c380d623ed3 ("crypto: vmx - Add support for VMS instructions by ASM") Cc: stable@vger.kernel.org Signed-off-by: Daniel Axtens <dja@axtens.net> Acked-by: Nayna Jain <nayna@linux.ibm.com> Tested-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: hash - fix incorrect HASH_MAX_DESCSIZEEric Biggers2019-05-172-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "hmac(sha3-224-generic)" algorithm has a descsize of 368 bytes, which is greater than HASH_MAX_DESCSIZE (360) which is only enough for sha3-224-generic. The check in shash_prepare_alg() doesn't catch this because the HMAC template doesn't set descsize on the algorithms, but rather sets it on each individual HMAC transform. This causes a stack buffer overflow when SHASH_DESC_ON_STACK() is used with hmac(sha3-224-generic). Fix it by increasing HASH_MAX_DESCSIZE to the real maximum. Also add a sanity check to hmac_init(). This was detected by the improved crypto self-tests in v5.2, by loading the tcrypt module with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y enabled. I didn't notice this bug when I ran the self-tests by requesting the algorithms via AF_ALG (i.e., not using tcrypt), probably because the stack layout differs in the two cases and that made a difference here. KASAN report: BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:359 [inline] BUG: KASAN: stack-out-of-bounds in shash_default_import+0x52/0x80 crypto/shash.c:223 Write of size 360 at addr ffff8880651defc8 by task insmod/3689 CPU: 2 PID: 3689 Comm: insmod Tainted: G E 5.1.0-10741-g35c99ffa20edd #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x86/0xc5 lib/dump_stack.c:113 print_address_description+0x7f/0x260 mm/kasan/report.c:188 __kasan_report+0x144/0x187 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x137/0x190 mm/kasan/generic.c:191 memcpy+0x37/0x50 mm/kasan/common.c:125 memcpy include/linux/string.h:359 [inline] shash_default_import+0x52/0x80 crypto/shash.c:223 crypto_shash_import include/crypto/hash.h:880 [inline] hmac_import+0x184/0x240 crypto/hmac.c:102 hmac_init+0x96/0xc0 crypto/hmac.c:107 crypto_shash_init include/crypto/hash.h:902 [inline] shash_digest_unaligned+0x9f/0xf0 crypto/shash.c:194 crypto_shash_digest+0xe9/0x1b0 crypto/shash.c:211 generate_random_hash_testvec.constprop.11+0x1ec/0x5b0 crypto/testmgr.c:1331 test_hash_vs_generic_impl+0x3f7/0x5c0 crypto/testmgr.c:1420 __alg_test_hash+0x26d/0x340 crypto/testmgr.c:1502 alg_test_hash+0x22e/0x330 crypto/testmgr.c:1552 alg_test.part.7+0x132/0x610 crypto/testmgr.c:4931 alg_test+0x1f/0x40 crypto/testmgr.c:4952 Fixes: b68a7ec1e9a3 ("crypto: hash - Remove VLA usage") Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Cc: <stable@vger.kernel.org> # v4.20+ Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * crypto: caam - fix typo in i.MX6 devices list for errataIuliana Prodan2019-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix a typo in the list of i.MX6 devices affected by an issue wherein AXI bus transactions may not occur in the correct order. Fixes: 33d69455e402 ("crypto: caam - limit AXI pipeline to a depth of 1") 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: sahara - Use devm_platform_ioremap_resource()Fabio Estevam2019-06-131-3/+1
| | | | | | | | | | | | | | Use devm_platform_ioremap_resource() to simplify the code a bit. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: mxs-dcp - Use devm_platform_ioremap_resource()Fabio Estevam2019-06-131-4/+1
| | | | | | | | | | | | | | Use devm_platform_ioremap_resource() to simplify the code a bit. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: hisilicon - Use the correct style for SPDX License IdentifierNishad Kamdar2019-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corrects the SPDX License Identifier style in header file related to Crypto Drivers for Hisilicon SEC Engine in Hip06 and Hip07. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: qat - use struct_size() helperGustavo A. R. Silva2019-06-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct qat_alg_buf_list { ... struct qat_alg_buf bufers[]; } __packed __aligned(64); Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following form: sizeof(struct qat_alg_buf_list) + ((1 + n) * sizeof(struct qat_alg_buf)) with: struct_size(bufl, bufers, n + 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>
* | ARM: dts: imx7ulp: add crypto supportIuliana Prodan2019-06-131-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Add crypto node in device tree for CAAM support. Noteworthy is that on 7ulp the interrupt line is shared between the two job rings. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com> Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: cavium/nitrox - Use the correct style for SPDX License IdentifierNishad Kamdar2019-06-132-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corrects the SPDX License Identifier style in header files related to Crypto Drivers for Cavium Nitrox family CNN55XX devices. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: bcm - Make some symbols staticYueHaibing2019-06-132-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix sparse warnings: drivers/crypto/bcm/cipher.c:99:6: warning: symbol 'BCMHEADER' was not declared. Should it be static? drivers/crypto/bcm/cipher.c:2096:6: warning: symbol 'spu_no_incr_hash' was not declared. Should it be static? drivers/crypto/bcm/cipher.c:4823:5: warning: symbol 'bcm_spu_probe' was not declared. Should it be static? drivers/crypto/bcm/cipher.c:4867:5: warning: symbol 'bcm_spu_remove' was not declared. Should it be static? drivers/crypto/bcm/spu2.c:52:6: warning: symbol 'spu2_cipher_type_names' was not declared. Should it be static? drivers/crypto/bcm/spu2.c:56:6: warning: symbol 'spu2_cipher_mode_names' was not declared. Should it be static? drivers/crypto/bcm/spu2.c:60:6: warning: symbol 'spu2_hash_type_names' was not declared. Should it be static? drivers/crypto/bcm/spu2.c:66:6: warning: symbol 'spu2_hash_mode_names' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: chacha - constify ctx and iv argumentsEric Biggers2019-06-135-6/+6
| | | | | | | | | | | | | | | | | | | | Constify the ctx and iv arguments to crypto_chacha_init() and the various chacha*_stream_xor() functions. This makes it clear that they are not modified. 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: chacha20poly1305 - a few cleanupsEric Biggers2019-06-131-30/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Use sg_init_one() instead of sg_init_table() then sg_set_buf(). - Remove unneeded calls to sg_init_table() prior to scatterwalk_ffwd(). - Simplify initializing the poly tail block. - Simplify computing padlen. This doesn't change any actual behavior. Cc: Martin Willi <martin@strongswan.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: skcipher - make chunksize and walksize accessors internalEric Biggers2019-06-132-60/+60
| | | | | | | | | | | | | | | | | | | | | | The 'chunksize' and 'walksize' properties of skcipher algorithms are implementation details that users of the skcipher API should not be looking at. So move their accessor functions from <crypto/skcipher.h> to <crypto/internal/skcipher.h>. 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: skcipher - un-inline encrypt and decrypt functionsEric Biggers2019-06-132-30/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | crypto_skcipher_encrypt() and crypto_skcipher_decrypt() have grown to be more than a single indirect function call. They now also check whether a key has been set, and with CONFIG_CRYPTO_STATS=y they also update the crypto statistics. That can add up to a lot of bloat at every call site. Moreover, these always involve a function call anyway, which greatly limits the benefits of inlining. So change them to be non-inline. 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: aead - un-inline encrypt and decrypt functionsEric Biggers2019-06-132-32/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | crypto_aead_encrypt() and crypto_aead_decrypt() have grown to be more than a single indirect function call. They now also check whether a key has been set, the decryption side checks whether the input is at least as long as the authentication tag length, and with CONFIG_CRYPTO_STATS=y they also update the crypto statistics. That can add up to a lot of bloat at every call site. Moreover, these always involve a function call anyway, which greatly limits the benefits of inlining. So change them to be non-inline. 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: x86/aesni - remove unused internal cipher algorithmEric Biggers2019-06-131-38/+7
| | | | | | | | | | | | | | | | | | | | Since commit 944585a64f5e ("crypto: x86/aes-ni - remove special handling of AES in PCBC mode"), the "__aes-aesni" internal cipher algorithm is no longer used. So remove it too. 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: doc - improve the skcipher API example codeEric Biggers2019-06-131-99/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the skcipher API example, changing it to encrypt a buffer with AES-256-XTS. This addresses various problems with the previous example: - It requests a specific driver "cbc-aes-aesni", which is unusual. Normally users ask for "cbc(aes)", not a specific driver. - It encrypts only a single AES block. For the reader, that doesn't clearly distinguish the "skcipher" API from the "cipher" API. - Showing how to encrypt something with bare CBC is arguably a poor choice of example, as it doesn't follow modern crypto trends. Now, usually authenticated encryption is recommended, in which case the user would use the AEAD API, not skcipher. Disk encryption is still a legitimate use for skcipher, but for that usually XTS is recommended. - Many other bugs and poor coding practices, such as not setting CRYPTO_TFM_REQ_MAY_SLEEP, unnecessarily allocating a heap buffer for the IV, unnecessary NULL checks, using a pointless wrapper struct, and forgetting to set an error code in one case. 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: testmgr - add some more preemption pointsEric Biggers2019-06-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Call cond_resched() after each fuzz test iteration. This avoids stall warnings if fuzz_iterations is set very high for testing purposes. While we're at it, also call cond_resched() after finishing testing each test vector. 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: algapi - require cra_name and cra_driver_nameEric Biggers2019-06-131-18/+4
| | | | | | | | | | | | | | | | | | | | | | | | Now that all algorithms explicitly set cra_driver_name, make it required for algorithm registration and remove the code that generated a default cra_driver_name. Also add an explicit check that cra_name is set too, since that's obviously required too, yet it didn't seem to be checked anywhere. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: make all generic algorithms set cra_driver_nameEric Biggers2019-06-1322-24/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most generic crypto algorithms declare a driver name ending in "-generic". The rest don't declare a driver name and instead rely on the crypto API automagically appending "-generic" upon registration. Having multiple conventions is unnecessarily confusing and makes it harder to grep for all generic algorithms in the kernel source tree. But also, allowing NULL driver names is problematic because sometimes people fail to set it, e.g. the case fixed by commit 417980364300 ("crypto: cavium/zip - fix collision with generic cra_driver_name"). Of course, people can also incorrectly name their drivers "-generic". But that's much easier to notice / grep for. Therefore, let's make cra_driver_name mandatory. In preparation for this, this patch makes all generic algorithms set cra_driver_name. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: chacha20poly1305 - fix atomic sleep when using async algorithmEric Biggers2019-06-061-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clear the CRYPTO_TFM_REQ_MAY_SLEEP flag when the chacha20poly1305 operation is being continued from an async completion callback, since sleeping may not be allowed in that context. This is basically the same bug that was recently fixed in the xts and lrw templates. But, it's always been broken in chacha20poly1305 too. This was found using syzkaller in combination with the updated crypto self-tests which actually test the MAY_SLEEP flag now. Reproducer: python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind( ("aead", "rfc7539(cryptd(chacha20-generic),poly1305-generic)"))' Kernel output: BUG: sleeping function called from invalid context at include/crypto/algapi.h:426 in_atomic(): 1, irqs_disabled(): 0, pid: 1001, name: kworker/2:2 [...] CPU: 2 PID: 1001 Comm: kworker/2:2 Not tainted 5.2.0-rc2 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014 Workqueue: crypto cryptd_queue_worker Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x4d/0x6a lib/dump_stack.c:113 ___might_sleep kernel/sched/core.c:6138 [inline] ___might_sleep.cold.19+0x8e/0x9f kernel/sched/core.c:6095 crypto_yield include/crypto/algapi.h:426 [inline] crypto_hash_walk_done+0xd6/0x100 crypto/ahash.c:113 shash_ahash_update+0x41/0x60 crypto/shash.c:251 shash_async_update+0xd/0x10 crypto/shash.c:260 crypto_ahash_update include/crypto/hash.h:539 [inline] poly_setkey+0xf6/0x130 crypto/chacha20poly1305.c:337 poly_init+0x51/0x60 crypto/chacha20poly1305.c:364 async_done_continue crypto/chacha20poly1305.c:78 [inline] poly_genkey_done+0x15/0x30 crypto/chacha20poly1305.c:369 cryptd_skcipher_complete+0x29/0x70 crypto/cryptd.c:279 cryptd_skcipher_decrypt+0xcd/0x110 crypto/cryptd.c:339 cryptd_queue_worker+0x70/0xa0 crypto/cryptd.c:184 process_one_work+0x1ed/0x420 kernel/workqueue.c:2269 worker_thread+0x3e/0x3a0 kernel/workqueue.c:2415 kthread+0x11f/0x140 kernel/kthread.c:255 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 Fixes: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539") Cc: <stable@vger.kernel.org> # v4.2+ Cc: Martin Willi <martin@strongswan.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: atmel-i2c - Fix build error while CRC16 set to mYueHaibing2019-06-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If CRYPTO_DEV_ATMEL_ECC is set m, which select CRC16 to m, while CRYPTO_DEV_ATMEL_SHA204A is set to y, building fails. drivers/crypto/atmel-i2c.o: In function 'atmel_i2c_checksum': atmel-i2c.c:(.text+0x16): undefined reference to 'crc16' Add CRC16 dependency to CRYPTO_DEV_ATMEL_SHA204A Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: caam - disable some clock checks for iMX7ULPIuliana Prodan2019-06-061-2/+4
| | | | | | | | | | | | | | | | | | Disabled the check and set of 'mem' and 'emi_slow' clocks, since these are not available for iMX7ULP. 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: caam - limit output IV to CBC to work around CTR mode DMA issueArd Biesheuvel2019-06-061-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CAAM driver currently violates an undocumented and slightly controversial requirement imposed by the crypto stack that a buffer referred to by the request structure via its virtual address may not be modified while any scatterlists passed via the same request structure are mapped for inbound DMA. This may result in errors like alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-generic): ret=74 alg: aead: Failed to load transform for gcm(aes): -2 on non-cache coherent systems, due to the fact that the GCM driver passes an IV buffer by virtual address which shares a cacheline with the auth_tag buffer passed via a scatterlist, resulting in corruption of the auth_tag when the IV is updated while the DMA mapping is live. Since the IV that is returned to the caller is only valid for CBC mode, and given that the in-kernel users of CBC (such as CTS) don't trigger the same issue as the GCM driver, let's just disable the output IV generation for all modes except CBC for the time being. Fixes: 854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt") Cc: Horia Geanta <horia.geanta@nxp.com> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> Reported-by: Sascha Hauer <s.hauer@pengutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Horia Geanta <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: atmel - Fix sparse endianness warningsHerbert Xu2019-06-062-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The param2 member in atmel_i2c_cmd is supposed to be little-endian but was marked as u16. This patch changes it to a __le16 which reveals a missing endian swap in atmel_i2c_init_read_cmd. Another missing little-endian marking is also added in atmel_i2c_checksum. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip...") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: lrw - use correct alignmaskEric Biggers2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c778f96bf347 ("crypto: lrw - Optimize tweak computation") incorrectly reduced the alignmask of LRW instances from '__alignof__(u64) - 1' to '__alignof__(__be32) - 1'. However, xor_tweak() and setkey() assume that the data and key, respectively, are aligned to 'be128', which has u64 alignment. Fix the alignmask to be at least '__alignof__(be128) - 1'. Fixes: c778f96bf347 ("crypto: lrw - Optimize tweak computation") Cc: <stable@vger.kernel.org> # v4.20+ Cc: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: ghash - fix unaligned memory access in ghash_setkey()Eric Biggers2019-06-061-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changing ghash_mod_init() to be subsys_initcall made it start running before the alignment fault handler has been installed on ARM. In kernel builds where the keys in the ghash test vectors happened to be misaligned in the kernel image, this exposed the longstanding bug that ghash_setkey() is incorrectly casting the key buffer (which can have any alignment) to be128 for passing to gf128mul_init_4k_lle(). Fix this by memcpy()ing the key to a temporary buffer. Don't fix it by setting an alignmask on the algorithm instead because that would unnecessarily force alignment of the data too. Fixes: 2cdc6899a88e ("crypto: ghash - Add GHASH digest algorithm for GCM") Reported-by: Peter Robinson <pbrobinson@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: xxhash - Implement xxhash supportNikolay Borisov2019-06-065-0/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xxhash is currently implemented as a self-contained module in /lib. This patch enables that module to be used as part of the generic kernel crypto framework. It adds a simple wrapper to the 64bit version. I've also added test vectors (with help from Nick Terrell). The upstream xxhash code is tested by running hashing operation on random 222 byte data with seed values of 0 and a prime number. The upstream test suite can be found at https://github.com/Cyan4973/xxHash/blob/cf46e0c/xxhsum.c#L664 Essentially hashing is run on data of length 0,1,14,222 with the aforementioned seed values 0 and prime 2654435761. The particular random 222 byte string was provided to me by Nick Terrell by reading /dev/random and the checksums were calculated by the upstream xxsum utility with the following bash script: dd if=/dev/random of=TEST_VECTOR bs=1 count=222 for a in 0 1; do for l in 0 1 14 222; do for s in 0 2654435761; do echo algo $a length $l seed $s; head -c $l TEST_VECTOR | ~/projects/kernel/xxHash/xxhsum -H$a -s$s done done done This produces output as follows: algo 0 length 0 seed 0 02cc5d05 stdin algo 0 length 0 seed 2654435761 02cc5d05 stdin algo 0 length 1 seed 0 25201171 stdin algo 0 length 1 seed 2654435761 25201171 stdin algo 0 length 14 seed 0 c1d95975 stdin algo 0 length 14 seed 2654435761 c1d95975 stdin algo 0 length 222 seed 0 b38662a6 stdin algo 0 length 222 seed 2654435761 b38662a6 stdin algo 1 length 0 seed 0 ef46db3751d8e999 stdin algo 1 length 0 seed 2654435761 ac75fda2929b17ef stdin algo 1 length 1 seed 0 27c3f04c2881203a stdin algo 1 length 1 seed 2654435761 4a15ed26415dfe4d stdin algo 1 length 14 seed 0 3d33dc700231dfad stdin algo 1 length 14 seed 2654435761 ea5f7ddef9a64f80 stdin algo 1 length 222 seed 0 5f3d3c08ec2bef34 stdin algo 1 length 222 seed 2654435761 6a9df59664c7ed62 stdin algo 1 is xx64 variant, algo 0 is the 32 bit variant which is currently not hooked up. Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: jitter - update implementation to 2.1.2Stephan Müller2019-06-062-228/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Jitter RNG implementation is updated to comply with upstream version 2.1.2. The change covers the following aspects: * Time variation measurement is conducted over the LFSR operation instead of the XOR folding * Invcation of stuck test during initialization * Removal of the stirring functionality and the Von-Neumann unbiaser as the LFSR using a primitive and irreducible polynomial generates an identical distribution of random bits This implementation was successfully used in FIPS 140-2 validations as well as in German BSI evaluations. This kernel implementation was tested as follows: * The unchanged kernel code file jitterentropy.c is compiled as part of user space application to generate raw unconditioned noise data. That data is processed with the NIST SP800-90B non-IID test tool to verify that the kernel code exhibits an equal amount of noise as the upstream Jitter RNG version 2.1.2. * Using AF_ALG with the libkcapi tool of kcapi-rng the Jitter RNG was output tested with dieharder to verify that the output does not exhibit statistical weaknesses. The following command was used: kcapi-rng -n "jitterentropy_rng" -b 100000000000 | dieharder -a -g 200 * The unchanged kernel code file jitterentropy.c is compiled as part of user space application to test the LFSR implementation. The LFSR is injected a monotonically increasing counter as input and the output is fed into dieharder to verify that the LFSR operation does not exhibit statistical weaknesses. * The patch was tested on the Muen separation kernel which returns a more coarse time stamp to verify that the Jitter RNG does not cause regressions with its initialization test considering that the Jitter RNG depends on a high-resolution timer. Tested-by: Reto Buerki <reet@codelabs.ch> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: testmgr - test the shash APIEric Biggers2019-06-061-67/+335
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For hash algorithms implemented using the "shash" algorithm type, test both the ahash and shash APIs, not just the ahash API. Testing the ahash API already tests the shash API indirectly, which is normally good enough. However, there have been corner cases where there have been shash bugs that don't get exposed through the ahash API. So, update testmgr to test the shash API too. This would have detected the arm64 SHA-1 and SHA-2 bugs for which fixes were just sent out (https://patchwork.kernel.org/patch/10964843/ and https://patchwork.kernel.org/patch/10965089/): alg: shash: sha1-ce test failed (wrong result) on test vector 0, cfg="init+finup aligned buffer" alg: shash: sha224-ce test failed (wrong result) on test vector 0, cfg="init+finup aligned buffer" alg: shash: sha256-ce test failed (wrong result) on test vector 0, cfg="init+finup aligned buffer" This also would have detected the bugs fixed by commit 307508d10729 ("crypto: crct10dif-generic - fix use via crypto_shash_digest()") and commit dec3d0b1071a ("crypto: x86/crct10dif-pcl - fix use via crypto_shash_digest()"). 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: arm64/sha2-ce - correct digest for empty data in finupElena Petrova2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sha256-ce finup implementation for ARM64 produces wrong digest for empty input (len=0). Expected: the actual digest, result: initial value of SHA internal state. The error is in sha256_ce_finup: for empty data `finalize` will be 1, so the code is relying on sha2_ce_transform to make the final round. However, in sha256_base_do_update, the block function will not be called when len == 0. Fix it by setting finalize to 0 if data is empty. Fixes: 03802f6a80b3a ("crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer") Cc: stable@vger.kernel.org Signed-off-by: Elena Petrova <lenaptr@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: arm64/sha1-ce - correct digest for empty data in finupElena Petrova2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sha1-ce finup implementation for ARM64 produces wrong digest for empty input (len=0). Expected: da39a3ee..., result: 67452301... (initial value of SHA internal state). The error is in sha1_ce_finup: for empty data `finalize` will be 1, so the code is relying on sha1_ce_transform to make the final round. However, in sha1_base_do_update, the block function will not be called when len == 0. Fix it by setting finalize to 0 if data is empty. Fixes: 07eb54d306f4 ("crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer") Cc: stable@vger.kernel.org Signed-off-by: Elena Petrova <lenaptr@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: caam - strip input without changing crypto requestIuliana Prodan2019-06-062-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | For rsa and pkcs1pad, CAAM expects an input of modulus size. For this we strip the leading zeros in case the size is more than modulus. This commit avoids modifying the crypto request while stripping zeros from input, to comply with the crypto API requirement. This is done by adding a fixup input pointer and length. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Horia Geanta <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: caam - fix pkcs1pad(rsa-caam, sha256) failure because of invalid inputIuliana Prodan2019-06-062-17/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | The problem is with the input data size sent to CAAM for encrypt/decrypt. Pkcs1pad is failing due to pkcs1 padding done in SW starting with0x01 instead of 0x00 0x01. CAAM expects an input of modulus size. For this we strip the leading zeros in case the size is more than modulus or pad the input with zeros until the modulus size is reached. 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: inside-secure - do not rely on the hardware last bit for result ↵Antoine Tenart2019-06-061-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | descriptors When performing a transformation the hardware is given result descriptors to save the result data. Those result descriptors are batched using a 'first' and a 'last' bit. There are cases were more descriptors than needed are given to the engine, leading to the engine only using some of them, and not setting the last bit on the last descriptor we gave. This causes issues were the driver and the hardware aren't in sync anymore about the number of result descriptors given (as the driver do not give a pool of descriptor to use for any transformation, but a pool of descriptors to use *per* transformation). This patch fixes it by attaching the number of given result descriptors to the requests, and by using this number instead of the 'last' bit found on the descriptors to process them. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - fix use of the SG listAntoine Tenart2019-06-062-30/+12
| | | | | | | | | | | | | | | | | | | | | | Replace sg_nents_for_len by sg_nents when DMA mapping/unmapping buffers and when looping over the SG entries. This fix cases where the SG entries aren't used fully, which would in such cases led to using fewer SG entries than needed (and thus the engine wouldn't have access to the full input data and the result would be wrong). Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - add support for HMAC updatesAntoine Tenart2019-06-062-22/+38
| | | | | | | | | | | | | | | | | | This patch adds support for HMAC updates in the Inside Secure SafeXcel crypto engine driver. Updates were supported for hash algorithms, but were never enabled for HMAC ones. This fixes boot time test issues. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - implement IV retrievalAntoine Tenart2019-06-062-7/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for retrieving intermediate IV from the crypto engine when using the CBC block mode with AES and (3)DES. The retrieved IV is copied to the request IV buffer, as requested by the kernel crypto API. This fix boot tests added by commit 8efd972ef96a ("crypto: testmgr - support checking skcipher output IV"). Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - fix queued len computationAntoine Tenart2019-06-061-3/+5
| | | | | | | | | | | | | | | | | | | | This patch fixes the queued len computation, which could theoretically be wrong if req->len[1] - req->processed[1] > 1. Be future-proof here, and fix it. Fixes: b460edb6230a ("crypto: inside-secure - sha512 support") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - fix zeroing of the request in ahash_exit_invAntoine Tenart2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | A request is zeroed in safexcel_ahash_exit_inv(). This request total size is EIP197_AHASH_REQ_SIZE while the memset zeroing it uses sizeof(struct ahash_request), which happens to be less than EIP197_AHASH_REQ_SIZE. This patch fixes it. Fixes: f6beaea30487 ("crypto: inside-secure - authenc(hmac(sha256), cbc(aes)) support") Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - unify cache resetAntoine Tenart2019-06-061-0/+2
| | | | | | | | | | | | | | | | | | This patch unify the way the cache related data is zeroed when the cache buffer is DMA unmapped. It should not change the driver behaviour, but improves the code safety and readability. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - enable context reuseAntoine Tenart2019-06-063-0/+16
| | | | | | | | | | | | | | | | | | The context given to the crypto engine can be reused over time. While the driver was designed to allow this, the feature wasn't enabled in the hardware engine. This patch enables it. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: inside-secure - change returned error when a descriptor reports an errorAntoine Tenart2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | This patch changes the error reported by the Inside Secure SafeXcel driver when a result descriptor reports an error, from -EIO to -EINVAL, as this is what the crypto framework expects. This was found while running the crypto extra tests. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-04 02:04:25 +0100