<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/crypto/Kconfig, branch linux-6.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-01-07T10:15:56+00:00</updated>
<entry>
<title>crypto: ccree,hisilicon - Fix dependencies to correct algorithm</title>
<updated>2023-01-07T10:15:56+00:00</updated>
<author>
<name>Tianjia Zhang</name>
<email>tianjia.zhang@linux.alibaba.com</email>
</author>
<published>2022-11-25T12:18:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc4e2e566aec8f98f1d49367b555a744b761cd0a'/>
<id>urn:sha1:dc4e2e566aec8f98f1d49367b555a744b761cd0a</id>
<content type='text'>
commit 2ae6feb1a1f6678fe11864f1b6920ed10b09ad6a upstream.

Commit d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory") moves
the SM3 and SM4 stand-alone library and the algorithm implementation for
the Crypto API into the same directory, and the corresponding relationship
of Kconfig is modified, CONFIG_CRYPTO_SM3/4 corresponds to the stand-alone
library of SM3/4, and CONFIG_CRYPTO_SM3/4_GENERIC corresponds to the
algorithm implementation for the Crypto API. Therefore, it is necessary
for this module to depend on the correct algorithm.

Fixes: d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory")
Cc: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Cc: stable@vger.kernel.org # v5.19+
Signed-off-by: Tianjia Zhang &lt;tianjia.zhang@linux.alibaba.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>crypto: rockchip - rework by using crypto_engine</title>
<updated>2022-12-31T12:26:17+00:00</updated>
<author>
<name>Corentin Labbe</name>
<email>clabbe@baylibre.com</email>
</author>
<published>2022-09-27T07:54:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2d54a27b2c6a56d4f9cf205f707b1737045ac117'/>
<id>urn:sha1:2d54a27b2c6a56d4f9cf205f707b1737045ac117</id>
<content type='text'>
[ Upstream commit 57d67c6e8219b2a034c16d6149e30fb40fd39935 ]

Instead of doing manual queue management, let's use the crypto/engine
for that.
In the same time, rework the requests handling to be easier to
understand (and fix all bugs related to them).

Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Corentin Labbe &lt;clabbe@baylibre.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: rockchip - add fallback for cipher</title>
<updated>2022-12-31T12:26:17+00:00</updated>
<author>
<name>Corentin Labbe</name>
<email>clabbe@baylibre.com</email>
</author>
<published>2022-09-27T07:54:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7885456d916268a32330ab944f77cb5ed14ac583'/>
<id>urn:sha1:7885456d916268a32330ab944f77cb5ed14ac583</id>
<content type='text'>
[ Upstream commit 68ef8af09a1a912a5ed2cfaa4cca7606f52cef90 ]

The hardware does not handle 0 size length request, let's add a
fallback.
Furthermore fallback will be used for all unaligned case the hardware
cannot handle.

Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Corentin Labbe &lt;clabbe@baylibre.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: s390 - do not depend on CRYPTO_HW for SIMD implementations</title>
<updated>2022-07-07T03:04:06+00:00</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2022-07-07T00:31:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7133757da4c4c17d625970f6da3d76af12a8867'/>
<id>urn:sha1:b7133757da4c4c17d625970f6da3d76af12a8867</id>
<content type='text'>
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 &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: s390 - add crypto library interface for ChaCha20</title>
<updated>2022-05-13T09:24:49+00:00</updated>
<author>
<name>Vladis Dronov</name>
<email>vdronov@redhat.com</email>
</author>
<published>2022-05-08T13:09:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=349d03ffd5f62c298fd667ffa397c3fdc5c6194b'/>
<id>urn:sha1:349d03ffd5f62c298fd667ffa397c3fdc5c6194b</id>
<content type='text'>
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 &lt;vdronov@redhat.com&gt;
Reviewed-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: xilinx - Turn SHA into a tristate and allow COMPILE_TEST</title>
<updated>2022-03-14T02:45:45+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2022-03-09T03:20:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0e03b8fd29363f2df44e2a7a176d486de550757a'/>
<id>urn:sha1:0e03b8fd29363f2df44e2a7a176d486de550757a</id>
<content type='text'>
This patch turns the new SHA driver into a tristate and also allows
compile testing.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: xilinx: prevent probing on non-xilinx hardware</title>
<updated>2022-03-09T03:12:31+00:00</updated>
<author>
<name>Corentin Labbe</name>
<email>clabbe@baylibre.com</email>
</author>
<published>2022-03-04T07:36:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a70d9a1cf112c0bdb42800d264d48f34089e3e8'/>
<id>urn:sha1:7a70d9a1cf112c0bdb42800d264d48f34089e3e8</id>
<content type='text'>
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 &lt;clabbe@baylibre.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: xilinx - Add Xilinx SHA3 driver</title>
<updated>2022-03-02T22:49:21+00:00</updated>
<author>
<name>Harsha</name>
<email>harsha.harsha@xilinx.com</email>
</author>
<published>2022-02-23T10:35:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7ecc3e34474b7055994314ab6cff75eac7d03b71'/>
<id>urn:sha1:7ecc3e34474b7055994314ab6cff75eac7d03b71</id>
<content type='text'>
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 -&gt; SHA3 driver-&gt; ZynqMp driver-&gt; Firmware -&gt;
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 &lt;harsha.harsha@xilinx.com&gt;
Signed-off-by: Kalyani Akula &lt;kalyani.akula@xilinx.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>s390/crypto: add SIMD implementation for ChaCha20</title>
<updated>2021-12-06T13:42:24+00:00</updated>
<author>
<name>Patrick Steuer</name>
<email>patrick.steuer@de.ibm.com</email>
</author>
<published>2021-11-04T14:58:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b087dfab4d3902681550fd1f5ff9c3e942059478'/>
<id>urn:sha1:b087dfab4d3902681550fd1f5ff9c3e942059478</id>
<content type='text'>
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 &gt;= 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 &lt;appro@openssl.org&gt;
Reviewed-by: Harald Freudenberger &lt;freude@de.ibm.com&gt;
Signed-off-by: Patrick Steuer &lt;patrick.steuer@de.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>crypto: sl3516 - Add dependency on ARCH_GEMINI</title>
<updated>2021-06-28T03:28:08+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2021-06-25T13:27:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e29dd5c8382e39210a180b75b68912f536893ef0'/>
<id>urn:sha1:e29dd5c8382e39210a180b75b68912f536893ef0</id>
<content type='text'>
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 &lt;geert+renesas@glider.be&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
