<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/crypto/mediatek/mtk-aes.c, branch master</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2021-01-02T21:41:34+00:00</updated>
<entry>
<title>crypto: mediatek - remove obsolete driver</title>
<updated>2021-01-02T21:41:34+00:00</updated>
<author>
<name>Vic Wu</name>
<email>vic.wu@mediatek.com</email>
</author>
<published>2020-12-07T07:58:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6a702fa5339597f2f2bb466043fbb20f3e55e0ad'/>
<id>urn:sha1:6a702fa5339597f2f2bb466043fbb20f3e55e0ad</id>
<content type='text'>
The crypto mediatek driver has been replaced by the inside-secure
driver now. Remove this driver to avoid having duplicate drivers.

Signed-off-by: Vic Wu &lt;vic.wu@mediatek.com&gt;
Acked-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mediatek - Fix endianness bugs and sparse warnings</title>
<updated>2020-08-28T06:58:30+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2020-08-21T07:52:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=39340cf97fef32667e8714d0fcc247f02d8e2b97'/>
<id>urn:sha1:39340cf97fef32667e8714d0fcc247f02d8e2b97</id>
<content type='text'>
This patch squashes all the sparse warnings in mediatek, some of
which appear to be genuine bugs.  In particular, previously on
BE the keys and IVs all get 32-bit swabbed which can't be right
because they don't get swabbed on LE.  I presume LE is the one
that actually works.

Another funky thing is that the GHASH key gets swabbed on LE.
This makes no sense but I'm presuming someone actually tested
this on LE so I'm preserving the swabbing.  Someone needs to
test this though as it is entirely possible that GCM is the
only thing that worked on BE but not LE.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mediatek - use AES library for GCM key derivation</title>
<updated>2020-07-16T11:49:04+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2020-07-07T06:32:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f441ba2ad34102692b9836923776f017b40afc88'/>
<id>urn:sha1:f441ba2ad34102692b9836923776f017b40afc88</id>
<content type='text'>
The Mediatek accelerator driver calls into a dynamically allocated
skcipher of the ctr(aes) variety to perform GCM key derivation, which
involves AES encryption of a single block consisting of NUL bytes.

There is no point in using the skcipher API for this, so use the AES
library interface instead.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: remove propagation of CRYPTO_TFM_RES_* flags</title>
<updated>2020-01-09T03:30:53+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-12-31T03:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/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:53+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-12-31T03:19:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/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: mediatek - switch to skcipher API</title>
<updated>2019-11-17T01:02:47+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2019-11-09T17:09:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c2609391f95b140eaa21442581c6675ba10388d9'/>
<id>urn:sha1:c2609391f95b140eaa21442581c6675ba10388d9</id>
<content type='text'>
Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
dated 20 august 2015 introduced the new skcipher API which is supposed to
replace both blkcipher and ablkcipher. While all consumers of the API have
been converted long ago, some producers of the ablkcipher remain, forcing
us to keep the ablkcipher support routines alive, along with the matching
code to expose [a]blkciphers via the skcipher API.

So switch this driver to the skcipher API, allowing us to finally drop the
ablkcipher code in the near future.

Cc: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mediatek - remove redundant bitwise-or</title>
<updated>2019-11-01T05:38:31+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-10-23T11:48:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a52485165d85b008d8ebb03884350b11039580e1'/>
<id>urn:sha1:a52485165d85b008d8ebb03884350b11039580e1</id>
<content type='text'>
Bitwise-or'ing 0xffffffff with the u32 variable ctr is the same result
as assigning the value to ctr.  Remove the redundant bitwise-or and
just use an assignment.

Addresses-Coverity: ("Suspicious &amp;= or |= constant expression")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mediatek - fix incorrect crypto key setting</title>
<updated>2019-09-05T04:36:54+00:00</updated>
<author>
<name>Vic Wu</name>
<email>vic.wu@mediatek.com</email>
</author>
<published>2019-08-28T06:37:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a3d7c50c416c378c91272e6b2905f91fde682319'/>
<id>urn:sha1:a3d7c50c416c378c91272e6b2905f91fde682319</id>
<content type='text'>
Record crypto key to context during setkey and set the key to
transform state buffer in encrypt/decrypt process.

Signed-off-by: Vic Wu &lt;vic.wu@mediatek.com&gt;
Tested-by: John Crispin &lt;john@phrozen.og&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mediatek - add support to OFB/CFB mode</title>
<updated>2019-09-05T04:36:54+00:00</updated>
<author>
<name>Ryder Lee</name>
<email>ryder.lee@mediatek.com</email>
</author>
<published>2019-08-28T06:37:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=069ec891823a5211c48c68c9b9f1571d9647606d'/>
<id>urn:sha1:069ec891823a5211c48c68c9b9f1571d9647606d</id>
<content type='text'>
This patch adds support to OFB/CFB mode.

Signed-off-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Signed-off-by: Vic Wu &lt;vic.wu@mediatek.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: mediatek - fix uninitialized value of gctx-&gt;textlen</title>
<updated>2019-09-05T04:36:54+00:00</updated>
<author>
<name>Ryder Lee</name>
<email>ryder.lee@mediatek.com</email>
</author>
<published>2019-08-28T06:37:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e049ff5af04b18bfb4105787be198d58c841fc99'/>
<id>urn:sha1:e049ff5af04b18bfb4105787be198d58c841fc99</id>
<content type='text'>
Add a pre-computed text length to avoid uninitialized value in the check.

Fixes: e47270665b5f ("crypto: mediatek - Add empty messages check in GCM mode")
Signed-off-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Signed-off-by: Vic Wu &lt;vic.wu@mediatek.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
