kernel.git/arch/s390/crypto, branch linux-5.4.y

s390/archrandom: simplify back to earlier design and initialize earlier

2022-07-07T15:36:48Z

commit e4f74400308cb8abde5fdc9cad609c2aba32110c upstream. s390x appears to present two RNG interfaces: - a "TRNG" that gathers entropy using some hardware function; and - a "DRBG" that takes in a seed and expands it. Previously, the TRNG was wired up to arch_get_random_{long,int}(), but it was observed that this was being called really frequently, resulting in high overhead. So it was changed to be wired up to arch_get_random_ seed_{long,int}(), which was a reasonable decision. Later on, the DRBG was then wired up to arch_get_random_{long,int}(), with a complicated buffer filling thread, to control overhead and rate. Fortunately, none of the performance issues matter much now. The RNG always attempts to use arch_get_random_seed_{long,int}() first, which means a complicated implementation of arch_get_random_{long,int}() isn't really valuable or useful to have around. And it's only used when reseeding, which means it won't hit the high throughput complications that were faced before. So this commit returns to an earlier design of just calling the TRNG in arch_get_random_seed_{long,int}(), and returning false in arch_get_ random_{long,int}(). Part of what makes the simplification possible is that the RNG now seeds itself using the TRNG at bootup. But this only works if the TRNG is detected early in boot, before random_init() is called. So this commit also causes that check to happen in setup_arch(). Cc: stable@vger.kernel.org Cc: Harald Freudenberger Cc: Ingo Franzki Cc: Juergen Christ Cc: Heiko Carstens Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20220610222023.378448-1-Jason@zx2c4.com Reviewed-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

s390/crypto: fix scatterwalk_unmap() callers in AES-GCM

2022-06-14T16:11:54Z

[ Upstream commit bd52cd5e23f134019b23f0c389db0f9a436e4576 ] The argument of scatterwalk_unmap() is supposed to be the void* that was returned by the previous scatterwalk_map() call. The s390 AES-GCM implementation was instead passing the pointer to the struct scatter_walk. This doesn't actually break anything because scatterwalk_unmap() only uses its argument under CONFIG_HIGHMEM and ARCH_HAS_FLUSH_ON_KUNMAP. Fixes: bf7fa038707c ("s390/crypto: add s390 platform specific aes gcm support.") Signed-off-by: Jann Horn Acked-by: Harald Freudenberger Link: https://lore.kernel.org/r/20220517143047.3054498-1-jannh@google.com Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/archrandom: add parameter check for s390_arch_random_generate

2021-05-11T12:04:13Z

[ Upstream commit 28096067686c5a5cbd4c35b079749bd805df5010 ] A review of the code showed, that this function which is exposed within the whole kernel should do a parameter check for the amount of bytes requested. If this requested bytes is too high an unsigned int overflow could happen causing this function to try to memcpy a really big memory chunk. This is not a security issue as there are only two invocations of this function from arch/s390/include/asm/archrandom.h and both are not exposed to userland. Reported-by: Sven Schnelle Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/crypto: Fix unsigned variable compared with zero

2019-12-31T15:45:41Z

[ Upstream commit 0398d4ab1677f7d8cd43aac2aa29a93dfcf9e2e3 ] s390_crypto_shash_parmsize() return type is int, it should not be stored in a unsigned variable, which compared with zero. Reported-by: Hulk Robot Fixes: 3c2eb6b76cab ("s390/crypto: Support for SHA3 via CPACF (MSA6)") Signed-off-by: YueHaibing Signed-off-by: Joerg Schmidbauer Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2019-09-18T19:11:14Z

Pull crypto updates from Herbert Xu: "API: - Add the ability to abort a skcipher walk. Algorithms: - Fix XTS to actually do the stealing. - Add library helpers for AES and DES for single-block users. - Add library helpers for SHA256. - Add new DES key verification helper. - Add surrounding bits for ESSIV generator. - Add accelerations for aegis128. - Add test vectors for lzo-rle. Drivers: - Add i.MX8MQ support to caam. - Add gcm/ccm/cfb/ofb aes support in inside-secure. - Add ofb/cfb aes support in media-tek. - Add HiSilicon ZIP accelerator support. Others: - Fix potential race condition in padata. - Use unbound workqueues in padata" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (311 commits) crypto: caam - Cast to long first before pointer conversion crypto: ccree - enable CTS support in AES-XTS crypto: inside-secure - Probe transform record cache RAM sizes crypto: inside-secure - Base RD fetchcount on actual RD FIFO size crypto: inside-secure - Base CD fetchcount on actual CD FIFO size crypto: inside-secure - Enable extended algorithms on newer HW crypto: inside-secure: Corrected configuration of EIP96_TOKEN_CTRL crypto: inside-secure - Add EIP97/EIP197 and endianness detection padata: remove cpu_index from the parallel_queue padata: unbind parallel jobs from specific CPUs padata: use separate workqueues for parallel and serial work padata, pcrypt: take CPU hotplug lock internally in padata_alloc_possible crypto: pcrypt - remove padata cpumask notifier padata: make padata_do_parallel find alternate callback CPU workqueue: require CPU hotplug read exclusion for apply_workqueue_attrs workqueue: unconfine alloc/apply/free_workqueue_attrs() padata: allocate workqueue internally arm64: dts: imx8mq: Add CAAM node random: Use wait_event_freezable() in add_hwgenerator_randomness() crypto: ux500 - Fix COMPILE_TEST warnings ...

s390/crypto: Support for SHA3 via CPACF (MSA6)

2019-09-13T10:18:50Z

This patch introduces sha3 support for s390. - Rework the s390-specific SHA1 and SHA2 related code to provide the basis for SHA3. - Provide two new kernel modules sha3_256_s390 and sha3_512_s390 together with new kernel options. Signed-off-by: Joerg Schmidbauer Reviewed-by: Ingo Franzki Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens

s390/crypto: xts-aes-s390 fix extra run-time crypto self tests finding

2019-09-05T13:18:15Z

With 'extra run-time crypto self tests' enabled, the selftest for s390-xts fails with alg: skcipher: xts-aes-s390 encryption unexpectedly succeeded on test vector "random: len=0 klen=64"; expected_error=-22, cfg="random: inplace use_digest nosimd src_divs=[2.61%@+4006, 84.44%@+21, 1.55%@+13, 4.50%@+344, 4.26%@+21, 2.64%@+27]" This special case with nbytes=0 is not handled correctly and this fix now makes sure that -EINVAL is returned when there is en/decrypt called with 0 bytes to en/decrypt. Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik

crypto: s390 - Rename functions to avoid conflict with crypto/sha256.h

2019-09-05T04:37:30Z

Rename static / file-local functions so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by: Hans de Goede Signed-off-by: Herbert Xu

crypto: s390/aes - fix typo in XTS_BLOCK_SIZE identifier

2019-08-22T12:12:45Z

Fix a typo XTS_BLOCKSIZE -> XTS_BLOCK_SIZE, causing the build to break. Fixes: ce68acbcb6a5 ("crypto: s390/xts-aes - invoke fallback for...") Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu

crypto: s390/xts-aes - invoke fallback for ciphertext stealing

2019-08-22T04:57:34Z

For correctness and compliance with the XTS-AES specification, we are adding support for ciphertext stealing to XTS implementations, even though no use cases are known that will be enabled by this. Since the s390 implementation already has a fallback skcipher standby for other purposes, let's use it for this purpose as well. If ciphertext stealing use cases ever become a bottleneck, we can always revisit this. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu