linux-next: build failure after merge of the keys tree

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_read':
big_key.c:(.text+0x562): undefined reference to `chacha20poly1305_decrypt'
x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_preparse':
big_key.c:(.text+0x825): undefined reference to `chacha20poly1305_encrypt'

Caused by commit

  e0a715753a88 ("security/keys: rewrite big_key crypto to use library interface")

I have used the version from next-20200512 again tdoay.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

How should we handle a bool depending on a tristate?

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_read':
> big_key.c:(.text+0x562): undefined reference to `chacha20poly1305_decrypt'
> x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_preparse':
> big_key.c:(.text+0x825): undefined reference to `chacha20poly1305_encrypt'
> 
> Caused by commit
> 
>   e0a715753a88 ("security/keys: rewrite big_key crypto to use library interface")
> 
> I have used the version from next-20200512 again tdoay.

Blech.  Yeah.  "depends on" doesn't work either.  The problem actually lies
within the Kconfig framework.  It doesn't know how to handle a bool depending
on a tristate.

So the issue is that with Jason's patch, we now have:

	config BIG_KEYS
		bool "Large payload keys"
		depends on KEYS
		depends on TMPFS
		depends on CRYPTO_LIB_CHACHA20POLY1305

	...

	config CRYPTO_LIB_CHACHA20POLY1305
		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
		select CRYPTO_LIB_POLY1305

But you're allowed to set CONFIG_CRYPTO_LIB_CHACHA20POLY1305=m.

Using "select" instead can lead to warnings about circular dependencies and,
in any case, doesn't propagate the selection up the tree.

Also, in this case, having BIG_KEYS select everything isn't practical as
CRYPTO_LIB_CHACHA20POLY1305 has a logical-XOR in its depends on.

I think one or more of the following things need to happen:

 (1) The configurator needs to give an error if it detects this.

 (2) The configurator needs to propagate select rootwards.

 (3) The configurator needs to propagate "=y" rootwards over depends on,
     prohibiting "=m".

 (4) The BIG_KEYS config needs to switch to a tristate.[*]

Do we have a preference?

David

[*] Note there have been situations where switching to a tristate isn't
    technically an option because the dependency target was required during
    boot (crypto used by module checking, for example), but we've just had to
    work around it and hope whoever was configuring the kernel built
    everything in.

Re: How should we handle a bool depending on a tristate?

[Linus Torvalds]

On Mon, May 18, 2020 at 9:01 AM David Howells <dhowells@redhat.com> wrote:
>
>
> Blech.  Yeah.  "depends on" doesn't work either.  The problem actually lies
> within the Kconfig framework.  It doesn't know how to handle a bool depending
> on a tristate.

No problem with Kconfig. It knows exactly how to let a bool depend on
a tristate.

It's just that there are two different kinds of dependencies.

For example, the dependency can be a hard and absolute dependency
(linking doesn't work, or whatever), and then obviously built-in code
cannot be enabled if the thing it depends on is a loadable module.

But the dependency can also be a conceptual one: "This option doesn't
make sense unless that option is set". Then a bool can make sense even
if the other config is a modular one.

And Kconfig can deal with either situation just fine.

Do

    depends on XYZ = y

or

    depends on XYZ != n

to clarify the choice. One requires a hard dependency, the other
requires that the  option just be enabled.

Now, if you just do "depends on XYZ", it allows a bool to be enabled
even for just a module (ie that second case). That makes sense for a
lot of "allow this feature in the module" kind of options, where it
would be pointless to even ask about a boolean feature if the parent
module isn't even enabled.

But that "depends on XYZ=y" is not uncommon. It basically says "this
option makes sense only when built in". Either because it requires it
for linking, or just because it doesn't work or make sense without it.

                     Linus

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/cred.h:13,
                 from security/integrity/ima/ima_mok.c:12:
security/integrity/ima/ima_mok.c: In function 'ima_mok_init':
include/linux/key.h:292:29: warning: passing argument 7 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
  292 | #define KEY_ALLOC_SET_KEEP  0x0020 /* Set the KEEP flag on the key/keyring */
      |                             ^~~~~~
      |                             |
      |                             int
security/integrity/ima/ima_mok.c:42:5: note: in expansion of macro 'KEY_ALLOC_SET_KEEP'
   42 |     KEY_ALLOC_SET_KEEP,
      |     ^~~~~~~~~~~~~~~~~~
include/linux/key.h:410:30: note: expected 'struct key_restriction *' but argument is of type 'int'
  410 |      struct key_restriction *restrict_link,
      |      ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
security/integrity/ima/ima_mok.c:43:5: error: passing argument 8 of 'keyring_alloc' from incompatible pointer type [-Werror=incompatible-pointer-types]
   43 |     restriction, NULL);
      |     ^~~~~~~~~~~
      |     |
      |     struct key_restriction *
