linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] lib/crypto: add prompts back to crypto libraries
@ 2022-01-11 19:53 Justin M. Forbes
  2022-01-11 22:12 ` Jason A. Donenfeld
  0 siblings, 1 reply; 9+ messages in thread
From: Justin M. Forbes @ 2022-01-11 19:53 UTC (permalink / raw)
  To: Herbert Xu, David S. Miller, Ard Biesheuvel, Jason A. Donenfeld,
	Greg Kroah-Hartman, linux-crypto, linux-kernel
  Cc: jmforbes, Justin M. Forbes

Commit 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") took
away a number of prompt texts from other crypto libraries. This makes
values flip from built-in to module when oldconfig runs, and causes
problems when these crypto libs need to be built in for thingslike
BIG_KEYS.

Fixes: 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in")
Signed-off-by: Justin M. Forbes <jforbes@fedoraproject.org>
---
 lib/crypto/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index 8620f38e117c..a3e41b7a8054 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -40,7 +40,7 @@ config CRYPTO_LIB_CHACHA_GENERIC
 	  of CRYPTO_LIB_CHACHA.

 config CRYPTO_LIB_CHACHA
-	tristate
+	tristate "ChaCha library interface"
 	depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA
 	select CRYPTO_LIB_CHACHA_GENERIC if CRYPTO_ARCH_HAVE_LIB_CHACHA=n
 	help
@@ -65,7 +65,7 @@ config CRYPTO_LIB_CURVE25519_GENERIC
 	  of CRYPTO_LIB_CURVE25519.

 config CRYPTO_LIB_CURVE25519
-	tristate
+	tristate "Curve25519 scalar multiplication library"
 	depends on CRYPTO_ARCH_HAVE_LIB_CURVE25519 || !CRYPTO_ARCH_HAVE_LIB_CURVE25519
 	select CRYPTO_LIB_CURVE25519_GENERIC if CRYPTO_ARCH_HAVE_LIB_CURVE25519=n
 	help
@@ -100,7 +100,7 @@ config CRYPTO_LIB_POLY1305_GENERIC
 	  of CRYPTO_LIB_POLY1305.

 config CRYPTO_LIB_POLY1305
-	tristate
+	tristate "Poly1305 library interface"
 	depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305
 	select CRYPTO_LIB_POLY1305_GENERIC if CRYPTO_ARCH_HAVE_LIB_POLY1305=n
 	help
@@ -109,7 +109,7 @@ config CRYPTO_LIB_POLY1305
 	  is available and enabled.

 config CRYPTO_LIB_CHACHA20POLY1305
-	tristate
+	tristate "ChaCha20-Poly1305 AEAD support (8-byte nonce library version)"
 	depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA
 	depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305
 	select CRYPTO_LIB_CHACHA
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-11 19:53 [PATCH] lib/crypto: add prompts back to crypto libraries Justin M. Forbes
@ 2022-01-11 22:12 ` Jason A. Donenfeld
  2022-01-11 22:22   ` Justin Forbes
  2022-01-11 22:24   ` Ard Biesheuvel
  0 siblings, 2 replies; 9+ messages in thread
From: Jason A. Donenfeld @ 2022-01-11 22:12 UTC (permalink / raw)
  To: Justin M. Forbes
  Cc: Herbert Xu, David S. Miller, Ard Biesheuvel, Greg Kroah-Hartman,
	Linux Crypto Mailing List, LKML, jmforbes, David Howells

Hi Justin,

These are library variables, which means they really have no sense in
being user selectable. Internal things to the kernel depend on them,
or they don't. They're always only dependencies.

It sounds like CONFIG_BIG_KEYS might be declaring its dependencies
wrong, and that's actually where the bug is? CC'ing David Howells just
in case. Maybe things should be changed to:

diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index 64b81abd087e..2f1624c9eed9 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -60,7 +60,7 @@ config BIG_KEYS
  bool "Large payload keys"
  depends on KEYS
  depends on TMPFS
- depends on CRYPTO_LIB_CHACHA20POLY1305 = y
+ select CRYPTO_LIB_CHACHA20POLY1305
  help
    This option provides support for holding large keys within the kernel
    (for example Kerberos ticket caches).  The data may be stored out to


