summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* crypto: serpent - mark __serpent_setkey_sbox noinlineArnd Bergmann2019-06-271-1/+7
| | | | | | | | | | | | | | | | The same bug that gcc hit in the past is apparently now showing up with clang, which decides to inline __serpent_setkey_sbox: crypto/serpent_generic.c:268:5: error: stack frame size of 2112 bytes in function '__serpent_setkey' [-Werror,-Wframe-larger-than=] Marking it 'noinline' reduces the stack usage from 2112 bytes to 192 and 96 bytes, respectively, and seems to generate more useful object code. Fixes: c871c10e4ea7 ("crypto: serpent - improve __serpent_setkey with UBSAN") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: testmgr - dynamically allocate crypto_shashArnd Bergmann2019-06-271-6/+13
| | | | | | | | | | | | | | | | | | | | The largest stack object in this file is now the shash descriptor. Since there are many other stack variables, this can push it over the 1024 byte warning limit, in particular with clang and KASAN: crypto/testmgr.c:1693:12: error: stack frame size of 1312 bytes in function '__alg_test_hash' [-Werror,-Wframe-larger-than=] Make test_hash_vs_generic_impl() do the same thing as the corresponding eaed and skcipher functions by allocating the descriptor dynamically. We can still do better than this, but it brings us well below the 1024 byte limit. Suggested-by: Eric Biggers <ebiggers@kernel.org> Fixes: 9a8a6b3f0950 ("crypto: testmgr - fuzz hashes against their generic implementation") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: testmgr - dynamically allocate testvec_configArnd Bergmann2019-06-271-11/+32
| | | | | | | | | | | | | | | | | | | | | On arm32, we get warnings about high stack usage in some of the functions: crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function 'alg_test_aead' [-Werror,-Wframe-larger-than=] static int alg_test_aead(const struct alg_test_desc *desc, const char *driver, ^ crypto/testmgr.c:1693:12: error: stack frame size of 1312 bytes in function '__alg_test_hash' [-Werror,-Wframe-larger-than=] static int __alg_test_hash(const struct hash_testvec *vecs, ^ On of the larger objects on the stack here is struct testvec_config, so change that to dynamic allocation. Fixes: 40153b10d91c ("crypto: testmgr - fuzz AEADs against their generic implementation") Fixes: d435e10e67be ("crypto: testmgr - fuzz skciphers against their generic implementation") Fixes: 9a8a6b3f0950 ("crypto: testmgr - fuzz hashes against their generic implementation") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: talitos - eliminate unneeded 'done' functions at build timeChristophe Leroy2019-06-271-1/+1
| | | | | | | | | | | | When building for SEC1 only, talitos2_done functions are unneeded and should go away. For this, use has_ftr_sec1() which will always return true when only SEC1 support is being built, allowing GCC to drop TALITOS2 functions. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: sun4i-ss - reduce stack usageArnd Bergmann2019-06-271-17/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | After the latest addition, the stack usage of sun4i_ss_cipher_poll grew beyond the warning limit when KASAN is enabled: drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:118:12: error: stack frame size of 1152 bytes in function 'sun4i_ss_cipher_poll' [-Werror,-Wframe-larger-than=] static int sun4i_ss_cipher_poll(struct skcipher_request *areq) Reduce it in three ways: - split out the new code into a separate function so its stack usage can overlap that of the sun4i_ss_opti_poll() code path - mark both special cases as noinline_for_stack, which should ideally result in a tail call that frees the rest of the stack - move the buf and obuf variables into the code blocks in which they are used. The three separate functions now use 144, 640 and 304 bytes of kernel stack, respectively. Fixes: 0ae1f46c55f8 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Corentin LABBE <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: ccree - add HW engine config checkGilad Ben-Yossef2019-06-273-0/+38
| | | | | | | | Add check to verify the stated device tree HW configuration matches the HW. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: ccree - prevent isr handling in case driver is suspendedOfir Drang2019-06-273-0/+16
| | | | | | | | | ccree irq may be shared with other devices, in order to prevent ccree isr handling while device maybe suspended we added a check to verify that the device is not suspended. Signed-off-by: Ofir Drang <ofir.drang@arm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: ccree - check that cryptocell reset completedOfir Drang2019-06-274-1/+43
| | | | | | | | | | | In case of driver probe and pm resume we need to check that the cryptocell hardware reset cycle is completed. during the reset cycle that Cryptocell provide read only access to the APB interface which allows to verify through the CC registers that the reset is completed. Until reset completion we assume that any write/crypto operation is blocked. Signed-off-by: Ofir Drang <ofir.drang@arm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: ccree - Relocate driver irq registration after clk initofir.drang@arm.com2019-06-271-9/+9
| | | | | Signed-off-by: Ofir Drang <ofir.drang@arm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: nx - no need to check return value of debugfs_create functionsGreg Kroah-Hartman2019-06-203-61/+26
| | | | | | | | | | | | | | | | | | | | | | | When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Also, there is no need to store the individual debugfs file names, especially as the whole directiry is deleted at once, so remove the unneeded structure entirely. Cc: "Breno Leitão" <leitao@debian.org> Cc: Nayna Jain <nayna@linux.ibm.com> Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* fs: cifs: switch to RC4 library interfaceArd Biesheuvel2019-06-203-48/+17
| | | | | | | | | | | | | | | | The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher, of which only a single generic C code implementation exists. This means that going through all the trouble of using scatterlists etc buys us very little, and we're better off just invoking the arc4 library directly. This also reverts commit 5f4b55699aaf ("CIFS: Fix BUG() in calc_seckey()"), since it is no longer necessary to allocate sec_key on the heap. Cc: linux-cifs@vger.kernel.org Cc: Steve French <sfrench@samba.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Steve French <stfrench@microsoft.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* ppp: mppe: switch to RC4 library interfaceArd Biesheuvel2019-06-202-85/+15
| | | | | | | | | | | | | | | | The MPPE code uses the sync skcipher to invoke the ecb(arc4) skcipher, of which only a single generic C code implementation exists. This means that going through all the trouble of using scatterlists etc buys us very little, and we're better off just invoking the arc4 library directly. Note that the SHA1 shash used by this driver has several accelerated implementations for various architectures, so retaining that part does make sense. Cc: linux-ppp@vger.kernel.org Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: arc4 - remove cipher implementationArd Biesheuvel2019-06-202-50/+16
| | | | | | | | | | | | | There are no remaining users of the cipher implementation, and there are no meaningful ways in which the arc4 cipher can be combined with templates other than ECB (and the way we do provide that combination is highly dubious to begin with). So let's drop the arc4 cipher altogether, and only keep the ecb(arc4) skcipher, which is used in various places in the kernel. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* net/lib80211: move TKIP handling to ARC4 library codeArd Biesheuvel2019-06-202-31/+18
| | | | | | | | | The crypto API abstraction is not very useful for invoking ciphers directly, especially in the case of arc4, which only has a generic implementation in C. So let's invoke the library code directly. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* net/lib80211: move WEP handling to ARC4 library codeArd Biesheuvel2019-06-202-38/+14
| | | | | | | | | The crypto API abstraction is not very useful for invoking ciphers directly, especially in the case of arc4, which only has a generic implementation in C. So let's invoke the library code directly. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* net/mac80211: move WEP handling to ARC4 library interfaceArd Biesheuvel2019-06-2011-60/+30
| | | | | | | | | | | | | The WEP code in the mac80211 subsystem currently uses the crypto API to access the arc4 (RC4) cipher, which is overly complicated, and doesn't really have an upside in this particular case, since ciphers are always synchronous and therefore always implemented in software. Given that we have no accelerated software implementations either, it is much more straightforward to invoke a generic library interface directly. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: arc4 - refactor arc4 core code into separate libraryArd Biesheuvel2019-06-207-60/+95
| | | | | | | | | | Refactor the core rc4 handling so we can move most users to a library interface, permitting us to drop the cipher interface entirely in a future patch. This is part of an effort to simplify the crypto API and improve its robustness against incorrect use. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: talitos - fix max key size for sha384 and sha512Christophe Leroy2019-06-201-1/+1
| | | | | | | | | | | | Below commit came with a typo in the CONFIG_ symbol, leading to a permanently reduced max key size regarless of the driver capabilities. Reported-by: Horia Geantă <horia.geanta@nxp.com> Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: vmx - Document CTR mode counter width quirksDaniel Axtens2019-06-201-2/+20
| | | | | | | | | | | The CTR code comes from OpenSSL, where it does a 32-bit counter. The kernel has a 128-bit counter. This difference has lead to issues. Document it. Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: caam - update IV using HW supportHoria Geantă2019-06-205-146/+163
| | | | | | | | | | | | | | | | | | Modify drivers to perform skcipher IV update using the crypto engine, instead of performing the operation in SW. Besides being more efficient, this also fixes IV update for CTR mode. Output HW S/G table is appended with an entry pointing to the same IV buffer used as input (which is now mapped BIDIRECTIONAL). AS (Algorithm State) parameter of the OPERATION command is changed from INIFINAL to INIT in descriptors used by ctr(aes), cbc(aes). This is needed since in case FINAL bit is set, HW skips IV updating in the Context Register for the last data block. Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* 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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-28 17:58:01 +0100