All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v1] fscrypt: support encrypted and trusted keys
@ 2021-07-27 14:43 Ahmad Fatoum
  2021-07-27 16:38 ` Eric Biggers
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Ahmad Fatoum @ 2021-07-27 14:43 UTC (permalink / raw)
  To: Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers
  Cc: Ahmad Fatoum, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
	James Bottomley, Mimi Zohar, Sumit Garg, David Howells,
	linux-fscrypt, linux-crypto, linux-integrity,
	linux-security-module, keyrings, linux-kernel

For both v1 and v2 key setup mechanisms, userspace supplies the raw key
material to the kernel after which it is never again disclosed to
userspace.

Use of encrypted and trusted keys offers stronger guarantees:
The key material is generated within the kernel and is never disclosed to
userspace in clear text and, in the case of trusted keys, can be
directly rooted to a trust source like a TPM chip.

Add support for trusted and encrypted keys by repurposing
fscrypt_add_key_arg::raw to hold the key description when the new
FSCRYPT_KEY_ARG_TYPE_DESC flag is supplied. The location of the flag
was previously reserved and enforced by ioctl code to be zero, so this
change won't break backwards compatibility.

Corresponding userspace patches are available for fscryptctl:
https://github.com/google/fscryptctl/pull/23

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
key_extract_material used by this patch is added in
<cover.b2fdd70b830d12853b12a12e32ceb0c8162c1346.1626945419.git-series.a.fatoum@pengutronix.de>
which still awaits feedback.

Sending this RFC out anyway to get some feedback from the fscrypt
developers whether this is the correct way to go about it.

To: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jaegeuk Kim <jaegeuk@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: David Howells <dhowells@redhat.com>
Cc: linux-fscrypt@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/filesystems/fscrypt.rst | 24 ++++++++---
 fs/crypto/keyring.c                   | 59 ++++++++++++++++++++++++---
 include/uapi/linux/fscrypt.h          | 16 +++++++-
 3 files changed, 87 insertions(+), 12 deletions(-)

diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index 44b67ebd6e40..83738af2afa3 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -681,11 +681,15 @@ It can be executed on any file or directory on the target filesystem,
 but using the filesystem's root directory is recommended.  It takes in
 a pointer to struct fscrypt_add_key_arg, defined as follows::
 
+    #define FSCRYPT_KEY_ADD_RAW_ASIS		0
+    #define FSCRYPT_KEY_ADD_RAW_DESC		1
+
     struct fscrypt_add_key_arg {
             struct fscrypt_key_specifier key_spec;
             __u32 raw_size;
             __u32 key_id;
-            __u32 __reserved[8];
+            __u32 raw_flags;     /* one of FSCRYPT_KEY_ADD_RAW_* */
+            __u32 __reserved[7];
             __u8 raw[];
     };
 
@@ -732,8 +736,11 @@ as follows:
   Alternatively, if ``key_id`` is nonzero, this field must be 0, since
   in that case the size is implied by the specified Linux keyring key.
 
-- ``key_id`` is 0 if the raw key is given directly in the ``raw``
-  field.  Otherwise ``key_id`` is the ID of a Linux keyring key of
+- If ``key_id`` is 0, the raw key is given directly in the ``raw``
+  field if ``raw_flags == FSCRYPT_KEY_ADD_RAW_ASIS``. With
+  ``raw_flags == FSCRYPT_KEY_ADD_RAW_DESC``, ``raw`` is instead
+  interpreted as the description of an encrypted or trusted key.
+  Otherwise ``key_id`` is the ID of a Linux keyring key of
   type "fscrypt-provisioning" whose payload is
   struct fscrypt_provisioning_key_payload whose ``raw`` field contains
   the raw key and whose ``type`` field matches ``key_spec.type``.
@@ -748,8 +755,15 @@ as follows:
   without having to store the raw keys in userspace memory.
 
 - ``raw`` is a variable-length field which must contain the actual
-  key, ``raw_size`` bytes long.  Alternatively, if ``key_id`` is
-  nonzero, then this field is unused.
+  key when ``raw_flags == FSCRYPT_KEY_ADD_RAW_ASIS``,
+  ``raw_size`` bytes long.  Alternatively, if
+  ``raw_flags == FSCRYPT_KEY_ADD_RAW_DESC``, ``raw`` is interpreted
+  as the key description of an encrypted or trusted key, in that order.
+  The material of this key will be used as if it were a raw key
+  supplied by userspace.
+
+  In both cases, the buffer is ``raw_size`` bytes long. If ````key_id``
+  is nonzero, then this field is unused.
 
 For v2 policy keys, the kernel keeps track of which user (identified
 by effective user ID) added the key, and only allows the key to be
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index 0b3ffbb4faf4..484f7c883b17 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -20,6 +20,9 @@
 
 #include <crypto/skcipher.h>
 #include <linux/key-type.h>
+#include <linux/key-type.h>
+#include <keys/encrypted-type.h>
+#include <keys/trusted-type.h>
 #include <linux/random.h>
 #include <linux/seq_file.h>
 
@@ -662,13 +665,57 @@ int fscrypt_ioctl_add_key(struct file *filp, void __user *_uarg)
 		if (err)
 			goto out_wipe_secret;
 	} else {
-		if (arg.raw_size < FSCRYPT_MIN_KEY_SIZE ||
-		    arg.raw_size > FSCRYPT_MAX_KEY_SIZE)
+		struct key *keyring_key = ERR_PTR(-EINVAL);
+		const void *key_material;
+		const char *desc;
+
+		switch (arg.raw_flags) {
+		case FSCRYPT_KEY_ADD_RAW_ASIS:
+			if (arg.raw_size < FSCRYPT_MIN_KEY_SIZE ||
+			    arg.raw_size > FSCRYPT_MAX_KEY_SIZE)
+				return -EINVAL;
+			secret.size = arg.raw_size;
+			err = -EFAULT;
+			if (copy_from_user(secret.raw, uarg->raw, secret.size))
+				goto out_wipe_secret;
+			break;
+		case FSCRYPT_KEY_ADD_RAW_DESC:
+			if (arg.raw_size > 4096)
+				return -EINVAL;
+			desc = memdup_user_nul(uarg->raw, arg.raw_size);
+			if (IS_ERR(desc))
+				return PTR_ERR(desc);
+
+			if (IS_REACHABLE(CONFIG_ENCRYPTED_KEYS))
+				keyring_key = request_key(&key_type_encrypted, desc, NULL);
+			if (IS_REACHABLE(CONFIG_TRUSTED_KEYS) && IS_ERR(keyring_key))
+				keyring_key = request_key(&key_type_trusted, desc, NULL);
+
+			kfree(desc);
+
+			if (IS_ERR(keyring_key))
+				return PTR_ERR(keyring_key);
+
+			down_read(&keyring_key->sem);
+
+			key_material = key_extract_material(keyring_key, &secret.size);
+			if (!IS_ERR(key_material) && (secret.size < FSCRYPT_MIN_KEY_SIZE ||
+			    secret.size > FSCRYPT_MAX_KEY_SIZE))
+				key_material = ERR_PTR(-EINVAL);
+			if (IS_ERR(key_material)) {
+				up_read(&keyring_key->sem);
+				key_put(keyring_key);
+				return PTR_ERR(key_material);
+			}
+
+			memcpy(secret.raw, key_material, secret.size);
+
+			up_read(&keyring_key->sem);
+			key_put(keyring_key);
+			break;
+		default:
 			return -EINVAL;
-		secret.size = arg.raw_size;
-		err = -EFAULT;
-		if (copy_from_user(secret.raw, uarg->raw, secret.size))
-			goto out_wipe_secret;
+		}
 	}
 
 	err = add_master_key(sb, &secret, &arg.key_spec);
diff --git a/include/uapi/linux/fscrypt.h b/include/uapi/linux/fscrypt.h
index 9f4428be3e36..bd498a188cf5 100644
--- a/include/uapi/linux/fscrypt.h
+++ b/include/uapi/linux/fscrypt.h
@@ -119,12 +119,26 @@ struct fscrypt_provisioning_key_payload {
 	__u8 raw[];
 };
 
+/*
+ * fscrypt_add_key_arg::raw contains the raw key material directly
+ * if key_id == 0
+ */
+#define FSCRYPT_KEY_ADD_RAW_ASIS		0
+
+/*
+ * fscrypt_add_key_arg::raw is a key descriptor for an already
+ * existing kernel encrypted or trusted key if key_id == 0.
+ * The kernel key's material will be used as input for fscrypt.
+ */
+#define FSCRYPT_KEY_ADD_RAW_DESC		1
+
 /* Struct passed to FS_IOC_ADD_ENCRYPTION_KEY */
 struct fscrypt_add_key_arg {
 	struct fscrypt_key_specifier key_spec;
 	__u32 raw_size;
 	__u32 key_id;
-	__u32 __reserved[8];
+	__u32 raw_flags;	/* one of FSCRYPT_KEY_ADD_RAW_* */
+	__u32 __reserved[7];
 	__u8 raw[];
 };
 
-- 
2.30.2


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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  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-27 17:09 ` kernel test robot
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 12+ messages in thread
From: Eric Biggers @ 2021-07-27 16:38 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Theodore Y. Ts'o, Jaegeuk Kim, Jarkko Sakkinen, James Morris,
	Serge E. Hallyn, James Bottomley, Mimi Zohar, Sumit Garg,
	David Howells, linux-fscrypt, linux-crypto, linux-integrity,
	linux-security-module, keyrings, linux-kernel

