Hi Thara,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on crypto/master v5.11-rc3 next-20210111]
[cannot apply to sparc-next/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Export and import interfaces save and restore partial transformation
states. The partial states were being stored and restored in struct
sha1_state for sha1/hmac(sha1) transformations and sha256_state for
sha256/hmac(sha256) transformations.This led to a bunch of corner cases
where improper state w
If the available data to transfer is exactly a multiple of block size, save
the last block to be transferred in qce_ahash_final (with the last block
bit set) if this is indeed the end of data stream. If not this saved block
will be transferred as part of next update. If this block is not held back
Set the register REG_ENCR_XTS_DU_SIZE to cryptlen for AES XTS
transformation. Anything else causes the engine to return back
wrong results.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/common.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qce
totallen is used to get the size of the data to be transformed.
This is also available via nbytes or cryptlen in the qce_sha_reqctx
and qce_cipher_ctx. Similarly offset convey nothing for the supported
encryption and authentication transformations and is always 0.
Remove these two redundant paramet
src_table is unused and hence remove it from struct qce_cipher_reqctx
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/cipher.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/qce/cipher.h b/drivers/crypto/qce/cipher.h
index cffa9fc628ff..850f257d00f3 100644
--- a/drivers/c
This patch contains the following fixes for the supported encryption
algorithms in the Qualcomm crypto engine(CE)
1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
does not support this and the operation causes the engine to hang.
2. Return unsupprted if any three keys are same fo
This patch series is a result of running kernel crypto fuzz tests (by
enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS) on the transformations
currently supported via the Qualcomm crypto engine on sdm845. The first
four patches are fixes for various regressions found during testing. The
last two patches
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Allen Pais
---
drivers/crypto/marvell/octeontx/otx_cptvf_mai
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Romain Perier
Signed-off-by: A
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Reviewed-by: Horia Geantă
Signed-off-by: Romain Perier
Signed-off-by: Allen
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
drivers/crypto/
From: Allen Pais
Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
introduced a new tasklet initialization API. This series converts
all the crypto modules to use the new tasklet_setup() API
The series is based on v5.11-rc2 (e71ba9452f0b)
v3:
- fixed rockchip driver(Emil Renne
On Mon, 2021-01-04 at 22:49 +0100, Stephan Müller wrote:
> The kernel crypto API provides the SP800-108 counter KDF implementation.
> Thus, the separate implementation provided as part of the keys subsystem
> can be replaced with calls to the KDF offered by the kernel crypto API.
>
> The keys subs
Hi Ard,
I love your patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on crypto/master linus/master v5.11-rc3 next-20210111]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
On Mon, 11 Jan 2021 at 22:05, Eric Biggers wrote:
>
> On Mon, Jan 11, 2021 at 05:52:30PM +0100, Ard Biesheuvel wrote:
> > CRC-T10DIF is a very poor match for the crypto API:
> > - every user in the kernel calls it via a library wrapper around the
> > shash API, so all callers share a single inst
On Mon, Jan 11, 2021 at 05:52:30PM +0100, Ard Biesheuvel wrote:
> CRC-T10DIF is a very poor match for the crypto API:
> - every user in the kernel calls it via a library wrapper around the
> shash API, so all callers share a single instance of the transform
> - each architecture provides at most
On Mon, 11 Jan 2021 at 21:56, Peter Zijlstra wrote:
>
> On Mon, Jan 11, 2021 at 07:36:20PM +0100, Ard Biesheuvel wrote:
> > On Mon, 11 Jan 2021 at 18:27, Ard Biesheuvel wrote:
> > > On Mon, 11 Jan 2021 at 17:52, Ard Biesheuvel wrote:
>
> > > > Special request to Peter to take a look at patch #2,
On Mon, Jan 11, 2021 at 07:36:20PM +0100, Ard Biesheuvel wrote:
> On Mon, 11 Jan 2021 at 18:27, Ard Biesheuvel wrote:
> > On Mon, 11 Jan 2021 at 17:52, Ard Biesheuvel wrote:
> > > Special request to Peter to take a look at patch #2, and in particular,
> > > whether synchronize_rcu_tasks() is suf
On Mon, 11 Jan 2021 at 18:27, Ard Biesheuvel wrote:
>
> On Mon, 11 Jan 2021 at 17:52, Ard Biesheuvel wrote:
> >
> > CRC-T10DIF is a very poor match for the crypto API:
> > - every user in the kernel calls it via a library wrapper around the
> > shash API, so all callers share a single instance
On Mon, 11 Jan 2021 at 17:52, Ard Biesheuvel wrote:
>
> CRC-T10DIF is a very poor match for the crypto API:
> - every user in the kernel calls it via a library wrapper around the
> shash API, so all callers share a single instance of the transform
> - each architecture provides at most a single
Get rid of the shash boilerplate, and register the accelerated ARM
version of the CRC-T10DIF algorithm with the library interface instead.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/crct10dif-ce-glue.c | 58
1 file changed, 11 insertions(+), 47 deletions(-)
diff --gi
Get rid of the shash boilerplate, and register the accelerated PowerPC
version of the CRC-T10DIF algorithm with the library interface instead.
Signed-off-by: Ard Biesheuvel
---
arch/powerpc/crypto/crct10dif-vpmsum_glue.c | 51 ++--
1 file changed, 4 insertions(+), 47 deletions(-)
Get rid of the shash boilerplate, and register the accelerated arm64
version of the CRC-T10DIF algorithm with the library interface instead.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crct10dif-ce-glue.c | 85
1 file changed, 15 insertions(+), 70 deletions(-)
diff
Wire up the new static call facility to the CRC-T10DIF library code, so
that optimized implementations can be swapped in easily, without having
to rely on the complexity of the crypto API shash infrastructure.
Signed-off-by: Ard Biesheuvel
---
include/linux/crc-t10dif.h | 21 --
lib/
In order to retain the ability to check accelerated implementations of
CRC-T10DIF against the generic C implementation, expose both via the
generic crypto API shash driver. This relies on the arch specific version
to be registered beforehand - this will generally be the case, given that
the modules
Get rid of the shash boilerplate, and register the accelerated x86
version of the CRC-T10DIF algorithm with the library interface instead.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/crct10dif-pclmul_glue.c | 90 +++-
1 file changed, 10 insertions(+), 80 deletions(-)
diff
As a first step towards moving CRC-T10DIF out of the crypto API, drop
the shash wrapping code from the library implementation, and move the
generic core CRC-T10DIF into it from the generic crypto SHASH driver.
In a future patch, the library interface will be augmented with the
facilities to regist
CRC-T10DIF is a very poor match for the crypto API:
- every user in the kernel calls it via a library wrapper around the
shash API, so all callers share a single instance of the transform
- each architecture provides at most a single optimized implementation,
based on SIMD instructions for carr
On January 6, 2021 10:37:50 PM PST, Borislav Petkov wrote:
>On Thu, Jan 07, 2021 at 02:19:06PM +0800, Tony W Wang-oc wrote:
>> SSE4.2 on Zhaoxin CPUs are compatible with Intel. The presence of
>> CRC32C instruction is enumerated by CPUID.01H:ECX.SSE4_2[bit 20] = 1.
>> Some Zhaoxin CPUs declare sup
On Mon, Jan 11, 2021 at 06:51:59PM +0800, Tony W Wang-oc wrote:
> This issue will be enhanced by hardware and patch submit will be pending.
I have no clue what that has to do with your current patch... you might
need to explain more verbosely.
--
Regards/Gruss,
Boris.
https://people.kernel.
On 07/01/2021 23:52, Dave Hansen wrote:
> On 1/6/21 10:19 PM, Tony W Wang-oc wrote:
>> +/*
>> + * These CPUs declare support SSE4.2 instruction sets but
>> + * having low performance CRC32C instruction implementation.
>> + */
>> +if (c->x86 == 0x6 || (c->x86 == 0x7 && c->x86_mod
On 07/01/2021 14:37, Borislav Petkov wrote:
> On Thu, Jan 07, 2021 at 02:19:06PM +0800, Tony W Wang-oc wrote:
>> SSE4.2 on Zhaoxin CPUs are compatible with Intel. The presence of
>> CRC32C instruction is enumerated by CPUID.01H:ECX.SSE4_2[bit 20] = 1.
>> Some Zhaoxin CPUs declare support SSE4.2 i
48 matches
Mail list logo
