From: Petr Vorel <pvorel@suse.cz>
To: Nicolai Stange <nstange@suse.de>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Masahiro Yamada <masahiroy@kernel.org>,
linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 1/1] crypto: vmx: Fix missing dependencies during boot
Date: Tue, 15 Feb 2022 11:40:23 +0100 [thread overview]
Message-ID: <YguDF5YbyKTGsc3/@pevik> (raw)
In-Reply-To: <87zgmsmu94.fsf@suse.de>
Hi Nicolai,
> Hi Petr,
> Petr Vorel <pvorel@suse.cz> writes:
> > if CRYPTO_DEV_VMX_ENCRYPT=y && !CRYPTO_MANAGER_DISABLE_TESTS
> > and either of CRYPTO_AES, CRYPTO_CBC, CRYPTO_CTR or CRYPTO_XTS is built
> > as module or disabled, alg_test() from crypto/testmgr.c complains during
> > boot about failing to allocate the generic fallback implementations
> > (2 == ENOENT):
> > [ 0.540953] Failed to allocate xts(aes) fallback: -2
> > [ 0.541014] alg: skcipher: failed to allocate transform for p8_aes_xts: -2
> > [ 0.541120] alg: self-tests for p8_aes_xts (xts(aes)) failed (rc=-2)
> > [ 0.544440] Failed to allocate ctr(aes) fallback: -2
> > [ 0.544497] alg: skcipher: failed to allocate transform for p8_aes_ctr: -2
> > [ 0.544603] alg: self-tests for p8_aes_ctr (ctr(aes)) failed (rc=-2)
> > [ 0.547992] Failed to allocate cbc(aes) fallback: -2
> > [ 0.548052] alg: skcipher: failed to allocate transform for p8_aes_cbc: -2
> > [ 0.548156] alg: self-tests for p8_aes_cbc (cbc(aes)) failed (rc=-2)
> > [ 0.550745] Failed to allocate transformation for 'aes': -2
> > [ 0.550801] alg: cipher: Failed to load transform for p8_aes: -2
> > [ 0.550892] alg: self-tests for p8_aes (aes) failed (rc=-2)
> > Check for these dependencies if crypto tests enabled.
> From my POV the problem of missing dependencies on fallback
> implementations is independent of the tests, the tests only happen to
> exhibit the issue.
I thought that after boot missing ciphers would be available from module and
loaded. But you're most likely right.
> > NOTE: this requires all these dependencies to be builtin if
> > !CRYPTO_MANAGER_DISABLE_TESTS, which is too strict on
> > CRYPTO_DEV_VMX_ENCRYPT=m.
> FWIW, I would not make the dependency conditional on
> !CRYPTO_MANAGER_DISABLE_TESTS.
You're right, I wasn't sure myself to use !CRYPTO_MANAGER_DISABLE_TESTS
as I also noticed that most of the dependencies in crypto/Kconfig and
drivers/crypto/Kconfig are described via "select".
...
> > what am I missing to allow e.g. CRYPTO_AES=m when
> > CRYPTO_DEV_VMX_ENCRYPT=m?
> If you were to leave the condition on
> !CRYPTO_MANAGER_DISABLE_TESTS away as suggested above, that is if you
> expressed the dependency like this ...
> config CRYPTO_DEV_VMX
> [...]
> depends on CRYPTO_AES
> ... then this would impose an upper limit (with the ordering n < m < y)
> of CRYPTO_AES on the possible values for CRYPTO_DEV_VMX. See
> Documentation/kconfig-language.rst.
> That is, if e.g. CRYPTO_AES=m, then only CRYPTO_DEV_VMX=n/m would be valid
> choices.
> I wouldn't go with "depends on", but prefer "select" in this case
> though. "select" is similar, but imposes a lower bound on the selected
> Kconfig symbol.
> That is,
> config CRYPTO_DEV_VMX
> [...]
> select CRYPTO_AES
Yep, I also tried select, but on CRYPTO_DEV_VMX_ENCRYPT, that's why it was not
working. Thanks for explanation and a hint => going to send v2.
Kind regards,
Petr
> would force the value of CRYPTO_AES to >= whatever the user picks for
> CRYPTO_DEV_VMX.
> (According to Documentation/kconfig-language.rst, you could even make
> this conditional on !CRYPTO_MANAGER_DISABLE_TESTS:
> select CRYPTO_AES if !CRYPTO_MANAGER_DISABLE_TESTS
> )
> Note that the 'select CRYPTO_AES' approach seems consistent to what is
> done for all the other crypto drivers depending on fallbacks, c.f. e.g
> drivers/crypto/Kconfig.
> Thanks,
> Nicolai
prev parent reply other threads:[~2022-02-15 10:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 18:56 [PATCH 1/1] crypto: vmx: Fix missing dependencies during boot Petr Vorel
2022-02-15 8:03 ` Nicolai Stange
2022-02-15 10:40 ` Petr Vorel [this message]
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=YguDF5YbyKTGsc3/@pevik \
--to=pvorel@suse.cz \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nstange@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).