This patch fixes two issues observed during self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled.
1. gcm(aes) hang issue , that happens during decryption.
2. rfc4106-gcm-aes-chcr encryption unexpectedly succeeded.
For gcm-aes decryption , authtag is not mapped due to
sg_nents_for_len(upto si
The ccm(aes) test fails when req->assoclen > ~240bytes.
The problem is the value assigned to auth_offset is wrong.
As auth_offset is unsigned char, it can take max value as 255.
So fix it by making it unsigned int.
Signed-off-by: Ayush Sawal
Signed-off-by: Devulapally Shiva Krishna
---
drivers
The following series of patches fixes the issues which came during
self-tests with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled.
Patch 1: Fixes gcm(aes) hang issue and rfc4106-gcm encryption issue.
Patch 2: Fixes ctr, cbc, xts and rfc3686-ctr extra test failures.
Patch 3: Fixes ccm(aes) extra test fa
This solves the following issues observed during self test when
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is enabled.
1. Added fallback for cbc, ctr and rfc3686 if req->nbytes is zero
and for xts added a fallback case if req->nbytes is not multiple of 16.
2. In case of cbc-aes, solved wrong iv update. Wh
Added support for 48 byte key length for aes-xts.
Signed-off-by: Ayush Sawal
Signed-off-by: Devulapally Shiva Krishna
---
drivers/crypto/chelsio/chcr_algo.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c
b/dri
The hmac(sha) test fails for a zero length source text data.
For hmac(sha) minimum length of the data must be of block-size.
So fix this by including the data_len for the last block.
Signed-off-by: Ayush Sawal
Signed-off-by: Devulapally Shiva Krishna
---
drivers/crypto/chelsio/chcr_algo.c | 2 +
On Mon, May 04, 2020 at 09:48:44PM -0400, Daniel Jordan wrote:
> On Mon, May 04, 2020 at 05:40:19PM -0700, Alexander Duyck wrote:
> > On Mon, May 4, 2020 at 4:44 PM Josh Triplett wrote:
> > >
> > > On May 4, 2020 3:33:58 PM PDT, Alexander Duyck
> > > wrote:
> > > >On Thu, Apr 30, 2020 at 1:12 PM
On Mon, May 04, 2020 at 05:40:19PM -0700, Alexander Duyck wrote:
> On Mon, May 4, 2020 at 4:44 PM Josh Triplett wrote:
> >
> > On May 4, 2020 3:33:58 PM PDT, Alexander Duyck
> > wrote:
> > >On Thu, Apr 30, 2020 at 1:12 PM Daniel Jordan
> > > wrote:
> > >> /*
> > >> -* Initialize
On Mon, May 04, 2020 at 03:33:58PM -0700, Alexander Duyck wrote:
> On Thu, Apr 30, 2020 at 1:12 PM Daniel Jordan
> > @@ -1778,15 +1798,25 @@ static int __init deferred_init_memmap(void *data)
> > goto zone_empty;
> >
> > /*
> > -* Initialize and free pages in MAX_ORD
On Mon, May 04, 2020 at 03:10:46PM -0700, Alexander Duyck wrote:
> So we cannot stop in the middle of a max order block. That shouldn't
> be possible as part of the issue is that the buddy allocator will
> attempt to access the buddy for the page which could cause issues if
> it tries to merge the
On Mon, May 4, 2020 at 4:44 PM Josh Triplett wrote:
>
> On May 4, 2020 3:33:58 PM PDT, Alexander Duyck
> wrote:
> >On Thu, Apr 30, 2020 at 1:12 PM Daniel Jordan
> > wrote:
> >> /*
> >> -* Initialize and free pages in MAX_ORDER sized increments so
> >> -* that we can avoid
On May 4, 2020 3:33:58 PM PDT, Alexander Duyck
wrote:
>On Thu, Apr 30, 2020 at 1:12 PM Daniel Jordan
> wrote:
>> /*
>> -* Initialize and free pages in MAX_ORDER sized increments so
>> -* that we can avoid introducing any issues with the buddy
>> -* allocator.
>> +
On Thu, Apr 30, 2020 at 1:12 PM Daniel Jordan
wrote:
>
> Deferred struct page init uses one thread per node, which is a
> significant bottleneck at boot for big machines--often the largest.
> Parallelize to reduce system downtime.
>
> The maximum number of threads is capped at the number of CPUs o
On Thu, Apr 30, 2020 at 7:45 PM Daniel Jordan
wrote:
>
> Hi Alex,
>
> On Thu, Apr 30, 2020 at 02:43:28PM -0700, Alexander Duyck wrote:
> > On 4/30/2020 1:11 PM, Daniel Jordan wrote:
> > > padata will soon divide up pfn ranges between threads when parallelizing
> > > deferred init, and deferred_ini
> On May 4, 2020, at 3:07 PM, bfie...@fieldses.org wrote:
>
> On Fri, May 01, 2020 at 03:04:00PM -0400, Chuck Lever wrote:
>> Over the past year or so I've observed that using sec=krb5i or
>> sec=krb5p with NFS/RDMA while testing my Linux NFS client and server
>> results in frequent connection
On Fri, May 01, 2020 at 10:31:17PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Instead of manually allocating a 'struct shash_desc' on the stack and
> calling crypto_shash_digest(), switch to using the new helper function
> crypto_shash_tfm_digest() which does this for us.
>
> Cc: linux-
On Fri, May 01, 2020 at 03:04:00PM -0400, Chuck Lever wrote:
> Over the past year or so I've observed that using sec=krb5i or
> sec=krb5p with NFS/RDMA while testing my Linux NFS client and server
> results in frequent connection loss. I've been able to pin this down
> a bit.
>
> The problem is th
From: Arnd Bergmann
Date: Thu, 30 Apr 2020 12:39:02 +0200
> gcc-10 warns about functions that return a pointer to a stack
> variable. In chcr_write_cpl_set_tcb_ulp(), this does not actually
> happen, but it's too hard to see for the compiler:
>
> drivers/crypto/chelsio/chcr_ktls.c: In function
Eric Biggers writes:
> From: Eric Biggers
>
> The PowerPC implementation of SHA-1 doesn't actually use the 16-word
> temporary array that's passed to the assembly code. This was probably
> meant to correspond to the 'W' array that lib/sha1.c uses. However, in
> sha1-powerpc-asm.S these values a
On Fri, May 01, 2020 at 10:59:45PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> crypto_shash_descsize() returns the size of the shash_desc context
> needed to compute the hash, not the size of the hash itself.
>
> crypto_shash_digestsize() would be correct, or alternatively using
> c->has
20 matches
Mail list logo
