From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
Date: Wed, 28 Jul 2021 02:39:05 +0800 [thread overview]
Message-ID: <202107280211.ecfaL0Im-lkp@intel.com> (raw)
In-Reply-To: <20210727144349.11215-1-a.fatoum@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 7793 bytes --]
Hi Ahmad,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.14-rc3 next-20210726]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Ahmad-Fatoum/fscrypt-support-encrypted-and-trusted-keys/20210727-224735
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 349a2d52ffe59b7a0c5876fa7ee9f3eaf188b830
config: x86_64-randconfig-a003-20210727 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project c658b472f3e61e1818e1909bf02f3d65470018a5)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# https://github.com/0day-ci/linux/commit/c945f8dc7432898b66cc34db21066db48b9c0d70
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Ahmad-Fatoum/fscrypt-support-encrypted-and-trusted-keys/20210727-224735
git checkout c945f8dc7432898b66cc34db21066db48b9c0d70
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
fs/crypto/keyring.c:701:19: error: implicit declaration of function 'key_extract_material' [-Werror,-Wimplicit-function-declaration]
key_material = key_extract_material(keyring_key, &secret.size);
^
>> fs/crypto/keyring.c:701:17: warning: incompatible integer to pointer conversion assigning to 'const void *' from 'int' [-Wint-conversion]
key_material = key_extract_material(keyring_key, &secret.size);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning and 1 error generated.
vim +701 fs/crypto/keyring.c
609
610 /*
611 * Add a master encryption key to the filesystem, causing all files which were
612 * encrypted with it to appear "unlocked" (decrypted) when accessed.
613 *
614 * When adding a key for use by v1 encryption policies, this ioctl is
615 * privileged, and userspace must provide the 'key_descriptor'.
616 *
617 * When adding a key for use by v2+ encryption policies, this ioctl is
618 * unprivileged. This is needed, in general, to allow non-root users to use
619 * encryption without encountering the visibility problems of process-subscribed
620 * keyrings and the inability to properly remove keys. This works by having
621 * each key identified by its cryptographically secure hash --- the
622 * 'key_identifier'. The cryptographic hash ensures that a malicious user
623 * cannot add the wrong key for a given identifier. Furthermore, each added key
624 * is charged to the appropriate user's quota for the keyrings service, which
625 * prevents a malicious user from adding too many keys. Finally, we forbid a
626 * user from removing a key while other users have added it too, which prevents
627 * a user who knows another user's key from causing a denial-of-service by
628 * removing it at an inopportune time. (We tolerate that a user who knows a key
629 * can prevent other users from removing it.)
630 *
631 * For more details, see the "FS_IOC_ADD_ENCRYPTION_KEY" section of
632 * Documentation/filesystems/fscrypt.rst.
633 */
634 int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
635 {
636 struct super_block *sb = file_inode(filp)->i_sb;
637 struct fscrypt_add_key_arg __user *uarg = _uarg;
638 struct fscrypt_add_key_arg arg;
639 struct fscrypt_master_key_secret secret;
640 int err;
641
642 if (copy_from_user(&arg, uarg, sizeof(arg)))
643 return -EFAULT;
644
645 if (!valid_key_spec(&arg.key_spec))
646 return -EINVAL;
647
648 if (memchr_inv(arg.__reserved, 0, sizeof(arg.__reserved)))
649 return -EINVAL;
650
651 /*
652 * Only root can add keys that are identified by an arbitrary descriptor
653 * rather than by a cryptographic hash --- since otherwise a malicious
654 * user could add the wrong key.
655 */
656 if (arg.key_spec.type == FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR &&
657 !capable(CAP_SYS_ADMIN))
658 return -EACCES;
659
660 memset(&secret, 0, sizeof(secret));
661 if (arg.key_id) {
662 if (arg.raw_size != 0)
663 return -EINVAL;
664 err = get_keyring_key(arg.key_id, arg.key_spec.type, &secret);
665 if (err)
666 goto out_wipe_secret;
667 } else {
668 struct key *keyring_key = ERR_PTR(-EINVAL);
669 const void *key_material;
670 const char *desc;
671
672 switch (arg.raw_flags) {
673 case FSCRYPT_KEY_ADD_RAW_ASIS:
674 if (arg.raw_size < FSCRYPT_MIN_KEY_SIZE ||
675 arg.raw_size > FSCRYPT_MAX_KEY_SIZE)
676 return -EINVAL;
677 secret.size = arg.raw_size;
678 err = -EFAULT;
679 if (copy_from_user(secret.raw, uarg->raw, secret.size))
680 goto out_wipe_secret;
681 break;
682 case FSCRYPT_KEY_ADD_RAW_DESC:
683 if (arg.raw_size > 4096)
684 return -EINVAL;
685 desc = memdup_user_nul(uarg->raw, arg.raw_size);
686 if (IS_ERR(desc))
687 return PTR_ERR(desc);
688
689 if (IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
690 keyring_key = request_key(&key_type_encrypted, desc, NULL);
691 if (IS_REACHABLE(CONFIG_TRUSTED_KEYS) && IS_ERR(keyring_key))
692 keyring_key = request_key(&key_type_trusted, desc, NULL);
693
694 kfree(desc);
695
696 if (IS_ERR(keyring_key))
697 return PTR_ERR(keyring_key);
698
699 down_read(&keyring_key->sem);
700
> 701 key_material = key_extract_material(keyring_key, &secret.size);
702 if (!IS_ERR(key_material) && (secret.size < FSCRYPT_MIN_KEY_SIZE ||
703 secret.size > FSCRYPT_MAX_KEY_SIZE))
704 key_material = ERR_PTR(-EINVAL);
705 if (IS_ERR(key_material)) {
706 up_read(&keyring_key->sem);
707 key_put(keyring_key);
708 return PTR_ERR(key_material);
709 }
710
711 memcpy(secret.raw, key_material, secret.size);
712
713 up_read(&keyring_key->sem);
714 key_put(keyring_key);
715 break;
716 default:
717 return -EINVAL;
718 }
719 }
720
721 err = add_master_key(sb, &secret, &arg.key_spec);
722 if (err)
723 goto out_wipe_secret;
724
725 /* Return the key identifier to userspace, if applicable */
726 err = -EFAULT;
727 if (arg.key_spec.type == FSCRYPT_KEY_SPEC_TYPE_IDENTIFIER &&
728 copy_to_user(uarg->key_spec.u.identifier, arg.key_spec.u.identifier,
729 FSCRYPT_KEY_IDENTIFIER_SIZE))
730 goto out_wipe_secret;
731 err = 0;
732 out_wipe_secret:
733 wipe_master_key_secret(&secret);
734 return err;
735 }
736 EXPORT_SYMBOL_GPL(fscrypt_ioctl_add_key);
737
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 35897 bytes --]
next prev parent reply other threads:[~2021-07-27 18:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 14:43 [RFC PATCH v1] fscrypt: support encrypted and trusted keys Ahmad Fatoum
2021-07-27 16:38 ` Eric Biggers
2021-07-28 8:50 ` Ahmad Fatoum
2021-07-28 16:05 ` Eric Biggers
2021-07-29 5:56 ` Sumit Garg
2021-07-29 9:07 ` Ahmad Fatoum
2021-07-29 18:28 ` Eric Biggers
2021-07-27 17:09 ` kernel test robot
2021-07-27 18:39 ` kernel test robot [this message]
2021-07-28 22:22 ` Jarkko Sakkinen
2021-07-28 22:27 ` Ahmad Fatoum
-- strict thread matches above, loose matches on Subject: below --
2021-07-27 16:56 kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202107280211.ecfaL0Im-lkp@intel.com \
--to=lkp@intel.com \
--cc=kbuild-all@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.