From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-crypto@vger.kernel.org, keyrings@vger.kernel.org,
linux-api@vger.kernel.org, Satya Tangirala <satyat@google.com>,
Paul Crowley <paulcrowley@google.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v8 13/20] fscrypt: v2 encryption policy support
Date: Mon, 12 Aug 2019 20:39:37 -0400 [thread overview]
Message-ID: <20190813003937.GK28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-14-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:14AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt policy version, "v2". It has the following changes
> from the original policy version, which we call "v1" (*):
>
> - Master keys (the user-provided encryption keys) are only ever used as
> input to HKDF-SHA512. This is more flexible and less error-prone, and
> it avoids the quirks and limitations of the AES-128-ECB based KDF.
> Three classes of cryptographically isolated subkeys are defined:
>
> - Per-file keys, like used in v1 policies except for the new KDF.
>
> - Per-mode keys. These implement the semantics of the DIRECT_KEY
> flag, which for v1 policies made the master key be used directly.
> These are also planned to be used for inline encryption when
> support for it is added.
>
> - Key identifiers (see below).
>
> - Each master key is identified by a 16-byte master_key_identifier,
> which is derived from the key itself using HKDF-SHA512. This prevents
> users from associating the wrong key with an encrypted file or
> directory. This was easily possible with v1 policies, which
> identified the key by an arbitrary 8-byte master_key_descriptor.
>
> - The key must be provided in the filesystem-level keyring, not in a
> process-subscribed keyring.
>
> The following UAPI additions are made:
>
> - The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
> fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
> from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
>
> - A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
> getting the v1 or v2 encryption policy of an encrypted file or
> directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
> be used because it did not have a way for userspace to indicate which
> policy structure is expected. The new ioctl includes a size field, so
> it is extensible to future fscrypt policy versions.
>
> - The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
> and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
> encryption policies. Such keys are kept logically separate from keys
> for v1 encryption policies, and are identified by 'identifier' rather
> than by 'descriptor'. The 'identifier' need not be provided when
> adding a key, since the kernel will calculate it anyway.
>
> This patch temporarily keeps adding/removing v2 policy keys behind the
> same permission check done for adding/removing v1 policy keys:
> capable(CAP_SYS_ADMIN). However, the next patch will carefully take
> advantage of the cryptographically secure master_key_identifier to allow
> non-root users to add/remove v2 policy keys, thus providing a full
> replacement for v1 policies.
>
> (*) Actually, in the API fscrypt_policy::version is 0 while on-disk
> fscrypt_context::format is 1. But I believe it makes the most sense
> to advance both to '2' to have them be in sync, and to consider the
> numbering to start at 1 except for the API quirk.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 13/20] fscrypt: v2 encryption policy support
Date: Tue, 13 Aug 2019 00:39:37 +0000 [thread overview]
Message-ID: <20190813003937.GK28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-14-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:14AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt policy version, "v2". It has the following changes
> from the original policy version, which we call "v1" (*):
>
> - Master keys (the user-provided encryption keys) are only ever used as
> input to HKDF-SHA512. This is more flexible and less error-prone, and
> it avoids the quirks and limitations of the AES-128-ECB based KDF.
> Three classes of cryptographically isolated subkeys are defined:
>
> - Per-file keys, like used in v1 policies except for the new KDF.
>
> - Per-mode keys. These implement the semantics of the DIRECT_KEY
> flag, which for v1 policies made the master key be used directly.
> These are also planned to be used for inline encryption when
> support for it is added.
>
> - Key identifiers (see below).
>
> - Each master key is identified by a 16-byte master_key_identifier,
> which is derived from the key itself using HKDF-SHA512. This prevents
> users from associating the wrong key with an encrypted file or
> directory. This was easily possible with v1 policies, which
> identified the key by an arbitrary 8-byte master_key_descriptor.
>
> - The key must be provided in the filesystem-level keyring, not in a
> process-subscribed keyring.
>
> The following UAPI additions are made:
>
> - The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
> fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
> from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
>
> - A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
> getting the v1 or v2 encryption policy of an encrypted file or
> directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
> be used because it did not have a way for userspace to indicate which
> policy structure is expected. The new ioctl includes a size field, so
> it is extensible to future fscrypt policy versions.
>
> - The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
> and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
> encryption policies. Such keys are kept logically separate from keys
> for v1 encryption policies, and are identified by 'identifier' rather
> than by 'descriptor'. The 'identifier' need not be provided when
> adding a key, since the kernel will calculate it anyway.
>
> This patch temporarily keeps adding/removing v2 policy keys behind the
> same permission check done for adding/removing v1 policy keys:
> capable(CAP_SYS_ADMIN). However, the next patch will carefully take
> advantage of the cryptographically secure master_key_identifier to allow
> non-root users to add/remove v2 policy keys, thus providing a full
> replacement for v1 policies.
>
> (*) Actually, in the API fscrypt_policy::version is 0 while on-disk
> fscrypt_context::format is 1. But I believe it makes the most sense
> to advance both to '2' to have them be in sync, and to consider the
> numbering to start at 1 except for the API quirk.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 13/20] fscrypt: v2 encryption policy support
Date: Mon, 12 Aug 2019 20:39:37 -0400 [thread overview]
Message-ID: <20190813003937.GK28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-14-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:14AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt policy version, "v2". It has the following changes
> from the original policy version, which we call "v1" (*):
>
> - Master keys (the user-provided encryption keys) are only ever used as
> input to HKDF-SHA512. This is more flexible and less error-prone, and
> it avoids the quirks and limitations of the AES-128-ECB based KDF.
> Three classes of cryptographically isolated subkeys are defined:
>
> - Per-file keys, like used in v1 policies except for the new KDF.
>
> - Per-mode keys. These implement the semantics of the DIRECT_KEY
> flag, which for v1 policies made the master key be used directly.
> These are also planned to be used for inline encryption when
> support for it is added.
>
> - Key identifiers (see below).
>
> - Each master key is identified by a 16-byte master_key_identifier,
> which is derived from the key itself using HKDF-SHA512. This prevents
> users from associating the wrong key with an encrypted file or
> directory. This was easily possible with v1 policies, which
> identified the key by an arbitrary 8-byte master_key_descriptor.
>
> - The key must be provided in the filesystem-level keyring, not in a
> process-subscribed keyring.
>
> The following UAPI additions are made:
>
> - The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
> fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
> from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
>
> - A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
> getting the v1 or v2 encryption policy of an encrypted file or
> directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
> be used because it did not have a way for userspace to indicate which
> policy structure is expected. The new ioctl includes a size field, so
> it is extensible to future fscrypt policy versions.
>
> - The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
> and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
> encryption policies. Such keys are kept logically separate from keys
> for v1 encryption policies, and are identified by 'identifier' rather
> than by 'descriptor'. The 'identifier' need not be provided when
> adding a key, since the kernel will calculate it anyway.
>
> This patch temporarily keeps adding/removing v2 policy keys behind the
> same permission check done for adding/removing v1 policy keys:
> capable(CAP_SYS_ADMIN). However, the next patch will carefully take
> advantage of the cryptographically secure master_key_identifier to allow
> non-root users to add/remove v2 policy keys, thus providing a full
> replacement for v1 policies.
>
> (*) Actually, in the API fscrypt_policy::version is 0 while on-disk
> fscrypt_context::format is 1. But I believe it makes the most sense
> to advance both to '2' to have them be in sync, and to consider the
> numbering to start at 1 except for the API quirk.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [f2fs-dev] [PATCH v8 13/20] fscrypt: v2 encryption policy support
Date: Mon, 12 Aug 2019 20:39:37 -0400 [thread overview]
Message-ID: <20190813003937.GK28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-14-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:14AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt policy version, "v2". It has the following changes
> from the original policy version, which we call "v1" (*):
>
> - Master keys (the user-provided encryption keys) are only ever used as
> input to HKDF-SHA512. This is more flexible and less error-prone, and
> it avoids the quirks and limitations of the AES-128-ECB based KDF.
> Three classes of cryptographically isolated subkeys are defined:
>
> - Per-file keys, like used in v1 policies except for the new KDF.
>
> - Per-mode keys. These implement the semantics of the DIRECT_KEY
> flag, which for v1 policies made the master key be used directly.
> These are also planned to be used for inline encryption when
> support for it is added.
>
> - Key identifiers (see below).
>
> - Each master key is identified by a 16-byte master_key_identifier,
> which is derived from the key itself using HKDF-SHA512. This prevents
> users from associating the wrong key with an encrypted file or
> directory. This was easily possible with v1 policies, which
> identified the key by an arbitrary 8-byte master_key_descriptor.
>
> - The key must be provided in the filesystem-level keyring, not in a
> process-subscribed keyring.
>
> The following UAPI additions are made:
>
> - The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
> fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
> from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
>
> - A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
> getting the v1 or v2 encryption policy of an encrypted file or
> directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
> be used because it did not have a way for userspace to indicate which
> policy structure is expected. The new ioctl includes a size field, so
> it is extensible to future fscrypt policy versions.
>
> - The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
> and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
> encryption policies. Such keys are kept logically separate from keys
> for v1 encryption policies, and are identified by 'identifier' rather
> than by 'descriptor'. The 'identifier' need not be provided when
> adding a key, since the kernel will calculate it anyway.
>
> This patch temporarily keeps adding/removing v2 policy keys behind the
> same permission check done for adding/removing v1 policy keys:
> capable(CAP_SYS_ADMIN). However, the next patch will carefully take
> advantage of the cryptographically secure master_key_identifier to allow
> non-root users to add/remove v2 policy keys, thus providing a full
> replacement for v1 policies.
>
> (*) Actually, in the API fscrypt_policy::version is 0 while on-disk
> fscrypt_context::format is 1. But I believe it makes the most sense
> to advance both to '2' to have them be in sync, and to consider the
> numbering to start at 1 except for the API quirk.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 13/20] fscrypt: v2 encryption policy support
Date: Mon, 12 Aug 2019 20:39:37 -0400 [thread overview]
Message-ID: <20190813003937.GK28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-14-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:14AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Add a new fscrypt policy version, "v2". It has the following changes
> from the original policy version, which we call "v1" (*):
>
> - Master keys (the user-provided encryption keys) are only ever used as
> input to HKDF-SHA512. This is more flexible and less error-prone, and
> it avoids the quirks and limitations of the AES-128-ECB based KDF.
> Three classes of cryptographically isolated subkeys are defined:
>
> - Per-file keys, like used in v1 policies except for the new KDF.
>
> - Per-mode keys. These implement the semantics of the DIRECT_KEY
> flag, which for v1 policies made the master key be used directly.
> These are also planned to be used for inline encryption when
> support for it is added.
>
> - Key identifiers (see below).
>
> - Each master key is identified by a 16-byte master_key_identifier,
> which is derived from the key itself using HKDF-SHA512. This prevents
> users from associating the wrong key with an encrypted file or
> directory. This was easily possible with v1 policies, which
> identified the key by an arbitrary 8-byte master_key_descriptor.
>
> - The key must be provided in the filesystem-level keyring, not in a
> process-subscribed keyring.
>
> The following UAPI additions are made:
>
> - The existing ioctl FS_IOC_SET_ENCRYPTION_POLICY can now be passed a
> fscrypt_policy_v2 to set a v2 encryption policy. It's disambiguated
> from fscrypt_policy/fscrypt_policy_v1 by the version code prefix.
>
> - A new ioctl FS_IOC_GET_ENCRYPTION_POLICY_EX is added. It allows
> getting the v1 or v2 encryption policy of an encrypted file or
> directory. The existing FS_IOC_GET_ENCRYPTION_POLICY ioctl could not
> be used because it did not have a way for userspace to indicate which
> policy structure is expected. The new ioctl includes a size field, so
> it is extensible to future fscrypt policy versions.
>
> - The ioctls FS_IOC_ADD_ENCRYPTION_KEY, FS_IOC_REMOVE_ENCRYPTION_KEY,
> and FS_IOC_GET_ENCRYPTION_KEY_STATUS now support managing keys for v2
> encryption policies. Such keys are kept logically separate from keys
> for v1 encryption policies, and are identified by 'identifier' rather
> than by 'descriptor'. The 'identifier' need not be provided when
> adding a key, since the kernel will calculate it anyway.
>
> This patch temporarily keeps adding/removing v2 policy keys behind the
> same permission check done for adding/removing v1 policy keys:
> capable(CAP_SYS_ADMIN). However, the next patch will carefully take
> advantage of the cryptographically secure master_key_identifier to allow
> non-root users to add/remove v2 policy keys, thus providing a full
> replacement for v1 policies.
>
> (*) Actually, in the API fscrypt_policy::version is 0 while on-disk
> fscrypt_context::format is 1. But I believe it makes the most sense
> to advance both to '2' to have them be in sync, and to consider the
> numbering to start at 1 except for the API quirk.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good, feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-08-13 0:39 UTC|newest]
Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 16:25 [PATCH v8 00/20] fscrypt: key management improvements Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 01/20] fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 02/20] fscrypt: use FSCRYPT_ prefix for uapi constants Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 03/20] fscrypt: use FSCRYPT_* definitions, not FS_* Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 04/20] fscrypt: add ->ci_inode to fscrypt_info Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 05/20] fscrypt: rename fscrypt_master_key to fscrypt_direct_key Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-12 22:20 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 06/20] fscrypt: refactor key setup code in preparation for v2 policies Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-12 22:38 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 07/20] fscrypt: move v1 policy key setup to keysetup_v1.c Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 08/20] fscrypt: rename keyinfo.c to keysetup.c Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 09/20] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-13 0:06 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 11/20] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 12/20] fscrypt: add an HKDF-SHA512 implementation Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-06 20:43 ` Paul Crowley
2019-08-06 20:43 ` Paul Crowley
2019-08-06 20:43 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-08-06 20:43 ` Paul Crowley via Linux-f2fs-devel
2019-08-06 20:43 ` Paul Crowley
2019-08-05 16:25 ` [PATCH v8 13/20] fscrypt: v2 encryption policy support Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-06 20:44 ` Paul Crowley
2019-08-06 20:44 ` Paul Crowley
2019-08-06 20:44 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-08-06 20:44 ` Paul Crowley via Linux-f2fs-devel
2019-08-06 20:44 ` Paul Crowley
2019-08-13 0:39 ` Theodore Y. Ts'o [this message]
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 15/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-13 0:15 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 16/20] fscrypt: require that key be added when setting a v2 encryption policy Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 17/20] ext4: wire up new fscrypt ioctls Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 18/20] f2fs: " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 19/20] ubifs: " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [PATCH v8 20/20] fscrypt: document the new ioctls and policy version Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-14 22:37 ` [PATCH v8 00/20] fscrypt: key management improvements Eric Biggers
2019-08-14 22:37 ` [f2fs-dev] " Eric Biggers
2019-08-14 22:37 ` Eric Biggers
2019-08-14 22:37 ` Eric Biggers
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=20190813003937.GK28705@mit.edu \
--to=tytso@mit.edu \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paulcrowley@google.com \
--cc=satyat@google.com \
/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.