<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/crypto/inside-secure, branch v5.8</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.8</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.8'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2020-01-09T03:30:53Z</updated>
<entry>
<title>crypto: remove propagation of CRYPTO_TFM_RES_* flags</title>
<updated>2020-01-09T03:30:53Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-12-31T03:19:38Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=af5034e8e4a5838fc77e476c1a91822e449d5869'/>
<id>urn:sha1:af5034e8e4a5838fc77e476c1a91822e449d5869</id>
<content type='text'>
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
-&gt;setkey() functions provide more information about errors.  But these
flags weren't actually being used or tested, and in many cases they
weren't being set correctly anyway.  So they've now been removed.

Also, if someone ever actually needs to start better distinguishing
-&gt;setkey() errors (which is somewhat unlikely, as this has been unneeded
for a long time), we'd be much better off just defining different return
values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.

So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that
propagates these flags around.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN</title>
<updated>2020-01-09T03:30:53Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-12-31T03:19:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=674f368a952c48ede71784935a799a5205b92b6c'/>
<id>urn:sha1:674f368a952c48ede71784935a799a5205b92b6c</id>
<content type='text'>
The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
make the -&gt;setkey() functions provide more information about errors.

However, no one actually checks for this flag, which makes it pointless.

Also, many algorithms fail to set this flag when given a bad length key.
Reviewing just the generic implementations, this is the case for
aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
rfc7539, rfc7539esp, salsa20, seqiv, and xcbc.  But there are probably
many more in arch/*/crypto/ and drivers/crypto/.

Some algorithms can even set this flag when the key is the correct
length.  For example, authenc and authencesn set it when the key payload
is malformed in any way (not just a bad length), the atmel-sha and ccree
drivers can set it if a memory allocation fails, and the chelsio driver
sets it for bad auth tag lengths, not just bad key lengths.

So even if someone actually wanted to start checking this flag (which
seems unlikely, since it's been unused for a long time), there would be
a lot of work needed to get it working correctly.  But it would probably
be much better to go back to the drawing board and just define different
return values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.

So just remove this flag.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Horia Geantă &lt;horia.geanta@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fix hang case on EIP97 with basic DES/3DES ops</title>
<updated>2019-12-20T06:58:34Z</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-12-11T16:32:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=177e358c9609e7810b53c3355ea4f56f26d1416f'/>
<id>urn:sha1:177e358c9609e7810b53c3355ea4f56f26d1416f</id>
<content type='text'>
This patch fixes another hang case on the EIP97 caused by sending
invalidation tokens to the hardware when doing basic (3)DES ECB/CBC
operations. Invalidation tokens are an EIP197 feature and needed nor
supported by the EIP97. So they should not be sent for that device.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fix hang case on EIP97 with zero length input data</title>
<updated>2019-12-20T06:58:34Z</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-12-11T16:32:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cb97aa9473627720810a0a016621c36f15392802'/>
<id>urn:sha1:cb97aa9473627720810a0a016621c36f15392802</id>
<content type='text'>
The EIP97 hardware cannot handle zero length input data and will (usually)
hang when presented with this anyway. This patch converts any zero length
input to a 1 byte dummy input to prevent this hanging.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fix Unable to fit even 1 command desc error w/ EIP97</title>
<updated>2019-12-20T06:58:33Z</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-12-11T16:32:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=098e51e517bc2e5865c520f3eee8bf83dd320e61'/>
<id>urn:sha1:098e51e517bc2e5865c520f3eee8bf83dd320e61</id>
<content type='text'>
Due to the additions of support for modes like AES-CCM and AES-GCM, which
require large command tokens, the size of the descriptor has grown such that
it now does not fit into the descriptor cache of a standard EIP97 anymore.
This means that the driver no longer works on the Marvell Armada 3700LP chip
(as used on e.g. Espressobin) that it has always supported.
Additionally, performance on EIP197's like Marvell A8K may also degrade
due to being able to fit less descriptors in the on-chip cache.
Putting these tokens into the descriptor was really a hack and not how the
design was supposed to be used - resource allocation did not account for it.

So what this patch does, is move the command token out of the descriptor.
To avoid having to allocate buffers on the fly for these command tokens,
they are stuffed in a "shadow ring", which is a circular buffer of fixed
size blocks that runs in lock-step with the descriptor ring. i.e. there is
one token block per descriptor. The descriptor ring itself is then pre-
populated with the pointers to these token blocks so these do not need to
be filled in when building the descriptors later.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@rambus.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Use PTR_ERR_OR_ZERO() to simplify code</title>
<updated>2019-12-11T08:34:44Z</updated>
<author>
<name>zhengbin</name>
<email>zhengbin13@huawei.com</email>
</author>
<published>2019-11-18T10:53:56Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3f61b0527b4e3df06fc8b41dded7ce7bbd3f0023'/>
<id>urn:sha1:3f61b0527b4e3df06fc8b41dded7ce7bbd3f0023</id>
<content type='text'>
Fixes coccicheck warning:

drivers/crypto/inside-secure/safexcel_cipher.c:2534:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: zhengbin &lt;zhengbin13@huawei.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fixed authenc w/ (3)DES fails on Macchiatobin</title>
<updated>2019-11-17T01:02:38Z</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-11-08T09:00:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b8151220f35da4653d95c840e03b8a9db2c0d1c0'/>
<id>urn:sha1:b8151220f35da4653d95c840e03b8a9db2c0d1c0</id>
<content type='text'>
Fixed 2 copy-paste mistakes in the commit mentioned below that caused
authenc w/ (3)DES to consistently fail on Macchiatobin (but strangely
work fine on x86+FPGA??).
Now fully tested on both platforms.

Fixes: 13a1bb93f7b1c9 ("crypto: inside-secure - Fixed warnings...")
Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fix hangup during probing for EIP97 engine</title>
<updated>2019-11-17T00:37:29Z</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-11-06T15:13:07Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c3510fec6e824cd7ab75f77c80412b746928aa2b'/>
<id>urn:sha1:c3510fec6e824cd7ab75f77c80412b746928aa2b</id>
<content type='text'>
Fixed mask used for CFSIZE and RFSIZE fields of HIA_OPTIONS register,
these were all 1 bit too wide. Which caused the probing of a standard
EIP97 to actually hang due to assume way too large descriptor FIFO's.

Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Add missed clk_disable_unprepare</title>
<updated>2019-11-08T15:15:53Z</updated>
<author>
<name>Chuhong Yuan</name>
<email>hslester96@gmail.com</email>
</author>
<published>2019-11-01T14:37:15Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=df40c4e6cdaaacbf26d1206adb2419733de3bbf1'/>
<id>urn:sha1:df40c4e6cdaaacbf26d1206adb2419733de3bbf1</id>
<content type='text'>
safexcel_remove misses disabling priv-&gt;reg_clk like what is done when
probe fails.
Add the missed call to fix it.

Signed-off-by: Chuhong Yuan &lt;hslester96@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: inside-secure - Fixed warnings on inconsistent byte order handling</title>
<updated>2019-11-01T05:33:42Z</updated>
<author>
<name>Pascal van Leeuwen</name>
<email>pascalvanl@gmail.com</email>
</author>
<published>2019-10-22T09:01:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=13a1bb93f7b1c90099c557696951884ea7dcda34'/>
<id>urn:sha1:13a1bb93f7b1c90099c557696951884ea7dcda34</id>
<content type='text'>
This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.

Credits for the fix to safexcel.c go to Ben Dooks.

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Reported-by: Ben Dooks &lt;ben.dooks@codethink.co.uk&gt;
Signed-off-by: Pascal van Leeuwen &lt;pvanleeuwen@verimatrix.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
