- 01 Feb, 2019 23 commits
-
-
Ard Biesheuvel authored
Commit 5092fcf3 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback") introduced C fallback code to replace the NEON routines when invoked from a context where the NEON is not available (i.e., from the context of a softirq taken while the NEON is already being used in kernel process context) Fix two logical flaws in the MAC calculation of the associated data. Reported-by:
Eric Biggers <ebiggers@kernel.org> Fixes: 5092fcf3 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback") Cc: stable@vger.kernel.org Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
The NEON MAC calculation routine fails to handle the case correctly where there is some data in the buffer, and the input fills it up exactly. In this case, we enter the loop at the end with w8 == 0, while a negative value is assumed, and so the loop carries on until the increment of the 32-bit counter wraps around, which is quite obviously wrong. So omit the loop altogether in this case, and exit right away. Reported-by:
-
Eric Biggers authored
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: 8e3ee85e ("crypto: crc32c - Test descriptor context format") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Vincent Whitchurch authored
The request unmap and bounce buffer copying is currently unnecessarily done while holding the queue spin lock. Signed-off-by:
Lars Persson <larper@axis.com> Signed-off-by:
Vincent Whitchurch <rabinv@axis.com> Signed-off-by:
-
Lars Persson authored
Avoid plain memcmp() on the AEAD tag value as this could leak information through a timing side channel. Signed-off-by:
-
Lars Persson authored
The implementation assumed that the client always wants the whole 16 byte AES-GCM tag. Now we respect the requested authentication tag size fetched using crypto_aead_authsize(). Signed-off-by:
-
Lars Persson authored
The driver was optimized to only do cache maintenance for the last word of the dma descriptor status array. Unfortunately an omission also passed the last word as the address of the array start to the DMA engine. In most cases this goes unnoticed since the hardware aligns the address to a 64 byte boundary. Signed-off-by:
-
Lars Persson authored
Clients may submit a new requests from the completion callback context. The driver was not prepared to receive a request in this state because it already held the request queue lock and a recursive lock error is triggered. Now all completions are queued up until we are ready to drop the queue lock and then delivered. The fault was triggered by TCP over an IPsec connection in the LTP test suite: LTP: starting tcp4_ipsec02 (tcp_ipsec.sh -p ah -m transport -s "100 1000 65535") BUG: spinlock recursion on CPU#1, genload/943 lock: 0xbf3c3094, .magic: dead4ead, .owner: genload/943, .owner_cpu: 1 CPU: 1 PID: 943 Comm: genload Tainted: G O 4.9.62-axis5-devel #6 Hardware name: Axis ARTPEC-6 Platform (unwind_backtrace) from [<8010d134>] (show_stack+0x18/0x1c) (show_stack) from [<803a289c>] (dump_stack+0x84/0x98) (dump_stack) from [<8016e164>] (do_raw_spin_lock+0x124/0x128) (do_raw_spin_lock) from [<804de1a4>] (artpec6_crypto_submit+0x2c/0xa0) (artpec6_crypto_submit) from [<804def38>] (artpec6_crypto_prepare_submit_hash+0xd0/0x54c) (artpec6_crypto_prepare_submit_hash) from [<7f3165f0>] (ah_output+0x2a4/0x3dc [ah4]) (ah_output [ah4]) from [<805df9bc>] (xfrm_output_resume+0x178/0x4a4) (xfrm_output_resume) from [<805d283c>] (xfrm4_output+0xac/0xbc) (xfrm4_output) from [<80587928>] (ip_queue_xmit+0x140/0x3b4) (ip_queue_xmit) from [<805a13b4>] (tcp_transmit_skb+0x4c4/0x95c) (tcp_transmit_skb) from [<8059f218>] (tcp_rcv_state_process+0xdf4/0xdfc) (tcp_rcv_state_process) from [<805a7530>] (tcp_v4_do_rcv+0x64/0x1ac) (tcp_v4_do_rcv) from [<805a9724>] (tcp_v4_rcv+0xa34/0xb74) (tcp_v4_rcv) from [<80581d34>] (ip_local_deliver_finish+0x78/0x2b0) (ip_local_deliver_finish) from [<8058259c>] (ip_local_deliver+0xe4/0x104) (ip_local_deliver) from [<805d23ec>] (xfrm4_transport_finish+0xf4/0x144) (xfrm4_transport_finish) from [<805df564>] (xfrm_input+0x4f4/0x74c) (xfrm_input) from [<804de420>] (artpec6_crypto_task+0x208/0x38c) (artpec6_crypto_task) from [<801271b0>] (tasklet_action+0x60/0xec) (tasklet_action) from [<801266d4>] (__do_softirq+0xcc/0x3a4) (__do_softirq) from [<80126d20>] (irq_exit+0xf4/0x15c) (irq_exit) from [<801741e8>] (__handle_domain_irq+0x68/0xbc) (__handle_domain_irq) from [<801014f0>] (gic_handle_irq+0x50/0x94) (gic_handle_irq) from [<80657370>] (__irq_usr+0x50/0x80) Signed-off-by:
-
Lars Persson authored
The hardware cannot restore the context correctly when it operates in SHA512 mode. This is too restrictive when operating in a framework that can interleave multiple hash sessions. Signed-off-by:
-
Lars Persson authored
The hardware implementation of SHA384 was not correct and it cannot be used in any situation. Signed-off-by:
-
Corentin Labbe authored
When building without CONFIG_HW_RANDOM_PPC4XX, I hit the following build failure: drivers/crypto/amcc/crypto4xx_core.c: In function 'crypto4xx_probe': drivers/crypto/amcc/crypto4xx_core.c:1407:20: error: passing argument 1 of 'ppc4xx_trng_probe' from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from drivers/crypto/amcc/crypto4xx_core.c:50:0: drivers/crypto/amcc/crypto4xx_trng.h:28:20: note: expected 'struct crypto4xx_device *' but argument is of type 'struct crypto4xx_core_device *' drivers/crypto/amcc/crypto4xx_core.c: In function 'crypto4xx_remove': drivers/crypto/amcc/crypto4xx_core.c:1434:21: error: passing argument 1 of 'ppc4xx_trng_remove' from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from drivers/crypto/amcc/crypto4xx_core.c:50:0: drivers/crypto/amcc/crypto4xx_trng.h:30:20: note: expected 'struct crypto4xx_device *' but argument is of type 'struct crypto4xx_core_device *' This patch fix the needed argument of ppc4xx_trng_probe()/ppc4xx_trng_remove() in that case. Fixes: 5343e674 ("crypto4xx: integrate ppc4xx-rng into crypto4xx") Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
-
YueHaibing authored
Fix a static code checker warning: drivers/crypto/chelsio/chcr_algo.c:3681 chcr_aead_op() warn: passing zero to 'PTR_ERR' Fixes: 2debd332 ("crypto: chcr - Add AEAD algos.") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Roland Hieber authored
Signed-off-by:
Roland Hieber <rhi@pengutronix.de> Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: "Horia Geantă" <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gary Hook <gary.hook@amd.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Srikanth Jampala <Jampala.Srikanth@cavium.com> Cc: Yangtao Li <tiny.windzz@gmail.com> Cc: Gadam Sreerama <sgadam@cavium.com> Cc: Eric Biggers <ebiggers@google.com> Cc: linux-crypto@vger.kernel.org Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Robert Richter <rrichter@cavium.com> Cc: Jan Glauber <jglauber@cavium.com> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Jan Glauber <jglauber@cavium.com> Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-arm-kernel@axis.com Cc: linux-crypto@vger.kernel.org Signed-off-by:
Lars Persson <lars.persson@axis.com> Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: Yael Chemla <yael.chemla@foss.arm.com> Cc: Gilad Ben-Yossef <gilad@benyossef.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
-
Greg Kroah-Hartman authored
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. Cc: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Conor McLoughlin <conor.mcloughlin@intel.com> Cc: Waiman Long <longman@redhat.com> Cc: qat-linux@intel.com Cc: linux-crypto@vger.kernel.org Signed-off-by:
-
Horia Geantă authored
Recent AEAD changes in testmgr framework introduced by commit a0d608ee ("crypto: testmgr - unify the AEAD encryption and decryption test vectors") uncovered an error in the CAAM drivers, since they don't correctly handle the case when AEAD output length is zero. Add checks to avoid feeding zero-length req->dst to DMA API. Signed-off-by:
-
Iuliana Prodan authored
Add cmac(aes) keyed hash offloading support. Similar to xcbc implementation, driver must make sure there are still some bytes buffered when ahash_final() is called. This way HW is able to decide whether padding is needed and which key to derive (L -> K1 / K2) for the last block. Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by:
-
YueHaibing authored
Use kmemdup rather than duplicating its implementation Signed-off-by:
-
- 25 Jan, 2019 17 commits
-
-
Eric Biggers authored
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 authored
The do_decrypt() function in util.c in the BCM crypto driver is never used, so remove it. Signed-off-by:
-
David Tolnay authored
The virtio-rng driver uses a completion called have_data to wait for a virtio read to be fulfilled by the hypervisor. The completion is reset before placing a buffer on the virtio queue and completed by the virtio callback once data has been written into the buffer. Prior to this commit, the driver called init_completion on this completion both during probe as well as when registering virtio buffers as part of a hwrng read operation. The second of these init_completion calls should instead be reinit_completion because the have_data completion has already been inited by probe. As described in Documentation/scheduler/completion.txt, "Calling init_completion() twice on the same completion object is most likely a bug". This bug was present in the initial implementation of virtio-rng in f7f510ec ("virtio: An entropy device, as suggested by hpa"). Back then the have_data completion was a single static completion rather than a member of one of potentially multiple virtrng_info structs as implemented later by 08e53fbd ("virtio-rng: support multiple virtio-rng devices"). The original driver incorrectly used init_completion rather than INIT_COMPLETION to reset have_data during read. Tested by running `head -c48 /dev/random | hexdump` within crosvm, the Chrome OS virtual machine monitor, and confirming that the virtio-rng driver successfully produces random bytes from the host. Signed-off-by:
David Tolnay <dtolnay@gmail.com> Tested-by:
-
Xiongfeng Wang authored
Use crypto template array registering API to simplify the code. Signed-off-by:
Xiongfeng Wang <xiongfeng.wang@linaro.org> Reviewed-by:
-
Xiongfeng Wang authored
Use crypto template array registering API to simplify the code. Signed-off-by:
-
Xiongfeng Wang authored
Use crypto template array registering API to simplify the code. Signed-off-by:
-
Xiongfeng Wang authored
Use crypto template array registering API to simplify the code. Signed-off-by:
-
Xiongfeng Wang authored
This patch add a helper to (un)register a array of templates. The following patches will use this helper to simplify the code. Signed-off-by:
-
Thomas Gleixner authored
The license boiler plate text is not ideal for machine parsing. The kernel uses SPDX license identifiers for that purpose, which replace the boiler plate text. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Ondrej Mosnacek <omosnacek@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Acked-by:
Ondrej Mosnacek <omosnacek@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
The license boiler plate text is not ideal for machine parsing. The kernel uses SPDX license identifiers for that purpose, which replace the boiler plate text. Signed-off-by:
-
Thomas Gleixner authored
Precise and non-ambiguous license information is important. The recently added morus header files have a SPDX license identifier, which is nice, but at the same time they have a contradictionary license boiler plate text. SPDX-License-Identifier: GPL-2.0 versus * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free * Software Foundation; either version 2 of the License, or (at your option) * any later version Oh well. As the other morus related files are licensed under the GPL v2 or later, it's assumed that the boiler plate code is correct, but the SPDX license identifier is wrong. Fix the SPDX identifier and remove the boiler plate as it is redundant. Fixes: 56e8e57f ("crypto: morus - Add common SIMD glue code for MORUS") Fixes: 396be41f ("crypto: morus - Add generic MORUS AEAD implementations") Signed-off-by:
-
Thomas Gleixner authored
Precise and non-ambiguous license information is important. The recently added aegis header file has a SPDX license identifier, which is nice, but at the same time it has a contradictionary license boiler plate text. SPDX-License-Identifier: GPL-2.0 versus * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free * Software Foundation; either version 2 of the License, or (at your option) * any later version Oh well. As the other aegis related files are licensed under the GPL v2 or later, it's assumed that the boiler plate code is correct, but the SPDX license identifier is wrong. Fix the SPDX identifier and remove the boiler plate as it is redundant. Fixes: f606a88e ("crypto: aegis - Add generic AEGIS AEAD implementations") Signed-off-by:
-
Atul Gupta authored
Inline single pdu else take co-pro path Signed-off-by:
Atul Gupta <atul.gupta@chelsio.com> Signed-off-by:
-
Atul Gupta authored
use is_eth_imm to determine immediate data than use sa_entry field which is common for tunnel and not per skb. Signed-off-by:
-
Gilad Ben-Yossef authored
For decryption in CBC mode we need to save the last ciphertext block for use as the next IV. However, we were trying to do this also with zero sized ciphertext resulting in a panic. Fix this by only doing the copy if the ciphertext length is at least of IV size. Signed-off-by:
-
Gilad Ben-Yossef authored
The ccree driver was logging an error if it got an interrupt but HW indicated nothing to do as might happen if sharing an irq line. Remove the error as this is normal and we already have a debug print for the IRR register value. Signed-off-by:
-
Gilad Ben-Yossef authored
We were copying the last ciphertext block into the IV field for CBC before removing the DMA mapping of the output buffer with the result of the buffer sometime being out-of-sync cache wise and were getting intermittent cases of bad output IV. Fix it by moving the DMA buffer unmapping before the copy. Signed-off-by:
-
