linux-next: build failure after merge of the keys tree
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 Date: Fri, 11 Dec 2020 15:46:09 +1100 Subject: [PATCH] fixup for "certs: Fix blacklist flag type confusion" Signed-off-by: Stephen Rothwell --- 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 pgpOFxzQdSKSq.pgp Description: OpenPGP digital signature
linux-next: build failure after merge of the keys tree
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 pgpNUjVU01j40.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
On Thu, May 14, 2020 at 6:35 AM Masahiro Yamada wrote: > > On Thu, May 14, 2020 at 9:11 PM David Howells wrote: > > > > Jason A. Donenfeld 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
On Thu, May 14, 2020 at 9:11 PM David Howells wrote: > > Jason A. Donenfeld 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
Jason A. Donenfeld 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
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 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' >
linux-next: build failure after merge of the keys tree
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:
Re: linux-next: build failure after merge of the keys tree
Hi all, On Mon, 4 May 2020 13:25:29 +1000 Stephen Rothwell wrote: > > Due to further changes in Linus' tree over the weekend, this fixup is > not linger needed. "no longer" (Monday's ...) -- Cheers, Stephen Rothwell pgpQJB6x10RtY.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
Hi all, On Mon, 2 Mar 2020 11:37:37 +1100 Stephen Rothwell 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 > 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 > --- > 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 pgpBpQTKBbyEq.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
Hi David, On Tue, 03 Sep 2019 00:53:14 +0100 David Howells wrote: > > Stephen Rothwell 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 pgpL2THmMbOFO.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
Stephen Rothwell 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
Stephen Rothwell 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
Hi David, On Tue, 03 Sep 2019 00:20:08 +0100 David Howells 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 pgpeCFMxy1_IA.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
Hi David, On Tue, 3 Sep 2019 09:07:22 +1000 Stephen Rothwell 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 pgpgCNMA4JHPx.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
Stephen Rothwell 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
Hi David, On Mon, 02 Sep 2019 17:01:19 +0100 David Howells wrote: > > Stephen Rothwell 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 > > 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 pgpKnS5pPZ3g1.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
Stephen Rothwell 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 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
Hi all, On Thu, 29 Aug 2019 15:31:16 +1000 Stephen Rothwell 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 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 --- 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 #include +#include #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 pgpV4C2Rw_hI0.pgp Description: OpenPGP digital signature
linux-next: build failure after merge of the keys tree
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 pgpKFod8MZp2_.pgp Description: OpenPGP digital signature
linux-next: build failure after merge of the keys tree
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(_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 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 --- 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(_type_user, - key_desc, NULL); + key_desc, NULL, NULL); if (IS_ERR(key)) return PTR_ERR(key); -- 2.20.1 -- Cheers, Stephen Rothwell pgp0pl7YwKusU.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the keys tree
I've dropped the keyrings ACL patches from the branch for now. I'll revisit them after the merge window. David
Re: linux-next: build failure after merge of the keys tree
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
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' ? _type_logon : _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
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' ? _type_logon : _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
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
linux-next: build failure after merge of the keys tree
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