Jason

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-11 22:12 ` Jason A. Donenfeld
@ 2022-01-11 22:22   ` Justin Forbes
  2022-01-11 22:24   ` Ard Biesheuvel
  1 sibling, 0 replies; 9+ messages in thread
From: Justin Forbes @ 2022-01-11 22:22 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Herbert Xu, David S. Miller, Ard Biesheuvel, Greg Kroah-Hartman,
	Linux Crypto Mailing List, LKML, David Howells

On Tue, Jan 11, 2022 at 4:12 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Justin,
>
> These are library variables, which means they really have no sense in
> being user selectable. Internal things to the kernel depend on them,
> or they don't. They're always only dependencies.

While this is correct in principle, it has not been that way in the
past.  The change had nothing to do with the patch it came in on, and
breaks existing configs used by some distros.  BIG_KEYS happened to be
our motivation for flipping those from module to built in, but I have
no way of knowing what else might be in a similar situation.  Worse,
many users will never know it is happening.  We simply have some
scripts that warn loudly if a config value is flipped from what it was
set to in our prebuild files.

> It sounds like CONFIG_BIG_KEYS might be declaring its dependencies
> wrong, and that's actually where the bug is? CC'ing David Howells just
> in case. Maybe things should be changed to:
>
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index 64b81abd087e..2f1624c9eed9 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -60,7 +60,7 @@ config BIG_KEYS
>   bool "Large payload keys"
>   depends on KEYS
>   depends on TMPFS
> - depends on CRYPTO_LIB_CHACHA20POLY1305 = y
> + select CRYPTO_LIB_CHACHA20POLY1305
>   help
>     This option provides support for holding large keys within the kernel
>     (for example Kerberos ticket caches).  The data may be stored out to

This looks correct, and would likely alleviate our initial problem,
but it doesn't mean nothing else is impacted. I would still be in
favor of my patch going in to revert the dropped prompts for 5.17, and
then we can audit everything else that has any type of dep on the
crypto libs in question and provide a patch to fix everything up
correctly.  I am happy to do that audit, but probably wouldn't get the
time to do so until rc2 or later.  I do not see how the dropped
prompts for these libs have anything to do with the "blake2s: include
as built-in" that brought them in.

Justin

>
> Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-11 22:12 ` Jason A. Donenfeld
  2022-01-11 22:22   ` Justin Forbes
@ 2022-01-11 22:24   ` Ard Biesheuvel
  2022-01-11 22:27     ` Jason A. Donenfeld
  1 sibling, 1 reply; 9+ messages in thread
From: Ard Biesheuvel @ 2022-01-11 22:24 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Justin M. Forbes, Herbert Xu, David S. Miller,
	Greg Kroah-Hartman, Linux Crypto Mailing List, LKML, jmforbes,
	David Howells

On Tue, 11 Jan 2022 at 23:12, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Justin,
>
> These are library variables, which means they really have no sense in
> being user selectable. Internal things to the kernel depend on them,
> or they don't. They're always only dependencies.
>

But what does any of this have to do with blake2s? These are unrelated
changes that are not even described in the commit log of the original
patch, so let's just revert them now. If changes are needed here, we
can discuss them on the linux-crypto mailing list after the merge
window.


> It sounds like CONFIG_BIG_KEYS might be declaring its dependencies
> wrong, and that's actually where the bug is? CC'ing David Howells just
> in case. Maybe things should be changed to:
>
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index 64b81abd087e..2f1624c9eed9 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -60,7 +60,7 @@ config BIG_KEYS
>   bool "Large payload keys"
>   depends on KEYS
>   depends on TMPFS
> - depends on CRYPTO_LIB_CHACHA20POLY1305 = y
> + select CRYPTO_LIB_CHACHA20POLY1305
>   help
>     This option provides support for holding large keys within the kernel
>     (for example Kerberos ticket caches).  The data may be stored out to
>
>
> Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-11 22:24   ` Ard Biesheuvel
@ 2022-01-11 22:27     ` Jason A. Donenfeld
  2022-01-11 22:41       ` Ard Biesheuvel
  0 siblings, 1 reply; 9+ messages in thread
From: Jason A. Donenfeld @ 2022-01-11 22:27 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Justin M. Forbes, Herbert Xu, David S. Miller,
	Greg Kroah-Hartman, Linux Crypto Mailing List, LKML, jmforbes,
	David Howells

On Tue, Jan 11, 2022 at 11:25 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 11 Jan 2022 at 23:12, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hi Justin,
> >
> > These are library variables, which means they really have no sense in
> > being user selectable. Internal things to the kernel depend on them,
> > or they don't. They're always only dependencies.
> >
>
> But what does any of this have to do with blake2s? These are unrelated
> changes that are not even described in the commit log of the original
> patch, so let's just revert them now. If changes are needed here, we
> can discuss them on the linux-crypto mailing list after the merge
> window.