In file included from include/linux/cred.h:13,
                 from security/integrity/ima/ima_mok.c:12:
include/linux/key.h:411:18: note: expected 'struct key *' but argument is of type 'struct key_restriction *'
  411 |      struct key *dest);
      |      ~~~~~~~~~~~~^~~~
security/integrity/ima/ima_mok.c:36:26: error: too many arguments to function 'keyring_alloc'
   36 |  ima_blacklist_keyring = keyring_alloc(".ima_blacklist",
      |                          ^~~~~~~~~~~~~
In file included from include/linux/cred.h:13,
                 from security/integrity/ima/ima_mok.c:12:
include/linux/key.h:406:20: note: declared here
  406 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
      |                    ^~~~~~~~~~~~~

Caused by commit

  33c36b2053de ("certs: Fix blacklist flag type confusion")

I have applied the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 11 Dec 2020 15:46:09 +1100
Subject: [PATCH] fixup for "certs: Fix blacklist flag type confusion"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 security/integrity/ima/ima_mok.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
index ce8871d96f12..5594dd38ab04 100644
--- a/security/integrity/ima/ima_mok.c
+++ b/security/integrity/ima/ima_mok.c
@@ -38,8 +38,7 @@ __init int ima_mok_init(void)
 				(KEY_POS_ALL & ~KEY_POS_SETATTR) |
 				KEY_USR_VIEW | KEY_USR_READ |
 				KEY_USR_WRITE | KEY_USR_SEARCH,
-				KEY_ALLOC_NOT_IN_QUOTA,
-				KEY_ALLOC_SET_KEEP,
+				KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP,
 				restriction, NULL);
 
 	if (IS_ERR(ima_blacklist_keyring))
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Jason A. Donenfeld]

On Thu, May 14, 2020 at 6:35 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Thu, May 14, 2020 at 9:11 PM David Howells <dhowells@redhat.com> wrote:
> >
> > Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > > Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> > > tristate and depends on as well as selects other things that are
> > > tristates.
> > >
> > > Meanwhile BIG_KEYS is a bool, which needs to select
> > > CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
> > > its selecting has =m items in its hierarchy.
> > >
> > > Any suggestions? The ideal thing to happen would be that the select of
> > > CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
> > > to become =y too.
> >
> > I think that select is broken in its behaviour - it doesn't propagate the
> > selection enforcement up the tree.  You could try changing it to a depends on
> > or you could put in a select for every dependency.
>
> I agree.
> 'depends on' will be cleaner.

That's fine, but also makes it more annoying for people to select
big_keys, and I don't know how David feels in that regard.

Seems like it'd be useful to have something that means "select X and
all the things X needs to not be broken", though satisfiability
problems like that can get really complicated quite fast.

Re: linux-next: build failure after merge of the keys tree

[Masahiro Yamada]

On Thu, May 14, 2020 at 9:11 PM David Howells <dhowells@redhat.com> wrote:
>
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> > tristate and depends on as well as selects other things that are
> > tristates.
> >
> > Meanwhile BIG_KEYS is a bool, which needs to select
> > CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
> > its selecting has =m items in its hierarchy.
> >
> > Any suggestions? The ideal thing to happen would be that the select of
> > CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
> > to become =y too.
>
> I think that select is broken in its behaviour - it doesn't propagate the
> selection enforcement up the tree.  You could try changing it to a depends on
> or you could put in a select for every dependency.

I agree.
'depends on' will be cleaner.

> I'm not sure there are any
> other options - unless we turn big_key into a module and institute autoloading
> of keytypes on demand.
>
> David
>


-- 
Best Regards
Masahiro Yamada

Re: linux-next: build failure after merge of the keys tree

[David Howells]

Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> tristate and depends on as well as selects other things that are
> tristates.
> 
> Meanwhile BIG_KEYS is a bool, which needs to select
> CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
> its selecting has =m items in its hierarchy.
> 
> Any suggestions? The ideal thing to happen would be that the select of
> CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
> to become =y too.

I think that select is broken in its behaviour - it doesn't propagate the
selection enforcement up the tree.  You could try changing it to a depends on
or you could put in a select for every dependency.  I'm not sure there are any
other options - unless we turn big_key into a module and institute autoloading
of keytypes on demand.

David

Re: linux-next: build failure after merge of the keys tree

[Jason A. Donenfeld]

Hey Masahiro,

Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
tristate and depends on as well as selects other things that are
tristates.

