All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.