user/sven/linux.git/drivers/crypto, branch v4.19.53

crypto: vmx - ghash: do nosimd fallback manually

2019-06-04T06:02:34Z

commit 357d065a44cdd77ed5ff35155a989f2a763e96ef upstream. 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 Signed-off-by: Daniel Axtens Acked-by: Ard Biesheuvel Tested-by: Michael Ellerman Signed-off-by: Herbert Xu Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman

crypto: sun4i-ss - Fix invalid calculation of hash end

2019-05-31T13:46:15Z

[ Upstream commit f87391558acf816b48f325a493d81d45dec40da0 ] When nbytes < 4, end is wronlgy set to a negative value which, due to uint, is then interpreted to a large value leading to a deadlock in the following code. This patch fix this problem. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: vmx - CTR: always increment IV as quadword

2019-05-31T13:46:01Z

commit 009b30ac7444c17fae34c4f435ebce8e8e2b3250 upstream. 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 Acked-by: Nayna Jain Tested-by: Nayna Jain Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - handle tee fips error during power management resume

2019-05-22T05:37:40Z

commit 7138377ce10455b7183c6dde4b2c51b33f464c45 upstream. in order to support cryptocell tee fips error that may occurs while cryptocell ree is suspended, an cc_tee_handle_fips_error call added to the cc_pm_resume function. Signed-off-by: Ofir Drang Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - add function to handle cryptocell tee fips error

2019-05-22T05:37:40Z

commit 897ab2316910a66bb048f1c9cefa25e6a592dcd7 upstream. Adds function that checks if cryptocell tee fips error occurred and in such case triggers system error through kernel panic. Change fips function to use this new routine. Signed-off-by: Ofir Drang Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - HOST_POWER_DOWN_EN should be the last CC access during suspend

2019-05-22T05:37:39Z

commit 3499efbeed39d114873267683b9e776bcb34b058 upstream. During power management suspend the driver need to prepare the device for the power down operation and as a last indication write to the HOST_POWER_DOWN_EN register which signals to the hardware that The ccree is ready for power down. Signed-off-by: Ofir Drang Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - pm resume first enable the source clk

2019-05-22T05:37:39Z

commit 7766dd774d80463cec7b81d90c8672af91de2da1 upstream. On power management resume function first enable the device clk source to allow access to the device registers. Signed-off-by: Ofir Drang Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - don't map AEAD key and IV on stack

2019-05-22T05:37:39Z

commit e8662a6a5f8f7f2cadc0edb934aef622d96ac3ee upstream. The AEAD authenc key and IVs might be passed to us on stack. Copy it to a slab buffer before mapping to gurantee proper DMA mapping. Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - use correct internal state sizes for export

2019-05-22T05:37:39Z

commit f3df82b468f00cca241d96ee3697c9a5e7fb6bd0 upstream. We were computing the size of the import buffer based on the digest size but the 318 and 224 byte variants use 512 and 256 bytes internal state sizes respectfully, thus causing the import buffer to overrun. Fix it by using the right sizes. Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccree - don't map MAC key on stack

2019-05-22T05:37:39Z

commit 874e163759f27e0a9988c5d1f4605e3f25564fd2 upstream. The MAC hash key might be passed to us on stack. Copy it to a slab buffer before mapping to gurantee proper DMA mapping. Signed-off-by: Gilad Ben-Yossef Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman