From: Stephan Mueller <smueller@chronox.de>
To: Yujie Liu <yujie.liu@intel.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: Mat Martineau <mathew.j.martineau@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
lkp@lists.01.org, lkp@intel.com, "Sang,
Oliver" <oliver.sang@intel.com>
Subject: Re: [security] d3b04a4398: WARNING:at_crypto/kdf_sp800108.c:#crypto_kdf108_init
Date: Fri, 10 Dec 2021 15:16:34 +0100 [thread overview]
Message-ID: <3737408.Lz6Wf2Li4r@tauon.chronox.de> (raw)
In-Reply-To: <766e5415-cc94-1b46-2326-d55343a80388@intel.com>
Am Freitag, 10. Dezember 2021, 03:54:32 CET schrieb Yujie Liu:
Hi Yujie, Herbert,
> This table shows that we have tested commit d3b04a4398("security: DH - use
> KDF implementation from crypto API") for several runs of boot test in qemu
> but got 100% bad result. We have also tested its parent commit (i.e. commit
> d792134423 "security: DH - remove dead code for zero padding") and all the
> runs got 100% good result. So this is not a random issue.
>
> > I am unable to reproduce it with i386 and clang-13. I can also not
> > reproduce it with GCC.
>
> We have tested the i386 kernel built by gcc-9 or clang-14, and confirmed
> both of them can reproduce this issue reliably.
>
> Please be sure to follow the reproduce steps in original report mail. The
> full reproduce log is attached.
Thank you for your response. The key log info is:
alg: self-tests for CTR-KDF (hmac(sha256)) failed (rc=-12)
And I finally see what the problem is: you selected SHA-256 as module but the
KDF implementation is selected to be statically linked.
So the KDF self test tries to allocate the SHA-256 algorithm and fails which
causes the ENOMEM error.
Herbert, what is your preference in handling this:
- we could SELECT CRYPTO_SHA256 when the KDF is compiled. This would only be
necessary to satisfy the self test. Yet, there is no guarantee that SHA-256
would truly be needed because the DH code that calls the KDF obtains the
reference to the hash from user space. In the end we could hard compile a
crypto algorithm into the kernel that may never be used.
- we could relax the KDF self test a bit and could prevent the self test being
executed if we get an ENOENT back during the algorithm allocation. But that
would imply that the KDF self test would never be executed. Even when SHA-256
is compiled as module and insmod'ed at a later time the KDF self test is not
executed as it is only executed from the __init function.
I would prefer to consider the first option to also statically compile
SHA-256.
Ciao
Stephan
next prev parent reply other threads:[~2021-12-10 14:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 8:04 kernel test robot
2021-12-05 10:21 ` Stephan Müller
2021-12-10 2:54 ` Yujie Liu
2021-12-10 14:16 ` Stephan Mueller [this message]
2021-12-17 4:14 ` 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=3737408.Lz6Wf2Li4r@tauon.chronox.de \
--to=smueller@chronox.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=oliver.sang@intel.com \
--cc=yujie.liu@intel.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