Meanwhile BIG_KEYS is a bool, which needs to select
CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
its selecting has =m items in its hierarchy.

Any suggestions? The ideal thing to happen would be that the select of
CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
to become =y too.

Jason


On Wed, May 13, 2020 at 10:31 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
>   Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
>   Selected by [y]:
>   - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
>   Selected by [m]:
>   - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
>   Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
>   Selected by [y]:
>   - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
>   Selected by [m]:
>   - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
>   Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
>   Selected by [y]:
>   - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
>   Selected by [m]:
>   - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `xchacha_init':
> chacha20poly1305.c:(.text+0x12d): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x13d): undefined reference to `hchacha_block_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14b): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_encrypt':
> chacha20poly1305.c:(.text+0x2ab): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2bd): undefined reference to `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2d6): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x317): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x32d): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x379): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x385): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x413): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x434): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_encrypt':
> (.text+0x59d): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_decrypt':
> chacha20poly1305.c:(.text+0x847): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x859): undefined reference to `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x86d): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8a7): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8f1): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8fc): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x94f): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9d9): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9f9): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_decrypt':
> (.text+0xb78): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_crypt_sg_inplace':
> chacha20poly1305.c:(.text+0xf16): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf3b): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf50): undefined reference to `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1094): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1155): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x117b): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x11da): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1223): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1321): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1401): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14a3): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14d6): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1507): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1573): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x15aa): undefined reference to `poly1305_final_arch'
>
> Caused by commit
>
>   f22998a0de8a ("security/keys: rewrite big_key crypto to use library interface")
>
> I have used the keys tree from next-20200512 for today.
>
> --
> Cheers,
> Stephen Rothwell

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5914 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
  Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
  Selected by [y]:
  - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
  Selected by [m]:
  - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])

WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
  Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
  Selected by [y]:
  - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
  Selected by [m]:
  - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])

WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
  Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
  Selected by [y]:
  - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
  Selected by [m]:
  - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `xchacha_init':
chacha20poly1305.c:(.text+0x12d): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x13d): undefined reference to `hchacha_block_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14b): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_encrypt':
chacha20poly1305.c:(.text+0x2ab): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2bd): undefined reference to `poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2d6): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x317): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x32d): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x379): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x385): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x413): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x434): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_encrypt':
(.text+0x59d): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_decrypt':
chacha20poly1305.c:(.text+0x847): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x859): undefined reference to `poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x86d): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8a7): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8f1): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8fc): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x94f): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9d9): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9f9): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_decrypt':
(.text+0xb78): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_crypt_sg_inplace':
chacha20poly1305.c:(.text+0xf16): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf3b): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf50): undefined reference to `poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1094): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1155): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x117b): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x11da): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1223): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1321): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1401): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14a3): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14d6): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1507): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1573): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x15aa): undefined reference to `poly1305_final_arch'

Caused by commit

  f22998a0de8a ("security/keys: rewrite big_key crypto to use library interface")

I have used the keys tree from next-20200512 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

Hi all,

On Mon, 4 May 2020 13:25:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Due to further changes in Linus' tree over the weekend, this fixup is
> not linger needed.