On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
> material to the kernel after which it is never again disclosed to
> userspace.
> 
> Use of encrypted and trusted keys offers stronger guarantees:
> The key material is generated within the kernel and is never disclosed to
> userspace in clear text and, in the case of trusted keys, can be
> directly rooted to a trust source like a TPM chip.

Please include a proper justification for this feature and update the relevant
sections of Documentation/filesystems/fscrypt.rst to explain why someone would
want to use this feature and what it accomplishes.

As-is, this feature doesn't seem to have a very strong justification.  Please
also see previous threads where this feature was discussed/requested:
https://lkml.kernel.org/linux-fscrypt/20180110124418.24385-1-git@andred.net/T/#u,
https://lkml.kernel.org/linux-fscrypt/20180118131359.8365-1-git@andred.net/T/#u,
https://lkml.kernel.org/linux-fscrypt/20200116193228.GA266386@vader/T/#u

Note that there are several design flaws with the encrypted and trusted key
types:

- By default, trusted keys are generated using the TPM's RNG rather than the
  kernel's RNG, which places all trust in an unauditable black box.

- trusted and encrypted keys aren't restricted to specific uses in the kernel
  (like the fscrypt-provisioning key type is) but rather are general-purpose.
  Hence, it may be possible to leak their contents to userspace by requesting
  their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
  using a weak cipher that is vulnerable to key recovery attacks.

- "encrypted" keys that use a master key of type "user" are supported, despite
  these being easily obtainable in the clear by userspace providing their own
  master key.  This violates one of the main design goals of "encrypted" keys.

Also, using the "trusted" key type isn't necessary to achieve TPM-bound
encryption, as TPM binding can be handled in userspace instead.

So I really would like to see a proper justification for this feature, and have
it be properly documented.

One comment on the UAPI below.

