public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Robert Elliott <elliott@hpe.com>,
	tim.c.chen@linux.intel.com, davem@davemloft.net,
	linux-crypto@vger.kernel.org, toshi.kani@hpe.com,
	rwright@hpe.com
Subject: Re: [PATCH] crypto: testmgr - don't generate WARN for missing modules
Date: Fri, 19 Aug 2022 16:15:16 -0700	[thread overview]
Message-ID: <YwAZhFLCrlHXegr9@sol.localdomain> (raw)
In-Reply-To: <Yv9uhQY7UAPN7QDE@gondor.apana.org.au>

On Fri, Aug 19, 2022 at 07:05:41PM +0800, Herbert Xu wrote:
> Robert Elliott <elliott@hpe.com> wrote:
> > This userspace command:
> >    modprobe tcrypt
> > or
> >    modprobe tcrypt mode=0
> > 
> > runs all the tcrypt test cases numbered <200 (i.e., all the
> > test cases calling tcrypt_test() and returning return values).
> > 
> > Tests are sparsely numbered from 0 to 1000. For example:
> >    modprobe tcrypt mode=12
> > tests sha512, and
> >    modprobe tcrypt mode=152
> > tests rfc4543(gcm(aes))) - AES-GCM as GMAC
> > 
> > The test manager generates WARNING crashdumps every time it attempts
> > a test using an algorithm that is not available (not built-in to the
> > kernel or available as a module):
> > 
> >    alg: skcipher: failed to allocate transform for ecb(arc4): -2
> >    ------------[ cut here ]-----------
> >    alg: self-tests for ecb(arc4) (ecb(arc4)) failed (rc=-2)
> >    WARNING: CPU: 9 PID: 4618 at crypto/testmgr.c:5777
> > alg_test+0x30b/0x510
> >    [50 more lines....]
> > 
> >    ---[ end trace 0000000000000000 ]---
> > 
> > If the kernel is compiled with CRYPTO_USER_API_ENABLE_OBSOLETE
> > disabled (the default), then these algorithms are not compiled into
> > the kernel or made into modules and trigger WARNINGs:
> >    arc4 tea xtea khazad anubis xeta seed
> > 
> > Additionally, any other algorithms that are not enabled in .config
> > will generate WARNINGs. In RHEL 9.0, for example, the default
> > selection of algorithms leads to 16 WARNING dumps.
> > 
> > One attempt to fix this was by modifying tcrypt_test() to check
> > crypto_has_alg() and immediately return 0 if crypto_has_alg() fails,
> > rather than proceed and return a non-zero error value that causes
> > the caller (alg_test() in crypto/testmgr.c) to invoke WARN().
> > That knocks out too many algorithms, though; some combinations
> > like ctr(des3_ede) would work.
> > 
> > Instead, change the condition on the WARN to ignore a return
> > value is ENOENT, which is the value returned when the algorithm
> > or combination of algorithms doesn't exist. Add a pr_warn to
> > communicate that information in case the WARN is skipped.
> > 
> > This approach allows algorithm tests to work that are combinations,
> > not provided by one driver, like ctr(blowfish).
> > 
> > Result - no more WARNINGs:
> > modprobe tcrypt
> > [  115.541765] tcrypt: testing md5
> > [  115.556415] tcrypt: testing sha1
> > [  115.570463] tcrypt: testing ecb(des)
> > [  115.585303] cryptomgr: alg: skcipher: failed to allocate transform for ecb(des): -2
> > [  115.593037] cryptomgr: alg: self-tests for ecb(des) using ecb(des) failed (rc=-2)
> > [  115.593038] tcrypt: testing cbc(des)
> > [  115.610641] cryptomgr: alg: skcipher: failed to allocate transform for cbc(des): -2
> > [  115.618359] cryptomgr: alg: self-tests for cbc(des) using cbc(des) failed (rc=-2)
> > ...
> > 
> > Signed-off-by: Robert Elliott <elliott@hpe.com>
> > ---
> > crypto/testmgr.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> 
> Patch applied.  Thanks.

I thought the conclusion from the discussion was that this should instead be
solved by a tcrypt change?  Either dropping the enumerative testing support from
tcrypt, or making tcrypt just try to allocate the algorithms (relying on the
registration-time self-tests) rather than call alg_test() directly.

- Eric

  reply	other threads:[~2022-08-19 23:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-13 23:14 [PATCH] crypto: testmgr - don't generate WARN for missing modules Robert Elliott
2022-08-15 21:30 ` Eric Biggers
2022-08-16  2:43   ` Herbert Xu
2022-08-16  5:09     ` Stephan Mueller
2022-08-16  5:49       ` Herbert Xu
2022-08-19 11:05 ` Herbert Xu
2022-08-19 23:15   ` Eric Biggers [this message]
2022-08-20  0:15     ` Elliott, Robert (Servers)
2022-08-20  0:40       ` Eric Biggers

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=YwAZhFLCrlHXegr9@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=davem@davemloft.net \
    --cc=elliott@hpe.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=rwright@hpe.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=toshi.kani@hpe.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox