<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/crypto/stm32, branch linux-5.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-01-27T11:02:43Z</updated>
<entry>
<title>crypto: stm32/crc32 - Fix kernel BUG triggered in probe()</title>
<updated>2022-01-27T11:02:43Z</updated>
<author>
<name>Marek Vasut</name>
</author>
<published>2021-12-20T19:50:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3536c2e8958b4b759663a0f103534287b15b57dc'/>
<id>urn:sha1:3536c2e8958b4b759663a0f103534287b15b57dc</id>
<content type='text'>
commit 29009604ad4e3ef784fd9b9fef6f23610ddf633d upstream.

The include/linux/crypto.h struct crypto_alg field cra_driver_name description
states "Unique name of the transformation provider. " ... " this contains the
name of the chip or provider and the name of the transformation algorithm."

In case of the stm32-crc driver, field cra_driver_name is identical for all
registered transformation providers and set to the name of the driver itself,
which is incorrect. This patch fixes it by assigning a unique cra_driver_name
to each registered transformation provider.

The kernel crash is triggered when the driver calls crypto_register_shashes()
which calls crypto_register_shash(), which calls crypto_register_alg(), which
calls __crypto_register_alg(), which returns -EEXIST, which is propagated
back through this call chain. Upon -EEXIST from crypto_register_shash(), the
crypto_register_shashes() starts unregistering the providers back, and calls
crypto_unregister_shash(), which calls crypto_unregister_alg(), and this is
where the BUG() triggers due to incorrect cra_refcnt.

Fixes: b51dbe90912a ("crypto: stm32 - Support for STM32 CRC32 crypto module")
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.12+
Cc: Alexandre Torgue &lt;alexandre.torgue@foss.st.com&gt;
Cc: Fabien Dessenne &lt;fabien.dessenne@st.com&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Lionel Debieve &lt;lionel.debieve@st.com&gt;
Cc: Nicolas Toromanoff &lt;nicolas.toromanoff@st.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-crypto@vger.kernel.org
Acked-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32 - Revert broken pm_runtime_resume_and_get changes</title>
<updated>2022-01-27T11:01:45Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2021-12-01T06:30:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=80d2ddd428ffac6dd0cc006832359019ea6faf54'/>
<id>urn:sha1:80d2ddd428ffac6dd0cc006832359019ea6faf54</id>
<content type='text'>
[ Upstream commit 3d6b661330a7954d8136df98160d525eb04dcd6a ]

We should not call pm_runtime_resume_and_get where the reference
count is expected to be incremented unconditionally.  This patch
reverts these calls to the original unconditional get_sync call.

Reported-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Fixes: 747bf30fd944 ("crypto: stm32/cryp - Fix PM reference leak...")
Fixes: 1cb3ad701970 ("crypto: stm32/hash - Fix PM reference leak...")
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.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: stm32/cryp - fix bugs and crash in tests</title>
<updated>2022-01-27T11:01:44Z</updated>
<author>
<name>Nicolas Toromanoff</name>
</author>
<published>2021-11-30T07:55:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=97f100d9435f5ff9e18c07a2469cc1f2d3aac2d3'/>
<id>urn:sha1:97f100d9435f5ff9e18c07a2469cc1f2d3aac2d3</id>
<content type='text'>
[ Upstream commit 4b898d5cfa4d9a0ad5bc82cb5eafdc092394c6a9 ]

Extra crypto manager auto test were crashing or failling due
to 2 reasons:
- block in a dead loop (dues to issues in cipher end process management)
- crash due to read/write unmapped memory (this crash was also reported
when using openssl afalg engine)

Rework interrupt management, interrupts are masked as soon as they are
no more used: if input buffer is fully consumed, "Input FIFO not full"
interrupt is masked and if output buffer is full, "Output FIFO not
empty" interrupt is masked.
And crypto request finish when input *and* outpout buffer are fully
read/write.

About the crash due to unmapped memory, using scatterwalk_copychunks()
that will map and copy each block fix the issue.
Using this api and copying full block will also fix unaligned data
access, avoid early copy of in/out buffer, and make useless the extra
alignment constraint.

Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module")

Reported-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32/cryp - fix lrw chaining mode</title>
<updated>2022-01-27T11:01:44Z</updated>
<author>
<name>Nicolas Toromanoff</name>
</author>
<published>2021-11-30T07:54:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c88e4241bb1dda01dbeaaf57b9435dd0b7814b33'/>
<id>urn:sha1:c88e4241bb1dda01dbeaaf57b9435dd0b7814b33</id>
<content type='text'>
[ Upstream commit fa97dc2d48b476ea98199d808d3248d285987e99 ]

