linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).