On Tue, Jun 23, 2020 at 10:02:17AM -0700, Eric Biggers wrote:
>
> The source code for the two failing AF_ALG tests is here:
>
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg02.c
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/a
On Sun, Jun 21, 2020 at 02:19:56PM +0300, Gilad Ben-Yossef wrote:
> Small fixes and adapt essiv support to the new template format
>
> ---
> Changes from v1:
> - Incorporate coding style fixes suggested by Markus Elfring.
>
> Gilad Ben-Yossef (3):
> crypto: ccree: fix resource leak on error pat
On Thu, Jun 18, 2020 at 11:16:25AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable err is being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused v
On Thu, Jun 18, 2020 at 11:12:29AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being assigned with a value that is never read
> and it is being updated later with a new value. The assignment is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
On Fri, Jun 19, 2020 at 04:22:53PM +0300, Horia Geantă wrote:
> ahash_finup_no_ctx() returns -ENOMEM in most error cases,
> and this is fine for almost all of them.
>
> However, the return code provided by dpaa2_caam_enqueue()
> (e.g. -EIO or -EBUSY) shouldn't be overridden by -ENOMEM.
>
> Signed
On Wed, Jun 17, 2020 at 09:48:56AM -0400, Mikulas Patocka wrote:
> There is this call chain:
> cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc
> where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
> was not specified.
>
> Signed-off-by: Mikulas
On Mon, Jun 15, 2020 at 11:38:37AM +0800, Zhangfei Gao wrote:
> Use strscpy to fix the warning
> warning: 'strncpy' specified bound 64 equals destination size
>
> Reported-by: kernel test robot
> Signed-off-by: Zhangfei Gao
> ---
> v2: Use strscpy instead of strlcpy since better truncation handl
This patch fixes all the sparse warnings in the octeontx driver.
Some of these are just trivial type changes.
However, some of the changes are non-trivial on little-endian hosts.
Obviously the driver appears to be broken on either LE or BE as it
was doing different things. I've taken the BE behav
On Wed, Jun 17, 2020 at 11:09:28AM -0400, Mikulas Patocka wrote:
>
> Index: linux-2.6/include/linux/crypto.h
> ===
> --- linux-2.6.orig/include/linux/crypto.h
> +++ linux-2.6/include/linux/crypto.h
> @@ -97,9 +97,18 @@
> #define CRYPT
On Mon, Jun 15, 2020 at 10:14:48AM +0300, Tero Kristo wrote:
>
> +static int sa_sha_update(struct ahash_request *req)
> +{
> + struct sa_sha_req_ctx *rctx = ahash_request_ctx(req);
> + struct scatterlist *sg;
> + void *buf;
> + int pages;
> + struct page *pg;
> +
> + if (!re
On Thu, Jun 25, 2020 at 08:56:49PM +0100, Giovanni Cabiddu wrote:
> On Thu, Jun 25, 2020 at 01:59:04PM +0100, Giovanni Cabiddu wrote:
> > + ctx->ftfm = crypto_alloc_skcipher("xts(aes)", 0, CRYPTO_ALG_ASYNC);
> > + if (IS_ERR(ctx->ftfm))
> > + return(PTR_ERR(ctx->ftfm));
> I just reali
Hi Ard,
I love your patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master sunxi/sunxi/for-next v5.8-rc2
next-20200625]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
PASID is defined as "int" although it's a 20-bit value and shouldn't be
negative int. To be consistent with PASID type in iommu, define PASID
as "u32".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
---
PASID type will be changed consistently as u32:
https://lore.kernel.org/patchwork/pa
On Thu, Jun 25, 2020 at 01:59:04PM +0100, Giovanni Cabiddu wrote:
> + ctx->ftfm = crypto_alloc_skcipher("xts(aes)", 0, CRYPTO_ALG_ASYNC);
> + if (IS_ERR(ctx->ftfm))
> + return(PTR_ERR(ctx->ftfm));
I just realized I added an extra pair of parenthesis around PTR_ERR.
Below is a ne
On Thu, 25 Jun 2020 at 21:16, David Miller wrote:
>
> From: Ard Biesheuvel
> Date: Thu, 25 Jun 2020 09:18:16 +0200
>
> > The skcipher API dynamically instantiates the transformation object
> > on request that implements the requested algorithm optimally on the
> > given platform. This notion of o
From: Ard Biesheuvel
Date: Thu, 25 Jun 2020 09:18:16 +0200
> The skcipher API dynamically instantiates the transformation object
> on request that implements the requested algorithm optimally on the
> given platform. This notion of optimality only matters for cases like
> bulk network or disk enc
On Thu, Jun 25, 2020 at 02:53:55PM +, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: 63b945091a07 ("crypto: ccp - CCP device driver and interface
> support").
>
> The bot has tested the followin
Hi Ard,
I love your patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master sunxi/sunxi/for-next v5.8-rc2
next-20200625]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 63b945091a07 ("crypto: ccp - CCP device driver and interface
support").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129, v4.14.185,
v4.9.228, v4.4.228.
v5.7.5: B
Hi,
I am trying to import a public key extracted along with signature(RSA-SHA384)
from my header.
When i tried to import the public key buffer to algo
crypto_akcipher_set_pub_key(), it fails
with -EBADMASG "ASN1: Unexpected tag" error msg.
My public in hex format and only contains modulus and ex
Forward requests to another provider if the key length is 192 bits as
this is not supported by the QAT accelerators.
This fixes the following issue reported by the extra self test:
alg: skcipher: qat_aes_xts setkey failed on test vector "random: len=3204
klen=48"; expected_error=0, actual_error=-2
Validate xts key using the function xts_verify_key() to prevent
malformed keys.
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/qat_algs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_alg
Remove tfm field in qat_alg_skcipher_ctx structure.
This is not used.
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/qat_algs.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index 11f
Allow aes xts requests that are not multiple of the block size.
If a request is smaller than the block size, return -EINVAL.
This fixes the following issue reported by the crypto testmgr self-test:
alg: skcipher: qat_aes_xts encryption failed on test vector "random:
len=116 klen=64"; expected_erro
This series fixes a few issues with the xts(aes) implementation in the
QuickAssist driver:
- Requests that are not multiple of the block size are rejected
- Input key not validated
- xts(aes) requests with key size 192 bits are rejected with -EINVAL
Giovanni Cabiddu (4):
crypto: qat - allow x
Even though the sun4i driver implements asynchronous versions of ecb(aes)
and cbc(aes), the fallbacks it allocates are required to be synchronous.
Given that SIMD based software implementations are usually asynchronous
as well, even though they rarely complete asynchronously (this typically
only ha
Even though the sahara driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only h
Even though the picoxcell driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically onl
Even though the qce driver implements asynchronous versions of ecb(aes),
cbc(aes)and xts(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically
Even though the omap-aes driver implements asynchronous versions of
ecb(aes), cbc(aes) and ctr(aes), the fallbacks it allocates are required
to be synchronous. Given that SIMD based software implementations are
usually asynchronous as well, even though they rarely complete
asynchronously (this typi
Even though the sun8i-ce driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only
Even though the sun8i-ss driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only
The AmLogic GXL crypto accelerator driver is built into the kernel if
ARCH_MESON is set. However, given the single image policy of arm64, its
defconfig enables all platforms by default, and so ARCH_MESON is usually
enabled.
This means that the AmLogic driver causes the arm64 defconfig build to
pul
Even though the ccp driver implements an asynchronous version of xts(aes),
the fallback it allocates is required to be synchronous. Given that SIMD
based software implementations are usually asynchronous as well, even
though they rarely complete asynchronously (this typically only happens
in cases
Even though the chelsio driver implements asynchronous versions of
cbc(aes) and xts(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only
Even though the mxs-dcp driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only
Even though the amlogic-gxl driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically o
The drivers for crypto accelerators in drivers/crypto all implement skciphers
of an asynchronous nature, given that they are backed by hardware DMA that
completes asynchronously wrt the execution flow.
However, in many cases, any fallbacks they allocate are limited to the
synchronous variety, whic
Hello Ard,
Quoting Ard Biesheuvel (2020-06-25 09:18:16)
> The skcipher API dynamically instantiates the transformation object
> on request that implements the requested algorithm optimally on the
> given platform. This notion of optimality only matters for cases like
> bulk network or disk encrypt
The skcipher API dynamically instantiates the transformation object
on request that implements the requested algorithm optimally on the
given platform. This notion of optimality only matters for cases like
bulk network or disk encryption, where performance can be a bottleneck,
or in cases where the
40 matches
Mail list logo
