| 30a50e44 | 01-Jan-2020 |
Christian Lamparter <chunkeey@gmail.com> |
crypto: crypto4xx - use GFP_KERNEL for big allocations
The driver should use GFP_KERNEL for the bigger allocation
during the driver's crypto4xx_probe() and not GFP_ATOMIC in
my opinion.
Signed-off-
crypto: crypto4xx - use GFP_KERNEL for big allocations
The driver should use GFP_KERNEL for the bigger allocation
during the driver's crypto4xx_probe() and not GFP_ATOMIC in
my opinion.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
| b87b2c4d | 01-Jan-2020 |
Christian Lamparter <chunkeey@gmail.com> |
crypto: crypto4xx - reduce memory fragmentation
With recent kernels (>5.2), the driver fails to probe, as the
allocation of the driver's scatter buffer fails with -ENOMEM.
This happens in crypto4xx
crypto: crypto4xx - reduce memory fragmentation
With recent kernels (>5.2), the driver fails to probe, as the
allocation of the driver's scatter buffer fails with -ENOMEM.
This happens in crypto4xx_build_sdr(). Where the driver tries
to get 512KiB (=PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD) of
continuous memory. This big chunk is by design, since the driver
uses this circumstance in the crypto4xx_copy_pkt_to_dst() to
its advantage:
"all scatter-buffers are all neatly organized in one big
continuous ringbuffer; So scatterwalk_map_and_copy() can be
instructed to copy a range of buffers in one go."
The PowerPC arch does not have support for DMA_CMA. Hence,
this patch reorganizes the order in which the memory
allocations are done. Since the driver itself is responsible
for some of the issues.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
| af5034e8 | 30-Dec-2019 |
Eric Biggers <ebiggers@google.com> |
crypto: remove propagation of CRYPTO_TFM_RES_* flags
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
->setkey() functions provide more information about errors. But these
flag
crypto: remove propagation of CRYPTO_TFM_RES_* flags
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
->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
->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 <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
| 95566aa7 | 08-Jul-2019 |
Wen Yang <wen.yang99@zte.com.cn> |
crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probe
There is a possible double free issue in ppc4xx_trng_probe():
85: dev->trng_base = of_iomap(trng, 0);
86: of_node_put(trng);
crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probe
There is a possible double free issue in ppc4xx_trng_probe():
85: dev->trng_base = of_iomap(trng, 0);
86: of_node_put(trng); ---> released here
87: if (!dev->trng_base)
88: goto err_out;
...
110: ierr_out:
111: of_node_put(trng); ---> 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 <wen.yang99@zte.com.cn>
Cc: <stable@vger.kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Allison Randal <allison@lohutok.net>
Cc: Armijn Hemel <armijn@tjaldur.nl>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
| 0f7a8137 | 18-May-2019 |
Christian Lamparter <chunkeey@gmail.com> |
crypto: crypto4xx - block ciphers should only accept complete blocks
The hardware automatically zero pads incomplete block ciphers
blocks without raising any errors. This is a screw-up. This
was not
crypto: crypto4xx - block ciphers should only accept complete blocks
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 <ebiggers@kernel.org>
Cc: stable@vger.kernel.org [4.19, 5.0 and 5.1]
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
| 70c4997f | 18-May-2019 |
Christian Lamparter <chunkeey@gmail.com> |
crypto: crypto4xx - fix blocksize for cfb and ofb
While the hardware consider them to be blockciphers, the
reference implementation defines them as streamciphers.
Do the right thing and set the blo
crypto: crypto4xx - fix blocksize for cfb and ofb
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 <ebiggers@kernel.org>
Cc: stable@vger.kernel.org
Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
| 38cf5533 | 22-Apr-2019 |
Christian Lamparter <chunkeey@gmail.com> |
crypto: crypto4xx - get rid of redundant using_sd variable
using_sd is used as a stand-in for sa_command_0.bf.scatter
that we need to set anyway, so we might as well just prevent
double-accounting.
crypto: crypto4xx - get rid of redundant using_sd variable
using_sd is used as a stand-in for sa_command_0.bf.scatter
that we need to set anyway, so we might as well just prevent
double-accounting.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|