<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/crypto, branch v4.19.67</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.67</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.19.67'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-08-16T08:12:38Z</updated>
<entry>
<title>crypto: ccp - Ignore tag length when decrypting GCM ciphertext</title>
<updated>2019-08-16T08:12:38Z</updated>
<author>
<name>Gary R Hook</name>
<email>gary.hook@amd.com</email>
</author>
<published>2019-07-30T16:05:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6dbc3b74daeb3475354cd135fcbfe14ae6abfe24'/>
<id>urn:sha1:6dbc3b74daeb3475354cd135fcbfe14ae6abfe24</id>
<content type='text'>
commit e2664ecbb2f26225ac6646876f2899558ffb2604 upstream.

AES GCM input buffers for decryption contain AAD+CTEXT+TAG. Only
decrypt the ciphertext, and use the tag for comparison.

Fixes: 36cf515b9bbe2 ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gary R Hook &lt;gary.hook@amd.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: ccp - Add support for valid authsize values less than 16</title>
<updated>2019-08-16T08:12:38Z</updated>
<author>
<name>Gary R Hook</name>
<email>gary.hook@amd.com</email>
</author>
<published>2019-07-30T16:05:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=30692edea30d633212e01f2378ac94d09c52f5d3'/>
<id>urn:sha1:30692edea30d633212e01f2378ac94d09c52f5d3</id>
<content type='text'>
commit 9f00baf74e4b6f79a3a3dfab44fb7bb2e797b551 upstream.

AES GCM encryption allows for authsize values of 4, 8, and 12-16 bytes.
Validate the requested authsize, and retain it to save in the request
context.

Fixes: 36cf515b9bbe2 ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gary R Hook &lt;gary.hook@amd.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: ccp - Fix oops by properly managing allocated structures</title>
<updated>2019-08-16T08:12:38Z</updated>
<author>
<name>Gary R Hook</name>
<email>gary.hook@amd.com</email>
</author>
<published>2019-07-30T16:05:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1c4393df3622d4a00aadff617b8fbcddc3c17204'/>
<id>urn:sha1:1c4393df3622d4a00aadff617b8fbcddc3c17204</id>
<content type='text'>
commit 25e44338321af545ab34243a6081c3f0fc6107d0 upstream.

A plaintext or ciphertext length of 0 is allowed in AES, in which case
no encryption occurs. Ensure that we don't clean up data structures
that were never allocated.

Fixes: 36cf515b9bbe2 ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gary R Hook &lt;gary.hook@amd.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: caam - limit output IV to CBC to work around CTR mode DMA issue</title>
<updated>2019-07-26T07:14:29Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2019-05-31T08:13:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ef5c2e165ab0a38c949bd44055fd0384e7d8c235'/>
<id>urn:sha1:ef5c2e165ab0a38c949bd44055fd0384e7d8c235</id>
<content type='text'>
commit ed527b13d800dd515a9e6c582f0a73eca65b2e1b upstream.

The CAAM driver currently violates an undocumented and slightly
controversial requirement imposed by the crypto stack that a buffer
referred to by the request structure via its virtual address may not
be modified while any scatterlists passed via the same request
structure are mapped for inbound DMA.

This may result in errors like

  alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-generic): ret=74
  alg: aead: Failed to load transform for gcm(aes): -2

on non-cache coherent systems, due to the fact that the GCM driver
passes an IV buffer by virtual address which shares a cacheline with
the auth_tag buffer passed via a scatterlist, resulting in corruption
of the auth_tag when the IV is updated while the DMA mapping is live.

Since the IV that is returned to the caller is only valid for CBC mode,
and given that the in-kernel users of CBC (such as CTS) don't trigger the
same issue as the GCM driver, let's just disable the output IV generation
for all modes except CBC for the time being.

Fixes: 854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt")
Cc: Horia Geanta &lt;horia.geanta@nxp.com&gt;
Cc: Iuliana Prodan &lt;iuliana.prodan@nxp.com&gt;
Reported-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Reviewed-by: Horia Geanta &lt;horia.geanta@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
[ Horia: backported to 4.14, 4.19 ]
Signed-off-by: Horia Geantă &lt;horia.geanta@nxp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probe</title>
<updated>2019-07-26T07:14:20Z</updated>
<author>
<name>Wen Yang</name>
<email>wen.yang99@zte.com.cn</email>
</author>
<published>2019-07-08T06:19:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c3b7d27f3746e7a54df1ada38710f82f1102f43b'/>
<id>urn:sha1:c3b7d27f3746e7a54df1ada38710f82f1102f43b</id>
<content type='text'>
commit 95566aa75cd6b3b404502c06f66956b5481194b3 upstream.

There is a possible double free issue in ppc4xx_trng_probe():

85:	dev-&gt;trng_base = of_iomap(trng, 0);
86:	of_node_put(trng);          ---&gt; released here
87:	if (!dev-&gt;trng_base)
88:		goto err_out;
...
110:	ierr_out:
111:		of_node_put(trng);  ---&gt; double released here
...

This issue was detected by using the Coccinelle software.
We fix it by removing the unnecessary of_node_put().