> 
> Add support for trusted and encrypted keys by repurposing
> fscrypt_add_key_arg::raw to hold the key description when the new
> FSCRYPT_KEY_ARG_TYPE_DESC flag is supplied. The location of the flag
> was previously reserved and enforced by ioctl code to be zero, so this
> change won't break backwards compatibility.
> 
> Corresponding userspace patches are available for fscryptctl:
> https://github.com/google/fscryptctl/pull/23
> 
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> key_extract_material used by this patch is added in
> <cover.b2fdd70b830d12853b12a12e32ceb0c8162c1346.1626945419.git-series.a.fatoum@pengutronix.de>
> which still awaits feedback.
> 
> Sending this RFC out anyway to get some feedback from the fscrypt
> developers whether this is the correct way to go about it.
> 
> To: "Theodore Y. Ts'o" <tytso@mit.edu>
> To: Jaegeuk Kim <jaegeuk@kernel.org>
> To: Eric Biggers <ebiggers@kernel.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: David Howells <dhowells@redhat.com>
> Cc: linux-fscrypt@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  Documentation/filesystems/fscrypt.rst | 24 ++++++++---
>  fs/crypto/keyring.c                   | 59 ++++++++++++++++++++++++---
>  include/uapi/linux/fscrypt.h          | 16 +++++++-
>  3 files changed, 87 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
> index 44b67ebd6e40..83738af2afa3 100644
> --- a/Documentation/filesystems/fscrypt.rst
> +++ b/Documentation/filesystems/fscrypt.rst
> @@ -681,11 +681,15 @@ It can be executed on any file or directory on the target filesystem,
>  but using the filesystem's root directory is recommended.  It takes in
>  a pointer to struct fscrypt_add_key_arg, defined as follows::
>  
> +    #define FSCRYPT_KEY_ADD_RAW_ASIS		0
> +    #define FSCRYPT_KEY_ADD_RAW_DESC		1
> +
>      struct fscrypt_add_key_arg {
>              struct fscrypt_key_specifier key_spec;
>              __u32 raw_size;
>              __u32 key_id;
> -            __u32 __reserved[8];
> +            __u32 raw_flags;     /* one of FSCRYPT_KEY_ADD_RAW_* */
> +            __u32 __reserved[7];
>              __u8 raw[];
>      };
>  
> @@ -732,8 +736,11 @@ as follows:
>    Alternatively, if ``key_id`` is nonzero, this field must be 0, since
>    in that case the size is implied by the specified Linux keyring key.
>  
> -- ``key_id`` is 0 if the raw key is given directly in the ``raw``
> -  field.  Otherwise ``key_id`` is the ID of a Linux keyring key of
> +- If ``key_id`` is 0, the raw key is given directly in the ``raw``
> +  field if ``raw_flags == FSCRYPT_KEY_ADD_RAW_ASIS``. With
> +  ``raw_flags == FSCRYPT_KEY_ADD_RAW_DESC``, ``raw`` is instead
> +  interpreted as the description of an encrypted or trusted key.
> +  Otherwise ``key_id`` is the ID of a Linux keyring key of
>    type "fscrypt-provisioning" whose payload is
>    struct fscrypt_provisioning_key_payload whose ``raw`` field contains
>    the raw key and whose ``type`` field matches ``key_spec.type``.
> @@ -748,8 +755,15 @@ as follows:
>    without having to store the raw keys in userspace memory.

Why not just allow the key_id field to specify a "trusted" or "encrypted" key?
Why is it necessary for FS_IOC_ADD_ENCRYPTION_KEY to support two different ways
of looking up keyring keys -- by ID and by description?  Looking up by ID works
fine for "fscrypt-provisioning" keys; why are "trusted" and "encrypted" keys
different in this regard?

- Eric

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  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-27 17:09 ` kernel test robot
  2021-07-27 18:39 ` kernel test robot
  2021-07-28 22:22 ` Jarkko Sakkinen
  3 siblings, 0 replies; 12+ messages in thread
From: kernel test robot @ 2021-07-27 17:09 UTC (permalink / raw)
  To: kbuild-all

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

Hi Ahmad,

[FYI, it's a private test report for your RFC patch.]
[auto build test ERROR on linux/master]
[also build test ERROR on linus/master v5.14-rc3 next-20210726]
[cannot apply to tytso-fscrypt/master]
[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: microblaze-randconfig-r031-20210727 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 10.3.0
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
        # 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=gcc-10.3.0 make.cross ARCH=microblaze 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   fs/crypto/keyring.c: In function 'fscrypt_ioctl_add_key':
>> fs/crypto/keyring.c:701:19: error: implicit declaration of function 'key_extract_material' [-Werror=implicit-function-declaration]
     701 |    key_material = key_extract_material(keyring_key, &secret.size);
         |                   ^~~~~~~~~~~~~~~~~~~~
>> fs/crypto/keyring.c:701:17: warning: assignment to 'const void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     701 |    key_material = key_extract_material(keyring_key, &secret.size);
         |                 ^
   cc1: some warnings being treated as errors


vim +/key_extract_material +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: 36511 bytes --]

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  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-27 17:09 ` kernel test robot
@ 2021-07-27 18:39 ` kernel test robot
  2021-07-28 22:22 ` Jarkko Sakkinen
  3 siblings, 0 replies; 12+ messages in thread
From: kernel test robot @ 2021-07-27 18:39 UTC (permalink / raw)
  To: kbuild-all