"no longer" (Monday's ...)

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

Hi all,

On Mon, 2 Mar 2020 11:37:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the keys tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> fs/io_uring.c: In function 'io_splice_punt':
> fs/io_uring.c:2473:6: error: too few arguments to function 'get_pipe_info'
>  2473 |  if (get_pipe_info(file))
>       |      ^~~~~~~~~~~~~
> In file included from include/linux/splice.h:12,
>                  from include/linux/skbuff.h:36,
>                  from include/linux/if_ether.h:19,
>                  from include/uapi/linux/ethtool.h:19,
>                  from include/linux/ethtool.h:18,
>                  from include/linux/netdevice.h:37,
>                  from include/net/sock.h:46,
>                  from fs/io_uring.c:64:
> include/linux/pipe_fs_i.h:267:25: note: declared here
>   267 | struct pipe_inode_info *get_pipe_info(struct file *file, bool for_splice);
>       |                         ^~~~~~~~~~~~~
> 
> Caused by commit
> 
>   549d46d3827d ("pipe: Add general notification queue support")
> 
> interacting with commit
> 
>   52b31bc9aabc ("io_uring: add splice(2) support")
> 
> from the block tree.
> 
> I have added the following merge fix patch.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 Mar 2020 11:27:27 +1100
> Subject: [PATCH] io_uring: fix up for get_pipe_info() API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/io_uring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index fb8fe0bd5e18..8cdd3870cd4e 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -2470,7 +2470,7 @@ static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>  
>  static bool io_splice_punt(struct file *file)
>  {
> -	if (get_pipe_info(file))
> +	if (get_pipe_info(file, true))
>  		return false;
>  	if (!io_file_supports_async(file))
>  		return true;

Due to further changes in Linus' tree over the weekend, this fixup is
not linger needed.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Pavel Begunkov]

On 3/2/2020 3:37 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the keys tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:

Acked-by: Pavel Begunkov <asml.silence@gmail.com>
Thanks

> fs/io_uring.c: In function 'io_splice_punt':
> fs/io_uring.c:2473:6: error: too few arguments to function 'get_pipe_info'
>  2473 |  if (get_pipe_info(file))
>       |      ^~~~~~~~~~~~~
> In file included from include/linux/splice.h:12,
>                  from include/linux/skbuff.h:36,
>                  from include/linux/if_ether.h:19,
>                  from include/uapi/linux/ethtool.h:19,
>                  from include/linux/ethtool.h:18,
>                  from include/linux/netdevice.h:37,
>                  from include/net/sock.h:46,
>                  from fs/io_uring.c:64:
> include/linux/pipe_fs_i.h:267:25: note: declared here
>   267 | struct pipe_inode_info *get_pipe_info(struct file *file, bool for_splice);
>       |                         ^~~~~~~~~~~~~
> 
> Caused by commit
> 
>   549d46d3827d ("pipe: Add general notification queue support")
> 
> interacting with commit
> 
>   52b31bc9aabc ("io_uring: add splice(2) support")
> 
> from the block tree.
> 
> I have added the following merge fix patch.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 Mar 2020 11:27:27 +1100
> Subject: [PATCH] io_uring: fix up for get_pipe_info() API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/io_uring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index fb8fe0bd5e18..8cdd3870cd4e 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -2470,7 +2470,7 @@ static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>  
>  static bool io_splice_punt(struct file *file)
>  {
> -	if (get_pipe_info(file))
> +	if (get_pipe_info(file, true))
>  		return false;
>  	if (!io_file_supports_async(file))
>  		return true;
> 

-- 
Pavel Begunkov

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/io_uring.c: In function 'io_splice_punt':
fs/io_uring.c:2473:6: error: too few arguments to function 'get_pipe_info'
 2473 |  if (get_pipe_info(file))
      |      ^~~~~~~~~~~~~
In file included from include/linux/splice.h:12,
                 from include/linux/skbuff.h:36,
                 from include/linux/if_ether.h:19,
                 from include/uapi/linux/ethtool.h:19,
                 from include/linux/ethtool.h:18,
                 from include/linux/netdevice.h:37,
                 from include/net/sock.h:46,
                 from fs/io_uring.c:64:
include/linux/pipe_fs_i.h:267:25: note: declared here
  267 | struct pipe_inode_info *get_pipe_info(struct file *file, bool for_splice);
      |                         ^~~~~~~~~~~~~

Caused by commit

  549d46d3827d ("pipe: Add general notification queue support")

interacting with commit

  52b31bc9aabc ("io_uring: add splice(2) support")

from the block tree.

I have added the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Mar 2020 11:27:27 +1100
Subject: [PATCH] io_uring: fix up for get_pipe_info() API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/io_uring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index fb8fe0bd5e18..8cdd3870cd4e 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2470,7 +2470,7 @@ static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 static bool io_splice_punt(struct file *file)
 {
-	if (get_pipe_info(file))
+	if (get_pipe_info(file, true))
 		return false;
 	if (!io_file_supports_async(file))
 		return true;
-- 
2.25.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

Hi all,

On Mon, 10 Feb 2020 10:07:43 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 10 Feb 2020 10:05:55 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the keys tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:  
> 
> kernel/watch_queue.c: In function 'post_one_notification':
> kernel/watch_queue.c:89:21: error: 'struct pipe_inode_info' has no member named 'wait'
>    89 |  spin_lock_irq(&pipe->wait.lock);
>       |                     ^~
> kernel/watch_queue.c:122:24: error: 'struct pipe_inode_info' has no member named 'wait'
>   122 |   spin_unlock_irq(&pipe->wait.lock);
>       |                        ^~
> In file included from include/linux/mmzone.h:10,
>                  from include/linux/gfp.h:6,
>                  from include/linux/umh.h:4,
>                  from include/linux/kmod.h:9,
>                  from include/linux/module.h:16,
>                  from kernel/watch_queue.c:11:
> kernel/watch_queue.c:125:46: error: 'struct pipe_inode_info' has no member named 'wait'
>   125 |  wake_up_interruptible_sync_poll_locked(&pipe->wait, EPOLLIN | EPOLLRDNORM);
>       |                                              ^~
> include/linux/wait.h:234:29: note: in definition of macro 'wake_up_interruptible_sync_poll_locked'
>   234 |  __wake_up_locked_sync_key((x), TASK_INTERRUPTIBLE, poll_to_key(m))
>       |                             ^
> kernel/watch_queue.c:129:23: error: 'struct pipe_inode_info' has no member named 'wait'
>   129 |  spin_unlock_irq(&pipe->wait.lock);
>       |                       ^~
> 
> > Caused by commit(s) in the keys tree interacting with commit
> > 
> >   0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
> > 
> > from Linus' tree.
> > 
> > Given that I haven't seen a pull request for the keys tree yet, it seems
> > that this work will not be in v5.6, so I have just dropped the keys tree
> > for today.  

From today, I have just disabled CONFIG_WATCH_QUEUE instead of dropping
the keys tree completely.  Please let me know when it has been fixed up
in case I don't notice.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

Hi all,

On Mon, 10 Feb 2020 10:05:55 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

kernel/watch_queue.c: In function 'post_one_notification':
kernel/watch_queue.c:89:21: error: 'struct pipe_inode_info' has no member named 'wait'
   89 |  spin_lock_irq(&pipe->wait.lock);
      |                     ^~
kernel/watch_queue.c:122:24: error: 'struct pipe_inode_info' has no member named 'wait'
  122 |   spin_unlock_irq(&pipe->wait.lock);
      |                        ^~
In file included from include/linux/mmzone.h:10,
                 from include/linux/gfp.h:6,
                 from include/linux/umh.h:4,
                 from include/linux/kmod.h:9,
                 from include/linux/module.h:16,
                 from kernel/watch_queue.c:11:
kernel/watch_queue.c:125:46: error: 'struct pipe_inode_info' has no member named 'wait'
  125 |  wake_up_interruptible_sync_poll_locked(&pipe->wait, EPOLLIN | EPOLLRDNORM);
      |                                              ^~
include/linux/wait.h:234:29: note: in definition of macro 'wake_up_interruptible_sync_poll_locked'
  234 |  __wake_up_locked_sync_key((x), TASK_INTERRUPTIBLE, poll_to_key(m))
      |                             ^
kernel/watch_queue.c:129:23: error: 'struct pipe_inode_info' has no member named 'wait'
  129 |  spin_unlock_irq(&pipe->wait.lock);
      |                       ^~

> Caused by commit(s) in the keys tree interacting with commit
> 
>   0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
> 
> from Linus' tree.
> 
> Given that I haven't seen a pull request for the keys tree yet, it seems
> that this work will not be in v5.6, so I have just dropped the keys tree
> for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:


Caused by commits in the keys tree interacting with commit

  0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")

from Linus' tree.

Given that I haven't seen a pull request for the keys tree yet, it seems
that this work will not be in v5.6, so I have just dropped the keys tree
for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 6985 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/keyctl.h:11,
                 from include/linux/key.h:35,
                 from include/linux/cred.h:13,
                 from fs/verity/signature.c:10:
fs/verity/signature.c: In function 'fsverity_init_signature':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 5 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
   52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
      |                        ^
      |                        |
      |                        int
fs/verity/signature.c:140:25: note: in expansion of macro 'KEY_POS_SEARCH'
  140 |         current_cred(), KEY_POS_SEARCH |
      |                         ^~~~~~~~~~~~~~
In file included from include/linux/cred.h:13,
                 from fs/verity/signature.c:10:
include/linux/key.h:390:20: note: expected 'struct key_acl *' but argument is of type 'int'
  390 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
      |                    ^~~~~~~~~~~~~
fs/crypto/keysetup_v1.c: In function 'find_and_lock_process_key':
fs/crypto/keysetup_v1.c:107:8: error: too few arguments to function 'request_key'
  107 |  key = request_key(&key_type_logon, description, NULL);
      |        ^~~~~~~~~~~
In file included from include/keys/user-type.h:11,
                 from fs/crypto/keysetup_v1.c:25:
include/linux/key.h:321:27: note: declared here
  321 | static inline struct key *request_key(struct key_type *type,
      |                           ^~~~~~~~~~~
In file included from include/linux/keyctl.h:11,
                 from include/linux/key.h:35,
                 from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'allocate_filesystem_keyring':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 5 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
   52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
      |                        ^
      |                        |
      |                        int
fs/crypto/keyring.c:208:21: note: in expansion of macro 'KEY_POS_SEARCH'
  208 |     current_cred(), KEY_POS_SEARCH |
      |                     ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
include/linux/key.h:390:20: note: expected 'struct key_acl *' but argument is of type 'int'
  390 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
      |                    ^~~~~~~~~~~~~
In file included from include/linux/keyctl.h:11,
                 from include/linux/key.h:35,
                 from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'allocate_master_key_users_keyring':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 5 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
   52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
      |                        ^
      |                        |
      |                        int
fs/crypto/keyring.c:252:21: note: in expansion of macro 'KEY_POS_SEARCH'
  252 |     current_cred(), KEY_POS_SEARCH |
      |                     ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
include/linux/key.h:390:20: note: expected 'struct key_acl *' but argument is of type 'int'
  390 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
      |                    ^~~~~~~~~~~~~
In file included from include/linux/keyctl.h:11,
                 from include/linux/key.h:35,
                 from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'add_master_key_user':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 6 of 'key_alloc' makes pointer from integer without a cast [-Wint-conversion]
   52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
      |                        ^
      |                        |
      |                        int
fs/crypto/keyring.c:290:8: note: in expansion of macro 'KEY_POS_SEARCH'
  290 |        KEY_POS_SEARCH | KEY_USR_VIEW, 0, NULL);
      |        ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
include/linux/key.h:256:20: note: expected 'struct key_acl *' but argument is of type 'int'
  256 | extern struct key *key_alloc(struct key_type *type,
      |                    ^~~~~~~~~
In file included from include/linux/keyctl.h:11,
                 from include/linux/key.h:35,
                 from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'add_new_master_key':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 6 of 'key_alloc' makes pointer from integer without a cast [-Wint-conversion]
   52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
      |                        ^
      |                        |
      |                        int
fs/crypto/keyring.c:362:4: note: in expansion of macro 'KEY_POS_SEARCH'
  362 |    KEY_POS_SEARCH | KEY_USR_SEARCH | KEY_USR_VIEW,
      |    ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
                 from fs/crypto/keyring.c:22:
include/linux/key.h:256:20: note: expected 'struct key_acl *' but argument is of type 'int'
  256 | extern struct key *key_alloc(struct key_type *type,
      |                    ^~~~~~~~~
drivers/md/dm-verity-verify-sig.c: In function 'verity_verify_get_sig_from_key':
drivers/md/dm-verity-verify-sig.c:38:8: error: too few arguments to function 'request_key'
   38 |  key = request_key(&key_type_user,
      |        ^~~~~~~~~~~
In file included from include/keys/user-type.h:11,
                 from drivers/md/dm-verity-verify-sig.c:10:
include/linux/key.h:321:27: note: declared here
  321 | static inline struct key *request_key(struct key_type *type,
      |                           ^~~~~~~~~~~

Caused by API updates in the keys tree without fixups of their uses.

The keys tree is now based on v5.5-rc3 ...

The callis to keyring_alloc() in fs/verity/signature.c and
fs/crypto/keyring.c were added in v5.4-rc1.  As were the calls to
request_key() in fs/crypto/keysetup_v1.c and
drivers/md/dm-verity-verify-sig.c.

I have used the keys tree from next-20191211 again today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

Hi David,

On Tue, 03 Sep 2019 00:53:14 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > > I was doing an x86_64 allmodconfig build which seems to build (all of?)
> > > the samples.  
> > 
> > Of course, this breaks our crossbuilds :-(
> > 
> > e.g. S390 allyesconfig build:
> > 
> > /usr/bin/ld: cannot find -lkeyutils  
> 
> Is it a requirement that stuff in samples/ should be able to build without
> resorting to external userspace headers?  Or, at least, those outside of the C
> library?

Well, this is the only samples failure in the current build ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > I was doing an x86_64 allmodconfig build which seems to build (all of?)
> > the samples.
> 
> Of course, this breaks our crossbuilds :-(
> 
> e.g. S390 allyesconfig build:
> 
> /usr/bin/ld: cannot find -lkeyutils

Is it a requirement that stuff in samples/ should be able to build without
resorting to external userspace headers?  Or, at least, those outside of the C
library?

David

Re: linux-next: build failure after merge of the keys tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > Ah, yes - the sample demonstrates the key/keyring notifications as well as
> > USB and block notifications and requires a constant from the
> > keyutils-devel package.  Maybe I should get it from the kernel UAPI
> > headers instead, but that risks generating a collision.
> 
> What sort of collision?

Accidentally including both a userspace header file and a kernel UAPI header
file with the constants colliding.

Anyway, I've pushed a new version of keys-next and also keyutils if you're
employing the testsuite from that at all.

David

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Hi David,

On Tue, 03 Sep 2019 00:20:08 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Ah, yes - the sample demonstrates the key/keyring notifications as well as USB
> and block notifications and requires a constant from the keyutils-devel
> package.  Maybe I should get it from the kernel UAPI headers instead, but that
> risks generating a collision.

What sort of collision?
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

Hi David,

On Tue, 3 Sep 2019 09:07:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > > I then discovered that I needed to install libkeyutils-dev :-( but it
> > > built OK after that.    
> > 
> > ?  The kernel shouldn't require that to build.  
> 
> I was doing an x86_64 allmodconfig build which seems to build (all of?)
> the samples.

Of course, this breaks our crossbuilds :-(

e.g. S390 allyesconfig build:

/usr/bin/ld: cannot find -lkeyutils

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > static inline void post_usb_device_notification(const struct usb_device *udev,
> > 						unsigned int subtype, u32 error) {}
> 
> But not published, yet?

I was hoping to get the smack patch reviewed by Casey first, but I can
publish anyway.

> > > I then discovered that I needed to install libkeyutils-dev :-( but it
> > > built OK after that.  
> > 
> > ?  The kernel shouldn't require that to build.
> 
> I was doing an x86_64 allmodconfig build which seems to build (all of?)
> the samples.

Ah, yes - the sample demonstrates the key/keyring notifications as well as USB
and block notifications and requires a constant from the keyutils-devel
package.  Maybe I should get it from the kernel UAPI headers instead, but that
risks generating a collision.

David

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

Hi David,

On Mon, 02 Sep 2019 17:01:19 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > The forward declararion doesn't seem to work (at laste for the
> > !CONFIG_USB_NOTIFICATIONS case.  
> 
> In the !CONFIG_USB_NOTIFICATIONS case, the argument is to a stub inline
> function.  Even though the argument isn't actually used, it can't be an
> undefined type - and, I'm guessing, an undefined size, meaning the compiler
> doesn't know how many registers/how much stack space it would occupy before
> getting to the error argument.
> 
> I have a fix for this in my tree that just makes it an unsigned int in the
> disabled case:
> 
> static inline void post_usb_device_notification(const struct usb_device *udev,
> 						unsigned int subtype, u32 error) {}

But not published, yet?

> > +#include <linux/watch_queue.h>  
> 
> I was trying to avoid that if I could to avoid introducing the possibility of
> circular deps, but that might not be a problem in this case.

Seems to be OK for x86_64 allmodconfig at least.

> 
> > I then discovered that I needed to install libkeyutils-dev :-( but it
> > built OK after that.  
> 
> ?  The kernel shouldn't require that to build.

I was doing an x86_64 allmodconfig build which seems to build (all of?)
the samples.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> The forward declararion doesn't seem to work (at laste for the
> !CONFIG_USB_NOTIFICATIONS case.

In the !CONFIG_USB_NOTIFICATIONS case, the argument is to a stub inline
function.  Even though the argument isn't actually used, it can't be an
undefined type - and, I'm guessing, an undefined size, meaning the compiler
doesn't know how many registers/how much stack space it would occupy before
getting to the error argument.

I have a fix for this in my tree that just makes it an unsigned int in the
disabled case:

static inline void post_usb_device_notification(const struct usb_device *udev,
						unsigned int subtype, u32 error) {}

> +#include <linux/watch_queue.h>

I was trying to avoid that if I could to avoid introducing the possibility of
circular deps, but that might not be a problem in this case.

> I then discovered that I needed to install libkeyutils-dev :-( but it
> built OK after that.

?  The kernel shouldn't require that to build.

David

Re: linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]

Hi all,

On Thu, 29 Aug 2019 15:31:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the keys tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> 
> Caused by commit
> 
>   ef9cc255c953 ("usb: Add USB subsystem notifications")
> 
> # CONFIG_USB_NOTIFICATIONS is not set
> 
> I have used the keys tree from next-20190828 for today.

I only realised this morning that I forgot to include the error log
(sorry):

In file included from include/linux/usb/phy.h:15,
                 from include/linux/usb/otg.h:14,
                 from include/linux/usb/tegra_usb_phy.h:21,
                 from arch/arm/mach-tegra/tegra.c:27:
include/linux/usb.h:2026:34: error: parameter 2 ('subtype') has incomplete type
 2026 |       enum usb_notification_type subtype,
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
include/linux/usb.h:2025:20: error: function declaration isn't a prototype [-Werror=strict-prototypes]
 2025 | static inline void post_usb_device_notification(const struct usb_device *udev,
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/usb.h:2029:38: error: parameter 2 ('subtype') has incomplete type
 2029 |           enum usb_notification_type subtype,
      |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
include/linux/usb.h:2028:20: error: function declaration isn't a prototype [-Werror=strict-prototypes]
 2028 | static inline void post_usb_bus_notification(const struct usb_bus *ubus,
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~

(several more like this)

Today I have included the following fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Sep 2019 16:01:59 +1000
Subject: [PATCH] usb: include watch_queue.h for needed enum

The forward declararion doesn't seem to work (at laste for the
!CONFIG_USB_NOTIFICATIONS case.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/usb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb.h b/include/linux/usb.h
index a7d5fce46569..11438058f4fa 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -4,6 +4,7 @@
 
 #include <linux/mod_devicetable.h>
 #include <linux/usb/ch9.h>
+#include <linux/watch_queue.h>
 
 #define USB_MAJOR			180
 #define USB_DEVICE_MAJOR		189
@@ -26,7 +27,6 @@
 struct usb_device;
 struct usb_driver;
 struct wusb_dev;
-enum usb_notification_type;
 
 /*-------------------------------------------------------------------------*/
 
-- 
2.23.0.rc1

I then discovered that I needed to install libkeyutils-dev :-( but it
built OK after that.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:


Caused by commit

  ef9cc255c953 ("usb: Add USB subsystem notifications")

# CONFIG_USB_NOTIFICATIONS is not set

I have used the keys tree from next-20190828 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/md/dm-verity-verify-sig.c: In function 'verity_verify_get_sig_from_key':
drivers/md/dm-verity-verify-sig.c:38:8: error: too few arguments to function 'request_key'
  key = request_key(&key_type_user,
        ^~~~~~~~~~~
In file included from include/keys/user-type.h:11,
                 from drivers/md/dm-verity-verify-sig.c:10:
include/linux/key.h:318:27: note: declared here
 static inline struct key *request_key(struct key_type *type,
                           ^~~~~~~~~~~

Caused by commit

  f802f2b3a991 ("keys: Replace uid/gid/perm permissions checking with an ACL")

interacting with commit

  644332ceab35 ("dm verity: add root hash pkcs#7 signature verification")

from the device-mapper tree.

I applied the following merge resolution patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 16 Aug 2019 15:00:15 +1000
Subject: [PATCH] dm verity: merge fix for "keys: Replace uid/gid/perm
 permissions checking with an ACL"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/md/dm-verity-verify-sig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c
index 614e43db93aa..2ca162d43fe6 100644
--- a/drivers/md/dm-verity-verify-sig.c
+++ b/drivers/md/dm-verity-verify-sig.c
@@ -36,7 +36,7 @@ static int verity_verify_get_sig_from_key(const char *key_desc,
 	int ret = 0;
 
 	key = request_key(&key_type_user,
-			key_desc, NULL);
+			key_desc, NULL, NULL);
 	if (IS_ERR(key))
 		return PTR_ERR(key);
 
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the keys tree

[David Howells]

I've dropped the keyrings ACL patches from the branch for now.  I'll revisit
them after the merge window.

David

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

Hi David,

After merging the keys tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/md/dm-crypt.c: In function 'crypt_set_keyring_key':
drivers/md/dm-crypt.c:2022:8: error: too few arguments to function 'request_key'
  key = request_key(key_string[0] == 'l' ? &key_type_logon : &key_type_user,   
        ^
In file included from drivers/md/dm-crypt.c:15:0:
include/linux/key.h:268:20: note: declared here
 extern struct key *request_key(struct key_type *type,
                    ^

Caused by commit

  b059d2a56c53 ("KEYS: Replace uid/gid/perm permissions checking with an ACL")

I have used the keys tree from next-20171110 for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the keys tree

[Stephen Rothwell]

Hi David,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

security/integrity/digsig.c: In function 'integrity_init_keyring':
security/integrity/digsig.c:46:30: error: passing argument 7 of 'keyring_alloc' from incompatible pointer type [-Werror=incompatible-pointer-types]
 #define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
                              ^
security/integrity/digsig.c:95:9: note: in expansion of macro 'restrict_link_to_ima'
         restrict_link_to_ima, NULL);
         ^
In file included from include/linux/cred.h:17:0,
                 from security/integrity/digsig.c:18:
include/linux/key.h:311:20: note: expected 'struct key_restriction *' but argument is of type 'int (*)(struct key *, const struct key_type *, const union key_payload *, struct key *)'
 extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
                    ^

Caused by commits

  aaf66c883813 ("KEYS: Split role of the keyring pointer for keyring restrict functions")
  c5faca6b4a58 ("KEYS: Use structure to capture key restriction function and data")

I have used the version from next-20170403 for today.

-- 
Cheers,
Stephen Rothwell