Fixes: 5343e674f32f ("crypto4xx: integrate ppc4xx-rng into crypto4xx")
Signed-off-by: Wen Yang &lt;wen.yang99@zte.com.cn&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Allison Randal &lt;allison@lohutok.net&gt;
Cc: Armijn Hemel &lt;armijn@tjaldur.nl&gt;
Cc: Julia Lawall &lt;Julia.Lawall@lip6.fr&gt;
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Julia Lawall &lt;julia.lawall@lip6.fr&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: ccp/gcm - use const time tag comparison.</title>
<updated>2019-07-26T07:14:20Z</updated>
<author>
<name>Cfir Cohen</name>
<email>cfir@google.com</email>
</author>
<published>2019-07-02T17:32:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a9fd1795fee69a9d384ead855e045edd5a035bb5'/>
<id>urn:sha1:a9fd1795fee69a9d384ead855e045edd5a035bb5</id>
<content type='text'>
commit 538a5a072e6ef04377b180ee9b3ce5bae0a85da4 upstream.

Avoid leaking GCM tag through timing side channel.

Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc: &lt;stable@vger.kernel.org&gt; # v4.12+
Signed-off-by: Cfir Cohen &lt;cfir@google.com&gt;
Acked-by: Gary R Hook &lt;ghook@amd.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: ccp - memset structure fields to zero before reuse</title>
<updated>2019-07-26T07:14:20Z</updated>
<author>
<name>Hook, Gary</name>
<email>Gary.Hook@amd.com</email>
</author>
<published>2019-07-10T00:09:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=561c4424f1e3f30615bc5701151709e0b59e1d3e'/>
<id>urn:sha1:561c4424f1e3f30615bc5701151709e0b59e1d3e</id>
<content type='text'>
commit 20e833dc36355ed642d00067641a679c618303fa upstream.

The AES GCM function reuses an 'op' data structure, which members
contain values that must be cleared for each (re)use.

This fix resolves a crypto self-test failure:
alg: aead: gcm-aes-ccp encryption test failed (wrong result) on test vector 2, cfg="two even aligned splits"

Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gary R Hook &lt;gary.hook@amd.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: crypto4xx - block ciphers should only accept complete blocks</title>
<updated>2019-07-26T07:14:20Z</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@gmail.com</email>
</author>
<published>2019-05-18T21:28:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=13805a5df489c4c870b3aaca2be56ee26c6db0c7'/>
<id>urn:sha1:13805a5df489c4c870b3aaca2be56ee26c6db0c7</id>
<content type='text'>
commit 0f7a81374060828280fcfdfbaa162cb559017f9f upstream.

The hardware automatically zero pads incomplete block ciphers
blocks without raising any errors. This is a screw-up. This
was noticed by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS tests that
sent a incomplete blocks and expect them to fail.

This fixes:
cbc-aes-ppc4xx encryption unexpectedly succeeded on test vector
"random: len=2409 klen=32"; expected_error=-22, cfg="random:
may_sleep use_digest src_divs=[96.90%@+2295, 2.34%@+4066,
0.32%@alignmask+12, 0.34%@+4087, 0.9%@alignmask+1787, 0.1%@+3767]
iv_offset=6"

ecb-aes-ppc4xx encryption unexpectedly succeeded on test vector
"random: len=1011 klen=32"; expected_error=-22, cfg="random:
may_sleep use_digest src_divs=[100.0%@alignmask+20]
dst_divs=[3.12%@+3001, 96.88%@+4070]"

Cc: Eric Biggers &lt;ebiggers@kernel.org&gt;
Cc: stable@vger.kernel.org [4.19, 5.0 and 5.1]
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.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: crypto4xx - fix blocksize for cfb and ofb</title>
<updated>2019-07-26T07:14:20Z</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@gmail.com</email>
</author>
<published>2019-05-18T21:28:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=17e63172d53640cb2ebc53088a4214f5db8afcfb'/>
<id>urn:sha1:17e63172d53640cb2ebc53088a4214f5db8afcfb</id>
<content type='text'>
commit 70c4997f34b6c6888b3ac157adec49e01d0df2d5 upstream.

While the hardware consider them to be blockciphers, the
reference implementation defines them as streamciphers.

Do the right thing and set the blocksize to 1. This
was found by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS.

This fixes the following issues:
skcipher: blocksize for ofb-aes-ppc4xx (16) doesn't match generic impl (1)
skcipher: blocksize for cfb-aes-ppc4xx (16) doesn't match generic impl (1)

Cc: Eric Biggers &lt;ebiggers@kernel.org&gt;
Cc: stable@vger.kernel.org
Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.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: crypto4xx - fix AES CTR blocksize value</title>
<updated>2019-07-26T07:14:20Z</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@gmail.com</email>
</author>
<published>2019-05-17T21:15:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4598094d24c7b89332ca4c45163f3aa802a140e5'/>
<id>urn:sha1:4598094d24c7b89332ca4c45163f3aa802a140e5</id>
<content type='text'>
commit bfa2ba7d9e6b20aca82b99e6842fe18842ae3a0f upstream.

This patch fixes a issue with crypto4xx's ctr(aes) that was
discovered by libcapi's kcapi-enc-test.sh test.

The some of the ctr(aes) encryptions test were failing on the
non-power-of-two test:

kcapi-enc - Error: encryption failed with error 0
kcapi-enc - Error: decryption failed with error 0
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits):
original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855)
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
(openssl generated CT): original file (e3b0..5) and generated file (3..8e)
[PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits)
(openssl generated PT)
[FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password):
original file (1d1..84c) and generated file (e3b..852b855)

But the 16, 32, 512, 65536 tests always worked.

Thankfully, this isn't a hidden hardware problem like previously,
instead this turned out to be a copy and paste issue.

With this patch, all the tests are passing with and
kcapi-enc-test.sh gives crypto4xx's a clean bill of health:
 "Number of failures: 0" :).

Cc: stable@vger.kernel.org
Fixes: 98e87e3d933b ("crypto: crypto4xx - add aes-ctr support")
Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.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>
</feed>