[-- 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 --]

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-27 16:38 ` Eric Biggers
@ 2021-07-28  8:50   ` Ahmad Fatoum
  2021-07-28 16:05     ` Eric Biggers
  0 siblings, 1 reply; 12+ messages in thread
From: Ahmad Fatoum @ 2021-07-28  8:50 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Theodore Y. Ts'o, Jaegeuk Kim, Jarkko Sakkinen, James Morris,
	Serge E. Hallyn, James Bottomley, Mimi Zohar, Sumit Garg,
	David Howells, linux-fscrypt, linux-crypto, linux-integrity,
	linux-security-module, keyrings, linux-kernel, git,
	Omar Sandoval, Pengutronix Kernel Team

Hello Eric,

On 27.07.21 18:38, Eric Biggers wrote:
> On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
>> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
>> material to the kernel after which it is never again disclosed to
>> userspace.
>>
>> Use of encrypted and trusted keys offers stronger guarantees:
>> The key material is generated within the kernel and is never disclosed to
>> userspace in clear text and, in the case of trusted keys, can be
>> directly rooted to a trust source like a TPM chip.
> 
> Please include a proper justification for this feature

I've patches pending for extending trusted keys to wrap the key sealing
functionality of the CAAM IP on NXP SoCs[1]. I want the kernel to
generate key material in the factory, have the CAAM encrypt it using its
undisclosed unique key and pass it to userspace as encrypted blob that is
persisted to an unencrypted volume. The intention is to thwart offline
decryption of an encrypted file system in an embedded system, where a
passphrase can't be supplied by an end user.

Employing TPM and TEE trusted keys with this is already possible with
dm-crypt, but I'd like this to be possible out-of-the-box with
ubifs + fscrypt as well.

> and update the relevant
> sections of Documentation/filesystems/fscrypt.rst to explain why someone would
> want to use this feature and what it accomplishes.

How about:

-  type "fscrypt-provisioning" whose payload is
+  type "fscrypt-provisioning" or "trusted":
+  "fscrypt-provisioning" keys have a payload of
   struct fscrypt_provisioning_key_payload whose ``raw`` field contains
   the raw key and whose ``type`` field matches ``key_spec.type``.
   Since ``raw`` is variable-length, the total size of this key's
   payload must be ``sizeof(struct fscrypt_provisioning_key_payload)``
-  plus the raw key size.  The process must have Search permission on
-  this key.
+  plus the raw key size.
+  For "trusted" keys, the payload is directly taken as the raw key.

+  The process must have Search permission on this key.

-  Most users should leave this 0 and specify the raw key directly.

+  Most users leave this 0 and specify the raw key directly.
-  The support for specifying a Linux keyring key is intended mainly to

-  allow re-adding keys after a filesystem is unmounted and re-mounted,
+  "trusted" keys are useful to leverage kernel support for sealing and
+  unsealing key material. Sealed keys can be persisted to unencrypted
+  storage and later used to decrypt the file system without requiring
+  userspace to know the raw key material.
+  "fscrypt-provisioning" key support is intended mainly to allow
+  re-adding keys after a filesystem is unmounted and re-mounted,

> As-is, this feature doesn't seem to have a very strong justification.  Please
> also see previous threads where this feature was discussed/requested:
> https://lkml.kernel.org/linux-fscrypt/20180110124418.24385-1-git@andred.net/T/#u,
> https://lkml.kernel.org/linux-fscrypt/20180118131359.8365-1-git@andred.net/T/#u,
> https://lkml.kernel.org/linux-fscrypt/20200116193228.GA266386@vader/T/#u

Thanks. I wasn't aware of the last one. I (re-)read them now. I hope
this mail manages to address the concerns.

(Also added original authors of these mail threads to CC)

> Note that there are several design flaws with the encrypted and trusted key
> types:
> 
> - By default, trusted keys are generated using the TPM's RNG rather than the
>   kernel's RNG, which places all trust in an unauditable black box.

Patch to fix that awaits feedback on linux-integrity[2].

> - trusted and encrypted keys aren't restricted to specific uses in the kernel
>   (like the fscrypt-provisioning key type is) but rather are general-purpose.
>   Hence, it may be possible to leak their contents to userspace by requesting
>   their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
>   using a weak cipher that is vulnerable to key recovery attacks.

The footgun is already there by allowing users to specify their own

raw key. Users can already use $keyid for dm-crypt and then do

  $ keyctl pipe $keyid | fscryptctl add_key /mnt

The responsibility to not reuse key material already lies with the users,
regardless if they handle the raw key material directly or indirectly via
a trusted key description/ID.

> - "encrypted" keys that use a master key of type "user" are supported, despite
>   these being easily obtainable in the clear by userspace providing their own
>   master key.  This violates one of the main design goals of "encrypted" keys.

I care for trusted keys foremost, so I've no problems dropping the encrypted
key support.

> Also, using the "trusted" key type isn't necessary to achieve TPM-bound
> encryption, as TPM binding can be handled in userspace instead.

Trusted keys support TEE and hopefully CAAM soon as well. I don't want my
userspace directly poking a DMA master.
> So I really would like to see a proper justification for this feature, and have
> it be properly documented.

In light of the extended justification above, do you want me to respin with
the proposed changes?

> One comment on the UAPI below.

> Why not just allow the key_id field to specify a "trusted" or "encrypted" key?
> Why is it necessary for FS_IOC_ADD_ENCRYPTION_KEY to support two different ways
> of looking up keyring keys -- by ID and by description?  Looking up by ID works
> fine for "fscrypt-provisioning" keys; why are "trusted" and "encrypted" keys
> different in this regard?

Mixture of reading emails predating key_id and misunderstanding the API.
key_id would be much cleaner indeed. I can change this for v2.

Thanks for your review.

[1]: https://lore.kernel.org/linux-integrity/655aab117f922320e2123815afb5bf3daeb7b8b3.1626885907.git-series.a.fatoum@pengutronix.de/
[2]: https://lore.kernel.org/linux-integrity/cover.9fc9298fd9d63553491871d043a18affc2dbc8a8.1626885907.git-series.a.fatoum@pengutronix.de/T/#meaefcdc9ac091944ddadaebe0410c2325af0032e

Cheers,
Ahmad

> 
> - Eric
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-28  8:50   ` Ahmad Fatoum
@ 2021-07-28 16:05     ` Eric Biggers
  2021-07-29  5:56       ` Sumit Garg
  0 siblings, 1 reply; 12+ messages in thread
From: Eric Biggers @ 2021-07-28 16:05 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Theodore Y. Ts'o, Jaegeuk Kim, Jarkko Sakkinen, James Morris,
	Serge E. Hallyn, James Bottomley, Mimi Zohar, Sumit Garg,
	David Howells, linux-fscrypt, linux-crypto, linux-integrity,
	linux-security-module, keyrings, linux-kernel, git,
	Omar Sandoval, Pengutronix Kernel Team

On Wed, Jul 28, 2021 at 10:50:42AM +0200, Ahmad Fatoum wrote:
> Hello Eric,
> 
> On 27.07.21 18:38, Eric Biggers wrote:
> > On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
> >> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
> >> material to the kernel after which it is never again disclosed to
> >> userspace.
> >>
> >> Use of encrypted and trusted keys offers stronger guarantees:
> >> The key material is generated within the kernel and is never disclosed to
> >> userspace in clear text and, in the case of trusted keys, can be
> >> directly rooted to a trust source like a TPM chip.
> > 
> > Please include a proper justification for this feature
> 
> I've patches pending for extending trusted keys to wrap the key sealing
> functionality of the CAAM IP on NXP SoCs[1]. I want the kernel to
> generate key material in the factory, have the CAAM encrypt it using its
> undisclosed unique key and pass it to userspace as encrypted blob that is
> persisted to an unencrypted volume. The intention is to thwart offline
> decryption of an encrypted file system in an embedded system, where a
> passphrase can't be supplied by an end user.
> 
> Employing TPM and TEE trusted keys with this is already possible with
> dm-crypt, but I'd like this to be possible out-of-the-box with
> ubifs + fscrypt as well.