The lib crypto stuff moved outside of `if CRYPTO`, so if you add those
titles back, the root menu is going to be filled with things. I'm
working on some patches now moving lib/crypto/ things into lib
strictly, so the dependency is one way. I can try adding back the
labels there if you want.

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-11 22:27     ` Jason A. Donenfeld
@ 2022-01-11 22:41       ` Ard Biesheuvel
  2022-01-12 13:58         ` Justin Forbes
  0 siblings, 1 reply; 9+ messages in thread
From: Ard Biesheuvel @ 2022-01-11 22:41 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Justin M. Forbes, Herbert Xu, David S. Miller,
	Greg Kroah-Hartman, Linux Crypto Mailing List, LKML, jmforbes,
	David Howells

On Tue, 11 Jan 2022 at 23:27, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Tue, Jan 11, 2022 at 11:25 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Tue, 11 Jan 2022 at 23:12, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > >
> > > Hi Justin,
> > >
> > > These are library variables, which means they really have no sense in
> > > being user selectable. Internal things to the kernel depend on them,
> > > or they don't. They're always only dependencies.
> > >
> >
> > But what does any of this have to do with blake2s? These are unrelated
> > changes that are not even described in the commit log of the original
> > patch, so let's just revert them now. If changes are needed here, we
> > can discuss them on the linux-crypto mailing list after the merge
> > window.
>
> The lib crypto stuff moved outside of `if CRYPTO`, so if you add those
> titles back, the root menu is going to be filled with things. I'm
> working on some patches now moving lib/crypto/ things into lib
> strictly, so the dependency is one way. I can try adding back the
> labels there if you want.
>

Ah, right. In that case, can we fold in something like the below?

diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index a3e41b7a8054..179041b60294 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0

+menu "Crypto library routines"
+
 config CRYPTO_LIB_AES
        tristate

@@ -120,3 +122,5 @@ config CRYPTO_LIB_SHA256

 config CRYPTO_LIB_SM4
        tristate
+
+endmenu

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-11 22:41       ` Ard Biesheuvel
@ 2022-01-12 13:58         ` Justin Forbes
  2022-01-12 13:59           ` Jason A. Donenfeld
  0 siblings, 1 reply; 9+ messages in thread
From: Justin Forbes @ 2022-01-12 13:58 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Jason A. Donenfeld, Herbert Xu, David S. Miller,
	Greg Kroah-Hartman, Linux Crypto Mailing List, LKML,
	David Howells

On Tue, Jan 11, 2022 at 4:41 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 11 Jan 2022 at 23:27, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > On Tue, Jan 11, 2022 at 11:25 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Tue, 11 Jan 2022 at 23:12, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > > >
> > > > Hi Justin,
> > > >
> > > > These are library variables, which means they really have no sense in
> > > > being user selectable. Internal things to the kernel depend on them,
> > > > or they don't. They're always only dependencies.
> > > >
> > >
> > > But what does any of this have to do with blake2s? These are unrelated
> > > changes that are not even described in the commit log of the original
> > > patch, so let's just revert them now. If changes are needed here, we
> > > can discuss them on the linux-crypto mailing list after the merge
> > > window.
> >
> > The lib crypto stuff moved outside of `if CRYPTO`, so if you add those
> > titles back, the root menu is going to be filled with things. I'm
> > working on some patches now moving lib/crypto/ things into lib
> > strictly, so the dependency is one way. I can try adding back the
> > labels there if you want.
> >
>
> Ah, right. In that case, can we fold in something like the below?
>
> diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
> index a3e41b7a8054..179041b60294 100644
> --- a/lib/crypto/Kconfig
> +++ b/lib/crypto/Kconfig
> @@ -1,5 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> +menu "Crypto library routines"
> +
>  config CRYPTO_LIB_AES
>         tristate
>
> @@ -120,3 +122,5 @@ config CRYPTO_LIB_SHA256
>
>  config CRYPTO_LIB_SM4
>         tristate
> +
> +endmenu

That works, I will send a V2 with the menu.

Justin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-12 13:58         ` Justin Forbes
@ 2022-01-12 13:59           ` Jason A. Donenfeld
  2022-01-12 14:05             ` Jason A. Donenfeld
  0 siblings, 1 reply; 9+ messages in thread
From: Jason A. Donenfeld @ 2022-01-12 13:59 UTC (permalink / raw)
  To: Justin Forbes
  Cc: Ard Biesheuvel, Herbert Xu, David S. Miller, Greg Kroah-Hartman,
	Linux Crypto Mailing List, LKML, David Howells

I think I've actually got a patch for the root problem here. Testing
now and it should be out shortly.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] lib/crypto: add prompts back to crypto libraries
  2022-01-12 13:59           ` Jason A. Donenfeld
@ 2022-01-12 14:05             ` Jason A. Donenfeld
  0 siblings, 0 replies; 9+ messages in thread
From: Jason A. Donenfeld @ 2022-01-12 14:05 UTC (permalink / raw)
  To: Justin Forbes
  Cc: Ard Biesheuvel, Herbert Xu, David S. Miller, Greg Kroah-Hartman,
	Linux Crypto Mailing List, LKML, David Howells

On Wed, Jan 12, 2022 at 2:59 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> I think I've actually got a patch for the root problem here. Testing
> now and it should be out shortly.

Actually, scratch that, it's a lot harder than I anticipated. I just
saw your v2. Let's roll with that. Sent you a note there for a v3.

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-01-12 14:05 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-11 19:53 [PATCH] lib/crypto: add prompts back to crypto libraries Justin M. Forbes
2022-01-11 22:12 ` Jason A. Donenfeld
2022-01-11 22:22   ` Justin Forbes
2022-01-11 22:24   ` Ard Biesheuvel
2022-01-11 22:27     ` Jason A. Donenfeld
2022-01-11 22:41       ` Ard Biesheuvel
2022-01-12 13:58         ` Justin Forbes
2022-01-12 13:59           ` Jason A. Donenfeld
2022-01-12 14:05             ` Jason A. Donenfeld

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