From: Eric Biggers <ebiggers@kernel.org>
To: Daniel Axtens <dja@axtens.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Michael Ellerman <mpe@ellerman.id.au>,
Nayna <nayna@linux.vnet.ibm.com>,
leo.barbosa@canonical.com, Stephan Mueller <smueller@chronox.de>,
nayna@linux.ibm.com, omosnacek@gmail.com, leitao@debian.org,
pfsmorigo@gmail.com, linux-crypto@vger.kernel.org,
marcelo.cerri@canonical.com,
George Wilson <gcwilson@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode
Date: Wed, 15 May 2019 19:56:04 -0700 [thread overview]
Message-ID: <20190516025603.GB23200@sol.localdomain> (raw)
In-Reply-To: <871s0z171b.fsf@dja-thinkpad.axtens.net>
On Thu, May 16, 2019 at 12:12:48PM +1000, Daniel Axtens wrote:
>
> I'm also seeing issues with ghash with the extended tests:
>
> [ 7.582926] alg: hash: p8_ghash test failed (wrong result) on test vector 0, cfg="random: use_final src_divs=[<reimport>9.72%@+39832, <reimport>18.2%@+65504, <reimport,nosimd>45.57%@alignmask+18, <reimport,nosimd>15.6%@+65496, 6.83%@+65514, <reimport,nosimd>1.2%@+25, <reim"
>
> It seems to happen when one of the source divisions has nosimd and the
> final result uses the simd finaliser, so that's interesting.
>
The bug is that p8_ghash uses different shash_descs for the SIMD and no-SIMD
cases. So if you start out doing the hash in SIMD context but then switch to
no-SIMD context or vice versa, the digest will be wrong. Note that there can be
an ->export() and ->import() in between, so it's not quite as obscure a case as
one might think.
To fix it I think you'll need to make p8_ghash use 'struct ghash_desc_ctx' just
like ghash-generic so that the two code paths can share the same shash_desc.
That's similar to what the various SHA hash algorithms do.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Daniel Axtens <dja@axtens.net>
Cc: leo.barbosa@canonical.com, nayna@linux.ibm.com,
Herbert Xu <herbert@gondor.apana.org.au>,
Stephan Mueller <smueller@chronox.de>,
Nayna <nayna@linux.vnet.ibm.com>,
omosnacek@gmail.com, marcelo.cerri@canonical.com,
pfsmorigo@gmail.com, linux-crypto@vger.kernel.org,
leitao@debian.org, George Wilson <gcwilson@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode
Date: Wed, 15 May 2019 19:56:04 -0700 [thread overview]
Message-ID: <20190516025603.GB23200@sol.localdomain> (raw)
In-Reply-To: <871s0z171b.fsf@dja-thinkpad.axtens.net>
On Thu, May 16, 2019 at 12:12:48PM +1000, Daniel Axtens wrote:
>
> I'm also seeing issues with ghash with the extended tests:
>
> [ 7.582926] alg: hash: p8_ghash test failed (wrong result) on test vector 0, cfg="random: use_final src_divs=[<reimport>9.72%@+39832, <reimport>18.2%@+65504, <reimport,nosimd>45.57%@alignmask+18, <reimport,nosimd>15.6%@+65496, 6.83%@+65514, <reimport,nosimd>1.2%@+25, <reim"
>
> It seems to happen when one of the source divisions has nosimd and the
> final result uses the simd finaliser, so that's interesting.
>
The bug is that p8_ghash uses different shash_descs for the SIMD and no-SIMD
cases. So if you start out doing the hash in SIMD context but then switch to
no-SIMD context or vice versa, the digest will be wrong. Note that there can be
an ->export() and ->import() in between, so it's not quite as obscure a case as
one might think.
To fix it I think you'll need to make p8_ghash use 'struct ghash_desc_ctx' just
like ghash-generic so that the two code paths can share the same shash_desc.
That's similar to what the various SHA hash algorithms do.
- Eric
next prev parent reply other threads:[~2019-05-16 2:56 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 2:09 [PATCH] crypto: vmx - fix copy-paste error in CTR mode Daniel Axtens
2019-03-15 2:09 ` Daniel Axtens
2019-03-15 2:24 ` Eric Biggers
2019-03-15 2:24 ` Eric Biggers
2019-03-15 4:24 ` Daniel Axtens
2019-03-15 4:24 ` Daniel Axtens
2019-03-15 4:34 ` Eric Biggers
2019-03-15 4:34 ` Eric Biggers
2019-03-15 5:23 ` Daniel Axtens
2019-03-15 5:23 ` Daniel Axtens
2019-04-10 7:02 ` Eric Biggers
2019-04-10 7:02 ` Eric Biggers
2019-04-11 14:47 ` Daniel Axtens
2019-04-11 14:47 ` Daniel Axtens
2019-04-11 17:40 ` Nayna
2019-04-11 17:40 ` Nayna
2019-04-13 3:41 ` Michael Ellerman
2019-04-13 3:41 ` Michael Ellerman
2019-05-06 15:53 ` Eric Biggers
2019-05-06 15:53 ` Eric Biggers
2019-05-13 0:59 ` Herbert Xu
2019-05-13 0:59 ` Herbert Xu
2019-05-13 11:39 ` Michael Ellerman
2019-05-13 11:39 ` Michael Ellerman
2019-05-14 17:35 ` Daniel Axtens
2019-05-14 17:35 ` Daniel Axtens
2019-05-15 3:53 ` Herbert Xu
2019-05-15 3:53 ` Herbert Xu
2019-05-15 6:36 ` Daniel Axtens
2019-05-15 6:36 ` Daniel Axtens
2019-05-16 2:12 ` Daniel Axtens
2019-05-16 2:12 ` Daniel Axtens
2019-05-16 2:56 ` Eric Biggers [this message]
2019-05-16 2:56 ` Eric Biggers
2019-05-16 5:28 ` Daniel Axtens
2019-05-16 5:28 ` Daniel Axtens
2019-03-18 8:41 ` Michael Ellerman
2019-03-18 8:41 ` Michael Ellerman
2019-03-18 9:13 ` Ard Biesheuvel
2019-03-18 9:13 ` Ard Biesheuvel
2019-03-19 0:52 ` Michael Ellerman
2019-03-19 0:52 ` Michael Ellerman
2019-03-18 6:03 ` Michael Ellerman
2019-03-18 6:03 ` Michael Ellerman
2019-03-20 8:40 ` Ondrej Mosnáček
2019-03-20 8:40 ` Ondrej Mosnáček
2019-03-22 13:04 ` Herbert Xu
2019-03-22 13:04 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190516025603.GB23200@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=dja@axtens.net \
--cc=gcwilson@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=leitao@debian.org \
--cc=leo.barbosa@canonical.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=marcelo.cerri@canonical.com \
--cc=mpe@ellerman.id.au \
--cc=nayna@linux.ibm.com \
--cc=nayna@linux.vnet.ibm.com \
--cc=omosnacek@gmail.com \
--cc=pfsmorigo@gmail.com \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.