linux-stable.git/drivers/crypto/Kconfig, branch v6.0

crypto: s390 - do not depend on CRYPTO_HW for SIMD implementations

2022-07-07T03:04:06+00:00

Various accelerated software implementation Kconfig values for S390 were
mistakenly placed into drivers/crypto/Kconfig, even though they're
mainly just SIMD code and live in arch/s390/crypto/ like usual. This
gives them the very unusual dependency on CRYPTO_HW, which leads to
problems elsewhere.

This patch fixes the issue by moving the Kconfig values for non-hardware
drivers into the usual place in crypto/Kconfig.

Acked-by: Herbert Xu 
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Jakub Kicinski

crypto: s390 - add crypto library interface for ChaCha20

2022-05-13T09:24:49+00:00

Implement a crypto library interface for the s390-native ChaCha20 cipher
algorithm. This allows us to stop to select CRYPTO_CHACHA20 and instead
select CRYPTO_ARCH_HAVE_LIB_CHACHA. This allows BIG_KEYS=y not to build
a whole ChaCha20 crypto infrastructure as a built-in, but build a smaller
CRYPTO_LIB_CHACHA instead.

Make CRYPTO_CHACHA_S390 config entry to look like similar ones on other
architectures. Remove CRYPTO_ALGAPI select as anyway it is selected by
CRYPTO_SKCIPHER.

Add a new test module and a test script for ChaCha20 cipher and its
interfaces. Here are test results on an idle z15 machine:

Data | Generic crypto TFM |  s390 crypto TFM |    s390 lib
size |      enc      dec  |     enc     dec  |     enc     dec
-----+--------------------+------------------+----------------
512b |   1545ns   1295ns  |   604ns   446ns  |   430ns  407ns
4k   |   9536ns   9463ns  |  2329ns  2174ns  |  2170ns  2154ns
64k  |  149.6us  149.3us  |  34.4us  34.5us  |  33.9us  33.1us
6M   |  23.61ms  23.11ms  |  4223us  4160us  |  3951us  4008us
60M  |  143.9ms  143.9ms  |  33.5ms  33.2ms  |  32.2ms  32.1ms

Signed-off-by: Vladis Dronov 
Reviewed-by: Harald Freudenberger 
Signed-off-by: Herbert Xu

crypto: xilinx - Turn SHA into a tristate and allow COMPILE_TEST

2022-03-14T02:45:45+00:00

This patch turns the new SHA driver into a tristate and also allows
compile testing.

Signed-off-by: Herbert Xu

crypto: xilinx: prevent probing on non-xilinx hardware

2022-03-09T03:12:31+00:00

The zynqmp-sha driver is always loaded and register its algorithm even on
platform which do not have the proper hardware.
This lead to a stacktrace due to zynqmp-sha3-384 failing its crypto
self tests.
So check if hardware is present via the firmware API call get_version.

While at it, simplify the platform_driver by using module_platform_driver()

Furthermore the driver should depend on ZYNQMP_FIRMWARE since it cannot
work without it.

Fixes: 7ecc3e34474b ("crypto: xilinx - Add Xilinx SHA3 driver")
Signed-off-by: Corentin Labbe 
Signed-off-by: Herbert Xu

crypto: xilinx - Add Xilinx SHA3 driver

2022-03-02T22:49:21+00:00

This patch adds SHA3 driver support for the Xilinx ZynqMP SoC.
Xilinx ZynqMP SoC has SHA3 engine used for secure hash calculation.
The flow is
SHA3 request from Userspace -> SHA3 driver-> ZynqMp driver-> Firmware ->
SHA3 HW Engine

SHA3 HW engine in Xilinx ZynqMP SoC, does not support parallel processing
of 2 hash requests.
Therefore, software fallback is being used for init, update, final,
export and import in the ZynqMP SHA driver
For digest, the calculation of SHA3 hash is done by the hardened
SHA3 accelerator in Xilinx ZynqMP SoC.

Signed-off-by: Harsha 
Signed-off-by: Kalyani Akula 
Signed-off-by: Herbert Xu

s390/crypto: add SIMD implementation for ChaCha20

2021-12-06T13:42:24+00:00

Add an implementation of the ChaCha20 stream cipher (see e.g. RFC 7539)
that makes use of z13's vector instruction set extension.

The original implementation is by Andy Polyakov which is
adapted for kernel use.

Four to six blocks are processed in parallel resulting in a performance
gain for inputs >= 256 bytes.

chacha20-generic

1 operation in 622 cycles (256 bytes)
1 operation in 2346 cycles (1024 bytes)

chacha20-s390

1 operation in 218 cycles (256 bytes)
1 operation in 647 cycles (1024 bytes)

Cc: Andy Polyakov 
Reviewed-by: Harald Freudenberger 
Signed-off-by: Patrick Steuer 
Signed-off-by: Heiko Carstens

crypto: sl3516 - Add dependency on ARCH_GEMINI

2021-06-28T03:28:08+00:00

The Storlink SL3516 crypto engine is only present on Storlink
Semiconductor/Storm Semiconductor/Cortina Systems Gemini SoCs.
Hence add a dependency on ARCH_GEMINI, to prevent asking the user about
this driver when configuring a kernel without Gemini support.

While at it, group the dependencies.

Fixes: 46c5338db7bd45b2 ("crypto: sl3516 - Add sl3516 crypto engine")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Herbert Xu

crypto: sl3516 - Typo s/Stormlink/Storlink/

2021-06-28T03:28:08+00:00

According to Documentation/devicetree/bindings/arm/gemini.txt, the
company was originally named "Storlink Semiconductor", and later renamed
to "Storm Semiconductor".

Fixes: 46c5338db7bd45b2 ("crypto: sl3516 - Add sl3516 crypto engine")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Herbert Xu

crypto: sl3516 - depends on HAS_IOMEM

2021-06-24T06:57:28+00:00

The sl3516 driver need to depend on HAS_IOMEM.
This fixes a build error:
ERROR: modpost: "devm_platform_ioremap_resource" [drivers/crypto/gemini/sl3516-ce.ko] undefined!

Reported-by: kernel test robot 
Signed-off-by: Corentin Labbe 
Signed-off-by: Herbert Xu

crypto: sl3516 - Fix build warning without CONFIG_PM

2021-06-24T06:51:35+00:00

drivers/crypto/gemini/sl3516-ce-core.c:345:12:
 warning: ‘sl3516_ce_pm_resume’ defined but not used [-Wunused-function]
 static int sl3516_ce_pm_resume(struct device *dev)
            ^~~~~~~~~~~~~~~~~~~

The driver needs PM, otherwise clock and resets are never set.
So make it depends on PM to fix this warning.

Signed-off-by: YueHaibing 
Suggested-by: LABBE Corentin 
Signed-off-by: Herbert Xu