This fixes the lrw autotest if lrw uses the CRYP as the AES block cipher
provider (as ecb(aes)). At end of request, CRYP should not update the IV
in case of ECB chaining mode. Indeed the ECB chaining mode never uses
the IV, but the software LRW chaining mode uses the IV field as
a counter and due to the (unexpected) update done by CRYP while the AES
block process, the counter get a wrong value when the IV overflow.

Fixes: 5f49f18d27cd ("crypto: stm32/cryp - update to return iv_out")

Signed-off-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32/cryp - fix double pm exit</title>
<updated>2022-01-27T11:01:44Z</updated>
<author>
<name>Nicolas Toromanoff</name>
</author>
<published>2021-11-30T07:54:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a9b97b1ab0d4588f25d82b494ed6f28b3bec240b'/>
<id>urn:sha1:a9b97b1ab0d4588f25d82b494ed6f28b3bec240b</id>
<content type='text'>
[ Upstream commit 6c12e742785bf9333faf60bfb96575bdd763448e ]

Delete extraneous lines in probe error handling code: pm was
disabled twice.

Fixes: 65f9aa36ee47 ("crypto: stm32/cryp - Add power management support")

Reported-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32/cryp - check early input data</title>
<updated>2022-01-27T11:01:44Z</updated>
<author>
<name>Nicolas Toromanoff</name>
</author>
<published>2021-11-30T07:54:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=48aa7e96d974c418a3d030facec0db8b337f3935'/>
<id>urn:sha1:48aa7e96d974c418a3d030facec0db8b337f3935</id>
<content type='text'>
[ Upstream commit 39e6e699c7fb92bdb2617b596ca4a4ea35c5d2a7 ]

Some auto tests failed because driver wasn't returning the expected
error with some input size/iv value/tag size.
Now:
 Return 0 early for empty buffer. (We don't need to start the engine for
 an empty input buffer).
 Accept any valid authsize for gcm(aes).
 Return -EINVAL if iv for ccm(aes) is invalid.
 Return -EINVAL if buffer size is a not a multiple of algorithm block size.

Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module")

Signed-off-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32/cryp - fix xts and race condition in crypto_engine requests</title>
<updated>2022-01-27T11:01:44Z</updated>
<author>
<name>Nicolas Toromanoff</name>
</author>
<published>2021-11-30T07:54:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=89904a3ee053a8c68b0d87ab9768a5cbae3f1127'/>
<id>urn:sha1:89904a3ee053a8c68b0d87ab9768a5cbae3f1127</id>
<content type='text'>
[ Upstream commit d703c7a994ee34b7fa89baf21631fca0aa9f17fc ]

Don't erase key:
If key is erased before the crypto_finalize_.*_request() call, some
pending process will run with a key={ 0 }.
Moreover if the key is reset at end of request, it breaks xts chaining
mode, as for last xts block (in case input len is not a multiple of
block) a new AES request is started without calling again set_key().

Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module")

Signed-off-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32/cryp - fix CTR counter carry</title>
<updated>2022-01-27T11:01:44Z</updated>
<author>
<name>Nicolas Toromanoff</name>
</author>
<published>2021-11-30T07:54:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=28cce5a3d884bf91af7884468425b3943d8e3790'/>
<id>urn:sha1:28cce5a3d884bf91af7884468425b3943d8e3790</id>
<content type='text'>
[ Upstream commit 41c76690b0990efacd15d35cfb4e77318cd80ebb ]

STM32 CRYP hardware doesn't manage CTR counter bigger than max U32, as
a workaround, at each block the current IV is saved, if the saved IV
lower u32 is 0xFFFFFFFF, the full IV is manually incremented, and set
in hardware.
Fixes: bbb2832620ac ("crypto: stm32 - Fix sparse warnings")

Signed-off-by: Nicolas Toromanoff &lt;nicolas.toromanoff@foss.st.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: stm32/cryp - Fix PM reference leak on stm32-cryp.c</title>
<updated>2021-04-16T11:16:33Z</updated>
<author>
<name>Shixin Liu</name>
</author>
<published>2021-04-08T07:18:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=747bf30fd944f02f341b5f3bc7d97a13f2ae2fbe'/>
<id>urn:sha1:747bf30fd944f02f341b5f3bc7d97a13f2ae2fbe</id>
<content type='text'>
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu &lt;liushixin2@huawei.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: stm32/hash - Fix PM reference leak on stm32-hash.c</title>
<updated>2021-04-16T11:16:33Z</updated>
<author>
<name>Shixin Liu</name>
</author>
<published>2021-04-08T07:18:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1cb3ad701970e68f18a9e5d090baf2b1b703d729'/>
<id>urn:sha1:1cb3ad701970e68f18a9e5d090baf2b1b703d729</id>
<content type='text'>
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu &lt;liushixin2@huawei.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
