All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Eric Biggers <ebiggers@kernel.org>, Daniel Axtens <dja@axtens.net>
Cc: leo.barbosa@canonical.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	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, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode
Date: Mon, 18 Mar 2019 19:41:42 +1100	[thread overview]
Message-ID: <87pnqo7ewp.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190315043433.GC1671@sol.localdomain>

Eric Biggers <ebiggers@kernel.org> writes:
> On Fri, Mar 15, 2019 at 03:24:35PM +1100, Daniel Axtens wrote:
...
>> >> This leads to corruption of the IV, which leads to subsequent blocks
>> >> being corrupted.
>> >> 
>> >> This can be detected with libkcapi test suite, which is available at
>> >> https://github.com/smuellerDD/libkcapi
>> >
>> > Is this also detected by the kernel's crypto self-tests, and if not why not?
>> > What about with the new option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y?
>> 
>> It seems the self-tests do not catch it. To catch it, there has to be a
>> test where the blkcipher_walk creates a walk.nbytes such that
>> [(the number of AES blocks) mod 8] is either 2 or 3. This happens with
>> AF_ALG pretty frequently, but when I booted with self-tests it only hit
>> 1, 4, 5, 6 and 7 - it missed 0, 2 and 3.
>> 
>> I don't have the EXTRA_TESTS option - I'm testing with 5.0-rc6. Is it in
>> -next?
>
> The improvements I recently made to the self-tests are intended to catch exactly
> this sort of bug.  They were just merged for v5.1, so try the latest mainline.
> This almost certainly would be caught by EXTRA_TESTS (and if not I'd want to
> know), but it may be caught by the regular self-tests now too.

Enabling the crypto tests (CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n)
actually hides the bug for me.

By which I mean I can't trigger the bug via kcapi-enc-tests.sh, because
the VMX code is never called.

ie:
  # zgrep -e CRYPTO_MANAGER -e VMX /proc/config.gz
  CONFIG_CRYPTO_MANAGER=y
  CONFIG_CRYPTO_MANAGER2=y
  # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
  # CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
  CONFIG_CRYPTO_DEV_VMX=y
  CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y

  # echo "p:p8_aes_ctr_crypt p8_aes_ctr_crypt" > /sys/kernel/debug/tracing/kprobe_events
  # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
  # ./kcapi-enc-test.sh
  ...
  Number of failures: 0
  # grep -c p8_aes_ctr_crypt  /sys/kernel/debug/tracing/trace
  0


I don't understand how the crypto core chooses which crypto_alg to use,
but I didn't expect enabling the tests to change it?

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Eric Biggers <ebiggers@kernel.org>, Daniel Axtens <dja@axtens.net>
Cc: leo.barbosa@canonical.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Stephan Mueller <smueller@chronox.de>,
	nayna@linux.ibm.com, omosnacek@gmail.com,
	marcelo.cerri@canonical.com, pfsmorigo@gmail.com,
	linux-crypto@vger.kernel.org, leitao@debian.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode
Date: Mon, 18 Mar 2019 19:41:42 +1100	[thread overview]
Message-ID: <87pnqo7ewp.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190315043433.GC1671@sol.localdomain>

Eric Biggers <ebiggers@kernel.org> writes:
> On Fri, Mar 15, 2019 at 03:24:35PM +1100, Daniel Axtens wrote:
...
>> >> This leads to corruption of the IV, which leads to subsequent blocks
>> >> being corrupted.
>> >> 
>> >> This can be detected with libkcapi test suite, which is available at
>> >> https://github.com/smuellerDD/libkcapi
>> >
>> > Is this also detected by the kernel's crypto self-tests, and if not why not?
>> > What about with the new option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y?
>> 
>> It seems the self-tests do not catch it. To catch it, there has to be a
>> test where the blkcipher_walk creates a walk.nbytes such that
>> [(the number of AES blocks) mod 8] is either 2 or 3. This happens with
>> AF_ALG pretty frequently, but when I booted with self-tests it only hit
>> 1, 4, 5, 6 and 7 - it missed 0, 2 and 3.
>> 
>> I don't have the EXTRA_TESTS option - I'm testing with 5.0-rc6. Is it in
>> -next?
>
> The improvements I recently made to the self-tests are intended to catch exactly
> this sort of bug.  They were just merged for v5.1, so try the latest mainline.
> This almost certainly would be caught by EXTRA_TESTS (and if not I'd want to
> know), but it may be caught by the regular self-tests now too.

Enabling the crypto tests (CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n)
actually hides the bug for me.

By which I mean I can't trigger the bug via kcapi-enc-tests.sh, because
the VMX code is never called.

ie:
  # zgrep -e CRYPTO_MANAGER -e VMX /proc/config.gz
  CONFIG_CRYPTO_MANAGER=y
  CONFIG_CRYPTO_MANAGER2=y
  # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
  # CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
  CONFIG_CRYPTO_DEV_VMX=y
  CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y

  # echo "p:p8_aes_ctr_crypt p8_aes_ctr_crypt" > /sys/kernel/debug/tracing/kprobe_events
  # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
  # ./kcapi-enc-test.sh
  ...
  Number of failures: 0
  # grep -c p8_aes_ctr_crypt  /sys/kernel/debug/tracing/trace
  0


I don't understand how the crypto core chooses which crypto_alg to use,
but I didn't expect enabling the tests to change it?

cheers

  parent reply	other threads:[~2019-03-18  8:41 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
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 [this message]
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=87pnqo7ewp.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=dja@axtens.net \
    --cc=ebiggers@kernel.org \
    --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=nayna@linux.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.