Why not do the key management in userspace, like tpm-tools
(https://github.com/tpm2-software/tpm2-tools)?  There are a lot of uses for this
type of hardware besides in-kernel crypto.  See
https://wiki.archlinux.org/title/Trusted_Platform_Module for all the things you
can do with the TPM on Linux, including LUKS encryption; this is all with
userspace key management.  Wouldn't the CAAM hardware be useful for similar
purposes and thus need a similar design as well, e.g. with functionality exposed
through some /dev node for userspace to use?  Or are you saying it will only
ever be useful for in-kernel crypto?

> > Note that there are several design flaws with the encrypted and trusted key
> > types:
> > 
> > - By default, trusted keys are generated using the TPM's RNG rather than the
> >   kernel's RNG, which places all trust in an unauditable black box.
> 
> Patch to fix that awaits feedback on linux-integrity[2].

It does *not* fix it, as your patch only provides an option to use the kernel's
RNG whereas the default is still the TPM's RNG.

Most people don't change defaults.

Essentially your same argument was used for Dual_EC_DRBG; people argued it was
okay to standardize because people had the option to choose their own constants
if they felt the default constants were backdoored.  That didn't really matter,
though, since in practice everyone just used the default constants.

> 
> > - trusted and encrypted keys aren't restricted to specific uses in the kernel
> >   (like the fscrypt-provisioning key type is) but rather are general-purpose.
> >   Hence, it may be possible to leak their contents to userspace by requesting
> >   their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
> >   using a weak cipher that is vulnerable to key recovery attacks.
> 
> The footgun is already there by allowing users to specify their own
> 
> raw key. Users can already use $keyid for dm-crypt and then do
> 
>   $ keyctl pipe $keyid | fscryptctl add_key /mnt
> 
> The responsibility to not reuse key material already lies with the users,
> regardless if they handle the raw key material directly or indirectly via
> a trusted key description/ID.

Elsewhere you are claiming that "trusted" keys can never be disclosed to
userspace.  So you can't rely on userspace cooperating, right?

- Eric

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-27 14:43 [RFC PATCH v1] fscrypt: support encrypted and trusted keys Ahmad Fatoum
                   ` (2 preceding siblings ...)
  2021-07-27 18:39 ` kernel test robot
@ 2021-07-28 22:22 ` Jarkko Sakkinen
  2021-07-28 22:27   ` Ahmad Fatoum
  3 siblings, 1 reply; 12+ messages in thread
From: Jarkko Sakkinen @ 2021-07-28 22:22 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, James Morris,
	Serge E. Hallyn, James Bottomley, Mimi Zohar, Sumit Garg,
	David Howells, linux-fscrypt, linux-crypto, linux-integrity,
	linux-security-module, keyrings, linux-kernel

On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
> material to the kernel after which it is never again disclosed to
> userspace.
> 
> Use of encrypted and trusted keys offers stronger guarantees:
> The key material is generated within the kernel and is never disclosed to
> userspace in clear text and, in the case of trusted keys, can be
> directly rooted to a trust source like a TPM chip.
> 
> Add support for trusted and encrypted keys by repurposing
> fscrypt_add_key_arg::raw to hold the key description when the new
> FSCRYPT_KEY_ARG_TYPE_DESC flag is supplied. The location of the flag
> was previously reserved and enforced by ioctl code to be zero, so this
> change won't break backwards compatibility.
> 
> Corresponding userspace patches are available for fscryptctl:
> https://github.com/google/fscryptctl/pull/23
> 
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> key_extract_material used by this patch is added in
> <cover.b2fdd70b830d12853b12a12e32ceb0c8162c1346.1626945419.git-series.a.fatoum@pengutronix.de>
> which still awaits feedback.
> 
> Sending this RFC out anyway to get some feedback from the fscrypt
> developers whether this is the correct way to go about it.
> 
> To: "Theodore Y. Ts'o" <tytso@mit.edu>
> To: Jaegeuk Kim <jaegeuk@kernel.org>
> To: Eric Biggers <ebiggers@kernel.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: David Howells <dhowells@redhat.com>
> Cc: linux-fscrypt@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  Documentation/filesystems/fscrypt.rst | 24 ++++++++---
>  fs/crypto/keyring.c                   | 59 ++++++++++++++++++++++++---
>  include/uapi/linux/fscrypt.h          | 16 +++++++-
>  3 files changed, 87 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
> index 44b67ebd6e40..83738af2afa3 100644
> --- a/Documentation/filesystems/fscrypt.rst
> +++ b/Documentation/filesystems/fscrypt.rst
> @@ -681,11 +681,15 @@ It can be executed on any file or directory on the target filesystem,
>  but using the filesystem's root directory is recommended.  It takes in
>  a pointer to struct fscrypt_add_key_arg, defined as follows::
>  
> +    #define FSCRYPT_KEY_ADD_RAW_ASIS		0
> +    #define FSCRYPT_KEY_ADD_RAW_DESC		1

Would be nice to have these documented.

/Jarkko

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-28 22:22 ` Jarkko Sakkinen
@ 2021-07-28 22:27   ` Ahmad Fatoum
  0 siblings, 0 replies; 12+ messages in thread
From: Ahmad Fatoum @ 2021-07-28 22:27 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, James Morris,
	Serge E. Hallyn, James Bottomley, Mimi Zohar, Sumit Garg,
	David Howells, linux-fscrypt, linux-crypto, linux-integrity,
	linux-security-module, keyrings, linux-kernel

Hello Jarkko,

On 29.07.21 00:22, Jarkko Sakkinen wrote:
> On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
>> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
>> material to the kernel after which it is never again disclosed to
>> userspace.
>>
>> Use of encrypted and trusted keys offers stronger guarantees:
>> The key material is generated within the kernel and is never disclosed to
>> userspace in clear text and, in the case of trusted keys, can be
>> directly rooted to a trust source like a TPM chip.
>>
>> Add support for trusted and encrypted keys by repurposing
>> fscrypt_add_key_arg::raw to hold the key description when the new
>> FSCRYPT_KEY_ARG_TYPE_DESC flag is supplied. The location of the flag
>> was previously reserved and enforced by ioctl code to be zero, so this
>> change won't break backwards compatibility.
>>
>> Corresponding userspace patches are available for fscryptctl:
>> https://github.com/google/fscryptctl/pull/23
>>
>> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> ---
>> key_extract_material used by this patch is added in
>> <cover.b2fdd70b830d12853b12a12e32ceb0c8162c1346.1626945419.git-series.a.fatoum@pengutronix.de>
>> which still awaits feedback.
>>
>> Sending this RFC out anyway to get some feedback from the fscrypt
>> developers whether this is the correct way to go about it.
>>
>> To: "Theodore Y. Ts'o" <tytso@mit.edu>
>> To: Jaegeuk Kim <jaegeuk@kernel.org>
>> To: Eric Biggers <ebiggers@kernel.org>
>> Cc: Jarkko Sakkinen <jarkko@kernel.org>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: "Serge E. Hallyn" <serge@hallyn.com>
>> Cc: James Bottomley <jejb@linux.ibm.com>
>> Cc: Mimi Zohar <zohar@linux.ibm.com>
>> Cc: Sumit Garg <sumit.garg@linaro.org>
>> Cc: David Howells <dhowells@redhat.com>
>> Cc: linux-fscrypt@vger.kernel.org
>> Cc: linux-crypto@vger.kernel.org
>> Cc: linux-integrity@vger.kernel.org
>> Cc: linux-security-module@vger.kernel.org
>> Cc: keyrings@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  Documentation/filesystems/fscrypt.rst | 24 ++++++++---
>>  fs/crypto/keyring.c                   | 59 ++++++++++++++++++++++++---
>>  include/uapi/linux/fscrypt.h          | 16 +++++++-
>>  3 files changed, 87 insertions(+), 12 deletions(-)
>>
>> diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
>> index 44b67ebd6e40..83738af2afa3 100644
>> --- a/Documentation/filesystems/fscrypt.rst
>> +++ b/Documentation/filesystems/fscrypt.rst
>> @@ -681,11 +681,15 @@ It can be executed on any file or directory on the target filesystem,
>>  but using the filesystem's root directory is recommended.  It takes in
>>  a pointer to struct fscrypt_add_key_arg, defined as follows::
>>  
>> +    #define FSCRYPT_KEY_ADD_RAW_ASIS		0
>> +    #define FSCRYPT_KEY_ADD_RAW_DESC		1
> 
> Would be nice to have these documented.

They have explanatory comments in the uAPI header. The Documentation file
purposefully omits these comments and describes each field separately after
the code block. I am just following suit.

FWIW, I intend to drop these flags for v2 anyway.

Cheers,
Ahmad

> 
> /Jarkko
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-28 16:05     ` Eric Biggers
@ 2021-07-29  5:56       ` Sumit Garg
  2021-07-29  9:07         ` Ahmad Fatoum
  0 siblings, 1 reply; 12+ messages in thread
From: Sumit Garg @ 2021-07-29  5:56 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Ahmad Fatoum, Theodore Y. Ts'o, Jaegeuk Kim, Jarkko Sakkinen,
	James Morris, Serge E. Hallyn, James Bottomley, Mimi Zohar,
	David Howells, linux-fscrypt,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	open list:SECURITY SUBSYSTEM, open list:ASYMMETRIC KEYS,
	Linux Kernel Mailing List, git, Omar Sandoval,
	Pengutronix Kernel Team

Hi Eric,

On Wed, 28 Jul 2021 at 21:35, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Wed, Jul 28, 2021 at 10:50:42AM +0200, Ahmad Fatoum wrote:
> > Hello Eric,
> >
> > On 27.07.21 18:38, Eric Biggers wrote:
> > > On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
> > >> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
> > >> material to the kernel after which it is never again disclosed to
> > >> userspace.
> > >>
> > >> Use of encrypted and trusted keys offers stronger guarantees:
> > >> The key material is generated within the kernel and is never disclosed to
> > >> userspace in clear text and, in the case of trusted keys, can be
> > >> directly rooted to a trust source like a TPM chip.
> > >
> > > Please include a proper justification for this feature
> >
> > I've patches pending for extending trusted keys to wrap the key sealing
> > functionality of the CAAM IP on NXP SoCs[1]. I want the kernel to
> > generate key material in the factory, have the CAAM encrypt it using its
> > undisclosed unique key and pass it to userspace as encrypted blob that is
> > persisted to an unencrypted volume. The intention is to thwart offline
> > decryption of an encrypted file system in an embedded system, where a
> > passphrase can't be supplied by an end user.
> >
> > Employing TPM and TEE trusted keys with this is already possible with
> > dm-crypt, but I'd like this to be possible out-of-the-box with
> > ubifs + fscrypt as well.
>
> Why not do the key management in userspace, like tpm-tools
> (https://github.com/tpm2-software/tpm2-tools)?  There are a lot of uses for this
> type of hardware besides in-kernel crypto.  See
> https://wiki.archlinux.org/title/Trusted_Platform_Module for all the things you
> can do with the TPM on Linux, including LUKS encryption; this is all with
> userspace key management.  Wouldn't the CAAM hardware be useful for similar
> purposes and thus need a similar design as well, e.g. with functionality exposed
> through some /dev node for userspace to use?  Or are you saying it will only
> ever be useful for in-kernel crypto?

AFAIK from my prior experience while working with CAAM engine during
my time at NXP, it is generally a crypto engine with additional
security properties like one discussed here to protect keys (blob
encap and decap) etc. But it doesn't offer user authentication similar
to what a TPM (ownership) can offer. Although, one should be able to
expose CAAM via /dev node but I am not sure if that would be really
useful without user authentication. I think similar should be the case
for other crypto engines with additional security properties.

With restriction of CAAM's security properties to kernel crypto we
could at least ensure a kernel boundary that should offer enough
resistance from malicious user space attacks.

>
> > > Note that there are several design flaws with the encrypted and trusted key
> > > types:
> > >
> > > - By default, trusted keys are generated using the TPM's RNG rather than the
> > >   kernel's RNG, which places all trust in an unauditable black box.
> >

With regards to trusted keys generated using the TEE's RNG, the
underlying implementation being OP-TEE [1] which is an open source TEE
implementation built on top of Arm TrustZone providing the hardware
based isolation among the TEE and Linux. So regarding auditability, it
should be comparatively easier to audit the TEE components designed
with a goal of minimal footprint when compared with Linux kernel.

[1] https://github.com/OP-TEE/optee_os

> > Patch to fix that awaits feedback on linux-integrity[2].
>
> It does *not* fix it, as your patch only provides an option to use the kernel's
> RNG whereas the default is still the TPM's RNG.
>

Yes in case of TPM, default is still TPM's RNG but with Ahmad's patch
#2, the trust source backend like CAAM should be able to use kernel's
RNG by default.

-Sumit

> Most people don't change defaults.
>
> Essentially your same argument was used for Dual_EC_DRBG; people argued it was
> okay to standardize because people had the option to choose their own constants
> if they felt the default constants were backdoored.  That didn't really matter,
> though, since in practice everyone just used the default constants.
>
> >
> > > - trusted and encrypted keys aren't restricted to specific uses in the kernel
> > >   (like the fscrypt-provisioning key type is) but rather are general-purpose.
> > >   Hence, it may be possible to leak their contents to userspace by requesting
> > >   their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
> > >   using a weak cipher that is vulnerable to key recovery attacks.
> >
> > The footgun is already there by allowing users to specify their own
> >
> > raw key. Users can already use $keyid for dm-crypt and then do
> >
> >   $ keyctl pipe $keyid | fscryptctl add_key /mnt
> >
> > The responsibility to not reuse key material already lies with the users,
> > regardless if they handle the raw key material directly or indirectly via
> > a trusted key description/ID.
>
> Elsewhere you are claiming that "trusted" keys can never be disclosed to
> userspace.  So you can't rely on userspace cooperating, right?
>
> - Eric

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-29  5:56       ` Sumit Garg
@ 2021-07-29  9:07         ` Ahmad Fatoum
  2021-07-29 18:28           ` Eric Biggers
  0 siblings, 1 reply; 12+ messages in thread
From: Ahmad Fatoum @ 2021-07-29  9:07 UTC (permalink / raw)
  To: Sumit Garg, Eric Biggers
  Cc: Theodore Y. Ts'o, Jaegeuk Kim, Jarkko Sakkinen, James Morris,
	Serge E. Hallyn, James Bottomley, Mimi Zohar, David Howells,
	linux-fscrypt, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	linux-integrity, open list:SECURITY SUBSYSTEM,
	open list:ASYMMETRIC KEYS, Linux Kernel Mailing List, git,
	Omar Sandoval, Pengutronix Kernel Team

On 29.07.21 07:56, Sumit Garg wrote:
> Hi Eric,
> 
> On Wed, 28 Jul 2021 at 21:35, Eric Biggers <ebiggers@kernel.org> wrote:
>>
>> On Wed, Jul 28, 2021 at 10:50:42AM +0200, Ahmad Fatoum wrote:
>>> Hello Eric,
>>>
>>> On 27.07.21 18:38, Eric Biggers wrote:
>>>> On Tue, Jul 27, 2021 at 04:43:49PM +0200, Ahmad Fatoum wrote:
>>>>> For both v1 and v2 key setup mechanisms, userspace supplies the raw key
>>>>> material to the kernel after which it is never again disclosed to
>>>>> userspace.
>>>>>
>>>>> Use of encrypted and trusted keys offers stronger guarantees:
>>>>> The key material is generated within the kernel and is never disclosed to
>>>>> userspace in clear text and, in the case of trusted keys, can be
>>>>> directly rooted to a trust source like a TPM chip.
>>>>
>>>> Please include a proper justification for this feature
>>>
>>> I've patches pending for extending trusted keys to wrap the key sealing
>>> functionality of the CAAM IP on NXP SoCs[1]. I want the kernel to
>>> generate key material in the factory, have the CAAM encrypt it using its
>>> undisclosed unique key and pass it to userspace as encrypted blob that is
>>> persisted to an unencrypted volume. The intention is to thwart offline
>>> decryption of an encrypted file system in an embedded system, where a
>>> passphrase can't be supplied by an end user.
>>>
>>> Employing TPM and TEE trusted keys with this is already possible with
>>> dm-crypt, but I'd like this to be possible out-of-the-box with
>>> ubifs + fscrypt as well.
>>
>> Why not do the key management in userspace, like tpm-tools
>> (https://github.com/tpm2-software/tpm2-tools)?  There are a lot of uses for this
>> type of hardware besides in-kernel crypto.  See
>> https://wiki.archlinux.org/title/Trusted_Platform_Module for all the things you
>> can do with the TPM on Linux, including LUKS encryption; this is all with
>> userspace key management.  Wouldn't the CAAM hardware be useful for similar
>> purposes and thus need a similar design as well, e.g. with functionality exposed
>> through some /dev node for userspace to use?  Or are you saying it will only
>> ever be useful for in-kernel crypto?
> 
> AFAIK from my prior experience while working with CAAM engine during
> my time at NXP, it is generally a crypto engine with additional
> security properties like one discussed here to protect keys (blob
> encap and decap) etc. But it doesn't offer user authentication similar
> to what a TPM (ownership) can offer. Although, one should be able to
> expose CAAM via /dev node but I am not sure if that would be really
> useful without user authentication. I think similar should be the case
> for other crypto engines with additional security properties.
> 
> With restriction of CAAM's security properties to kernel crypto we
> could at least ensure a kernel boundary that should offer enough
> resistance from malicious user space attacks.

Which are a real possibility given the CAAM's direct memory access.
We now have safe interfaces mainline wrapping it for HWRNG, crypto
acceleration and hopefully soon key sealing and I don't think throwing
existing kernel driver support away and inventing a new CAAM uAPI is a
practical alternative.

>>>> Note that there are several design flaws with the encrypted and trusted key
>>>> types:
>>>>
>>>> - By default, trusted keys are generated using the TPM's RNG rather than the
>>>>   kernel's RNG, which places all trust in an unauditable black box.
>>>
> 
> With regards to trusted keys generated using the TEE's RNG, the
> underlying implementation being OP-TEE [1] which is an open source TEE
> implementation built on top of Arm TrustZone providing the hardware
> based isolation among the TEE and Linux. So regarding auditability, it
> should be comparatively easier to audit the TEE components designed
> with a goal of minimal footprint when compared with Linux kernel.
> 
> [1] https://github.com/OP-TEE/optee_os
> 
>>> Patch to fix that awaits feedback on linux-integrity[2].
>>
>> It does *not* fix it, as your patch only provides an option to use the kernel's
>> RNG whereas the default is still the TPM's RNG.
>>
> 
> Yes in case of TPM, default is still TPM's RNG but with Ahmad's patch
> #2, the trust source backend like CAAM should be able to use kernel's
> RNG by default.

Exactly.

>> Most people don't change defaults.
>>
>> Essentially your same argument was used for Dual_EC_DRBG; people argued it was
>> okay to standardize because people had the option to choose their own constants
>> if they felt the default constants were backdoored.  That didn't really matter,
>> though, since in practice everyone just used the default constants.

I'd appreciate your feedback on my CAAM series if you think the defaults
can be improved. Trusted keys are no longer restricted to TPMs,
so users of other backends shouldn't be dismissed, because one backend
can be used with fscrypt by alternative means.
>>>> - trusted and encrypted keys aren't restricted to specific uses in the kernel
>>>>   (like the fscrypt-provisioning key type is) but rather are general-purpose.
>>>>   Hence, it may be possible to leak their contents to userspace by requesting
>>>>   their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
>>>>   using a weak cipher that is vulnerable to key recovery attacks.
>>>
>>> The footgun is already there by allowing users to specify their own
>>>
>>> raw key. Users can already use $keyid for dm-crypt and then do
>>>
>>>   $ keyctl pipe $keyid | fscryptctl add_key /mnt
>>>
>>> The responsibility to not reuse key material already lies with the users,
>>> regardless if they handle the raw key material directly or indirectly via
>>> a trusted key description/ID.
>>
>> Elsewhere you are claiming that "trusted" keys can never be disclosed to
>> userspace.  So you can't rely on userspace cooperating, right?

The users I meant are humans, e.g. system integrators. They need to think about

burning fuses, signing bootloaders, verifying kernel and root file systems,

encrypting file systems and safekeeping their crypto keys. Ample opportunity for

stuff to go wrong. They would benefit from having relevant kernel functionality

integrate with each other instead of having to carry downstream patches, which
we and many others[1] did for years. We now finally have a chance to drop this
technical debt thanks to Sumit's trusted key rework and improve user security
along the way.

So, Eric, how should we proceed?

[1]: See the CAAM series cover letter for a history of CAAM sealing upstreaming
     efforts

Cheers,
Ahmad

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
  2021-07-29  9:07         ` Ahmad Fatoum
@ 2021-07-29 18:28           ` Eric Biggers
  0 siblings, 0 replies; 12+ messages in thread
From: Eric Biggers @ 2021-07-29 18:28 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Sumit Garg, Theodore Y. Ts'o, Jaegeuk Kim, Jarkko Sakkinen,
	James Morris, Serge E. Hallyn, James Bottomley, Mimi Zohar,
	David Howells, linux-fscrypt,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	open list:SECURITY SUBSYSTEM, open list:ASYMMETRIC KEYS,
	Linux Kernel Mailing List, git, Omar Sandoval,
	Pengutronix Kernel Team

On Thu, Jul 29, 2021 at 11:07:00AM +0200, Ahmad Fatoum wrote:
> >> Most people don't change defaults.
> >>
> >> Essentially your same argument was used for Dual_EC_DRBG; people argued it was
> >> okay to standardize because people had the option to choose their own constants
> >> if they felt the default constants were backdoored.  That didn't really matter,
> >> though, since in practice everyone just used the default constants.
> 
> I'd appreciate your feedback on my CAAM series if you think the defaults
> can be improved. Trusted keys are no longer restricted to TPMs,
> so users of other backends shouldn't be dismissed, because one backend
> can be used with fscrypt by alternative means.

I already gave feedback:
https://lkml.kernel.org/keyrings/YGOcZtkw3ZM5kvl6@gmail.com
https://lkml.kernel.org/keyrings/YGUHBelwhvJDhKoo@gmail.com
https://lkml.kernel.org/keyrings/YGViOc3DG+Pjuur6@sol.localdomain

> >>>> - trusted and encrypted keys aren't restricted to specific uses in the kernel
> >>>>   (like the fscrypt-provisioning key type is) but rather are general-purpose.
> >>>>   Hence, it may be possible to leak their contents to userspace by requesting
> >>>>   their use for certain algorithms/features, e.g. to encrypt a dm-crypt target
> >>>>   using a weak cipher that is vulnerable to key recovery attacks.
> >>>
> >>> The footgun is already there by allowing users to specify their own
> >>>
> >>> raw key. Users can already use $keyid for dm-crypt and then do
> >>>
> >>>   $ keyctl pipe $keyid | fscryptctl add_key /mnt
> >>>
> >>> The responsibility to not reuse key material already lies with the users,
> >>> regardless if they handle the raw key material directly or indirectly via
> >>> a trusted key description/ID.
> >>
> >> Elsewhere you are claiming that "trusted" keys can never be disclosed to
> >> userspace.  So you can't rely on userspace cooperating, right?
> 
> The users I meant are humans, e.g. system integrators. They need to think about
> 
> burning fuses, signing bootloaders, verifying kernel and root file systems,
> 
> encrypting file systems and safekeeping their crypto keys. Ample opportunity for
> 
> stuff to go wrong. They would benefit from having relevant kernel functionality
> 
> integrate with each other instead of having to carry downstream patches, which
> we and many others[1] did for years. We now finally have a chance to drop this
> technical debt thanks to Sumit's trusted key rework and improve user security
> along the way.
> 
> So, Eric, how should we proceed?
> 

It is probably inevitable that this be added, but you need to document it
properly and not make misleading claims like "The key material is generated
within the kernel" (for the TPM "trust" source the default is to use the TPM's
RNG, *not* the kernel RNG), and "is never disclosed to userspace in clear text"
(that's only guaranteed to be true for non-malicious userspace).  Also please
properly document that this is mainly intended for accessing key wrapping
hardware such as CAAM that can't be accessed from userspace in another way like
TPMs can.

- Eric

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

* Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys
@ 2021-07-27 16:56 kernel test robot
  0 siblings, 0 replies; 12+ messages in thread
From: kernel test robot @ 2021-07-27 16:56 UTC (permalink / raw)
  To: kbuild

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

CC: kbuild-all(a)lists.01.org
In-Reply-To: <20210727144349.11215-1-a.fatoum@pengutronix.de>
References: <20210727144349.11215-1-a.fatoum@pengutronix.de>
TO: Ahmad Fatoum <a.fatoum@pengutronix.de>

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
:::::: branch date: 2 hours ago
:::::: commit date: 2 hours ago
compiler: gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
reproduce:
cd tools/perf && ./check-headers.sh

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


perfheadercheck warnings: (new ones prefixed by >>)
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  122> /*
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  123>  * fscrypt_add_key_arg::raw contains the raw key material directly
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  124>  * if key_id == 0
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  125>  */
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  126> #define FSCRYPT_KEY_ADD_RAW_ASIS		0
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  127> 
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  128> /*
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  129>  * fscrypt_add_key_arg::raw is a key descriptor for an already
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  130>  * existing kernel encrypted or trusted key if key_id == 0.
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  131>  * The kernel key's material will be used as input for fscrypt.
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  132>  */
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  133> #define FSCRYPT_KEY_ADD_RAW_DESC		1
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  134> 
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  127< 	__u32 __reserved[8];
>> Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  140> 	__u32 raw_flags;	/* one of FSCRYPT_KEY_ADD_RAW_* */
   Warning: Kernel ABI header at 'tools/include/uapi/linux/fscrypt.h' differs from latest version at 'include/uapi/linux/fscrypt.h':  141> 	__u32 __reserved[7];

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

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

end of thread, other threads:[~2021-07-29 18:28 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2021-07-28 22:22 ` Jarkko Sakkinen
2021-07-28 22:27   ` Ahmad Fatoum
2021-07-27 16:56 kernel test robot

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.