* [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies
@ 2019-10-24 21:54 Eric Biggers
2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers
` (4 more replies)
0 siblings, 5 replies; 12+ messages in thread
From: Eric Biggers @ 2019-10-24 21:54 UTC (permalink / raw)
To: linux-fscrypt
Cc: linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala,
Paul Crowley, Paul Lawrence, Theodore Y . Ts'o, Jaegeuk Kim
Hello,
In preparation for adding inline encryption support to fscrypt, this
patchset adds a new fscrypt policy flag which modifies the encryption to
be optimized for inline encryption hardware compliant with the UFS v2.1
standard or the upcoming version of the eMMC standard.
This means using per-mode keys instead of per-file keys, and in
compensation including the inode number in the IVs. For ext4, this
precludes filesystem shrinking, so I've also added a compat feature
which will prevent the filesystem from being shrunk.
I've separated this from the full "Inline Encryption Support" patchset
(https://lkml.kernel.org/linux-fsdevel/20190821075714.65140-1-satyat@google.com/)
to avoid conflating an implementation (inline encryption) with a new
on-disk format (IV_INO_LBLK_64). This patchset purely adds support for
IV_INO_LBLK_64 policies to fscrypt, but implements them using the
existing filesystem layer crypto.
We're planning to make the *implementation* (filesystem layer or inline
crypto) be controlled by a mount option '-o inlinecrypt'.
This patchset applies to fscrypt.git#master and can also be retrieved from
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=inline-crypt-optimized-v2
I've written a ciphertext verification test for this new type of policy:
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/xfstests-dev.git/log/?h=inline-encryption
Work-in-progress patches for the inline encryption implementation of
both IV_INO_LBLK_64 and regular policies can be found at
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=inline-encryption-wip
Changes v1 => v2:
- Rename the flag from INLINE_CRYPT_OPTIMIZED to IV_INO_LBLK_64.
- Use the same key derivation and IV generation scheme for filenames
encryption too.
- Improve the documentation and commit messages.
Eric Biggers (3):
fscrypt: add support for IV_INO_LBLK_64 policies
ext4: add support for IV_INO_LBLK_64 encryption policies
f2fs: add support for IV_INO_LBLK_64 encryption policies
Documentation/filesystems/fscrypt.rst | 63 +++++++++++++++++----------
fs/crypto/crypto.c | 10 ++++-
fs/crypto/fscrypt_private.h | 16 +++++--
fs/crypto/keyring.c | 6 ++-
fs/crypto/keysetup.c | 45 ++++++++++++++-----
fs/crypto/policy.c | 41 ++++++++++++++++-
fs/ext4/ext4.h | 2 +
fs/ext4/super.c | 14 ++++++
fs/f2fs/super.c | 26 ++++++++---
include/linux/fscrypt.h | 3 ++
include/uapi/linux/fscrypt.h | 3 +-
11 files changed, 182 insertions(+), 47 deletions(-)
--
2.24.0.rc0.303.g954a862665-goog
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies 2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers @ 2019-10-24 21:54 ` Eric Biggers 2019-10-29 17:47 ` Paul Crowley 2019-11-06 3:35 ` Theodore Y. Ts'o 2019-10-24 21:54 ` [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies Eric Biggers ` (3 subsequent siblings) 4 siblings, 2 replies; 12+ messages in thread From: Eric Biggers @ 2019-10-24 21:54 UTC (permalink / raw) To: linux-fscrypt Cc: linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Theodore Y . Ts'o, Jaegeuk Kim From: Eric Biggers <ebiggers@google.com> Inline encryption hardware compliant with the UFS v2.1 standard or with the upcoming version of the eMMC standard has the following properties: (1) Per I/O request, the encryption key is specified by a previously loaded keyslot. There might be only a small number of keyslots. (2) Per I/O request, the starting IV is specified by a 64-bit "data unit number" (DUN). IV bits 64-127 are assumed to be 0. The hardware automatically increments the DUN for each "data unit" of configurable size in the request, e.g. for each filesystem block. Property (1) makes it inefficient to use the traditional fscrypt per-file keys. Property (2) precludes the use of the existing DIRECT_KEY fscrypt policy flag, which needs at least 192 IV bits. Therefore, add a new fscrypt policy flag IV_INO_LBLK_64 which causes the encryption to modified as follows: - The encryption keys are derived from the master key, encryption mode number, and filesystem UUID. - The IVs are chosen as (inode_number << 32) | file_logical_block_num. For filenames encryption, file_logical_block_num is 0. Since the file nonces aren't used in the key derivation, many files may share the same encryption key. This is much more efficient on the target hardware. Including the inode number in the IVs and mixing the filesystem UUID into the keys ensures that data in different files is nevertheless still encrypted differently. Additionally, limiting the inode and block numbers to 32 bits and placing the block number in the low bits maintains compatibility with the 64-bit DUN convention (property (2) above). Since this scheme assumes that inode numbers are stable (which may preclude filesystem shrinking) and that inode and file logical block numbers are at most 32-bit, IV_INO_LBLK_64 will only be allowed on filesystems that meet these constraints. These are acceptable limitations for the cases where this format would actually be used. Note that IV_INO_LBLK_64 is an on-disk format, not an implementation. This patch just adds support for it using the existing filesystem layer encryption. A later patch will add support for inline encryption. Co-developed-by: Satya Tangirala <satyat@google.com> Signed-off-by: Satya Tangirala <satyat@google.com> Signed-off-by: Eric Biggers <ebiggers@google.com> --- Documentation/filesystems/fscrypt.rst | 63 +++++++++++++++++---------- fs/crypto/crypto.c | 10 ++++- fs/crypto/fscrypt_private.h | 16 +++++-- fs/crypto/keyring.c | 6 ++- fs/crypto/keysetup.c | 45 ++++++++++++++----- fs/crypto/policy.c | 41 ++++++++++++++++- include/linux/fscrypt.h | 3 ++ include/uapi/linux/fscrypt.h | 3 +- 8 files changed, 146 insertions(+), 41 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 6ec459be3de16..471a511c75088 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -256,13 +256,8 @@ alternative master keys or to support rotating master keys. Instead, the master keys may be wrapped in userspace, e.g. as is done by the `fscrypt <https://github.com/google/fscrypt>`_ tool. -Including the inode number in the IVs was considered. However, it was -rejected as it would have prevented ext4 filesystems from being -resized, and by itself still wouldn't have been sufficient to prevent -the same key from being directly reused for both XTS and CTS-CBC. - -DIRECT_KEY and per-mode keys ----------------------------- +DIRECT_KEY policies +------------------- The Adiantum encryption mode (see `Encryption modes and usage`_) is suitable for both contents and filenames encryption, and it accepts @@ -285,6 +280,21 @@ IV. Moreover: key derived using the KDF. Users may use the same master key for other v2 encryption policies. +IV_INO_LBLK_64 policies +----------------------- + +When FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 is set in the fscrypt policy, +the encryption keys are derived from the master key, encryption mode +number, and filesystem UUID. This normally results in all files +protected by the same master key sharing a single contents encryption +key and a single filenames encryption key. To still encrypt different +files' data differently, inode numbers are included in the IVs. +Consequently, shrinking the filesystem may not be allowed. + +This format is optimized for use with inline encryption hardware +compliant with the UFS or eMMC standards, which support only 64 IV +bits per I/O request and may have only a small number of keyslots. + Key identifiers --------------- @@ -342,10 +352,16 @@ a little endian number, except that: is encrypted with AES-256 where the AES-256 key is the SHA-256 hash of the file's data encryption key. -- In the "direct key" configuration (FSCRYPT_POLICY_FLAG_DIRECT_KEY - set in the fscrypt_policy), the file's nonce is also appended to the - IV. Currently this is only allowed with the Adiantum encryption - mode. +- With `DIRECT_KEY policies`_, the file's nonce is appended to the IV. + Currently this is only allowed with the Adiantum encryption mode. + +- With `IV_INO_LBLK_64 policies`_, the logical block number is limited + to 32 bits and is placed in bits 0-31 of the IV. The inode number + (which is also limited to 32 bits) is placed in bits 32-63. + +Note that because file logical block numbers are included in the IVs, +filesystems must enforce that blocks are never shifted around within +encrypted files, e.g. via "collapse range" or "insert range". Filenames encryption -------------------- @@ -355,10 +371,10 @@ the requirements to retain support for efficient directory lookups and filenames of up to 255 bytes, the same IV is used for every filename in a directory. -However, each encrypted directory still uses a unique key; or -alternatively (for the "direct key" configuration) has the file's -nonce included in the IVs. Thus, IV reuse is limited to within a -single directory. +However, each encrypted directory still uses a unique key, or +alternatively has the file's nonce (for `DIRECT_KEY policies`_) or +inode number (for `IV_INO_LBLK_64 policies`_) included in the IVs. +Thus, IV reuse is limited to within a single directory. With CTS-CBC, the IV reuse means that when the plaintext filenames share a common prefix at least as long as the cipher block size (16 @@ -432,12 +448,15 @@ This structure must be initialized as follows: (1) for ``contents_encryption_mode`` and FSCRYPT_MODE_AES_256_CTS (4) for ``filenames_encryption_mode``. -- ``flags`` must contain a value from ``<linux/fscrypt.h>`` which - identifies the amount of NUL-padding to use when encrypting - filenames. If unsure, use FSCRYPT_POLICY_FLAGS_PAD_32 (0x3). - Additionally, if the encryption modes are both - FSCRYPT_MODE_ADIANTUM, this can contain - FSCRYPT_POLICY_FLAG_DIRECT_KEY; see `DIRECT_KEY and per-mode keys`_. +- ``flags`` contains optional flags from ``<linux/fscrypt.h>``: + + - FSCRYPT_POLICY_FLAGS_PAD_*: The amount of NUL padding to use when + encrypting filenames. If unsure, use FSCRYPT_POLICY_FLAGS_PAD_32 + (0x3). + - FSCRYPT_POLICY_FLAG_DIRECT_KEY: See `DIRECT_KEY policies`_. + - FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64: See `IV_INO_LBLK_64 + policies`_. This is mutually exclusive with DIRECT_KEY and is not + supported on v1 policies. - For v2 encryption policies, ``__reserved`` must be zeroed. @@ -1090,7 +1109,7 @@ policy structs (see `Setting an encryption policy`_), except that the context structs also contain a nonce. The nonce is randomly generated by the kernel and is used as KDF input or as a tweak to cause different files to be encrypted differently; see `Per-file keys`_ and -`DIRECT_KEY and per-mode keys`_. +`DIRECT_KEY policies`_. Data path changes ----------------- diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index ced8ad9f2d019..3719efa546c65 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -73,11 +73,17 @@ EXPORT_SYMBOL(fscrypt_free_bounce_page); void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, const struct fscrypt_info *ci) { + u8 flags = fscrypt_policy_flags(&ci->ci_policy); + memset(iv, 0, ci->ci_mode->ivsize); - iv->lblk_num = cpu_to_le64(lblk_num); - if (fscrypt_is_direct_key_policy(&ci->ci_policy)) + if (flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) { + WARN_ON_ONCE((u32)lblk_num != lblk_num); + lblk_num |= (u64)ci->ci_inode->i_ino << 32; + } else if (flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) { memcpy(iv->nonce, ci->ci_nonce, FS_KEY_DERIVATION_NONCE_SIZE); + } + iv->lblk_num = cpu_to_le64(lblk_num); } /* Encrypt or decrypt a single filesystem block of file contents */ diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index dacf8fcbac3be..b44e445b43a8a 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -163,6 +163,9 @@ struct fscrypt_info { /* The actual crypto transform used for encryption and decryption */ struct crypto_skcipher *ci_ctfm; + /* True if the key should be freed when this fscrypt_info is freed */ + bool ci_owns_key; + /* * Encryption mode used for this inode. It corresponds to either the * contents or filenames encryption mode, depending on the inode type. @@ -281,7 +284,8 @@ extern int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key, */ #define HKDF_CONTEXT_KEY_IDENTIFIER 1 #define HKDF_CONTEXT_PER_FILE_KEY 2 -#define HKDF_CONTEXT_PER_MODE_KEY 3 +#define HKDF_CONTEXT_DIRECT_KEY 3 +#define HKDF_CONTEXT_IV_INO_LBLK_64_KEY 4 extern int fscrypt_hkdf_expand(struct fscrypt_hkdf *hkdf, u8 context, const u8 *info, unsigned int infolen, @@ -378,8 +382,14 @@ struct fscrypt_master_key { struct list_head mk_decrypted_inodes; spinlock_t mk_decrypted_inodes_lock; - /* Per-mode tfms for DIRECT_KEY policies, allocated on-demand */ - struct crypto_skcipher *mk_mode_keys[__FSCRYPT_MODE_MAX + 1]; + /* Crypto API transforms for DIRECT_KEY policies, allocated on-demand */ + struct crypto_skcipher *mk_direct_tfms[__FSCRYPT_MODE_MAX + 1]; + + /* + * Crypto API transforms for filesystem-layer implementation of + * IV_INO_LBLK_64 policies, allocated on-demand. + */ + struct crypto_skcipher *mk_iv_ino_lblk_64_tfms[__FSCRYPT_MODE_MAX + 1]; } __randomize_layout; diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c index c34fa7c61b43b..040df1f5e1c8b 100644 --- a/fs/crypto/keyring.c +++ b/fs/crypto/keyring.c @@ -43,8 +43,10 @@ static void free_master_key(struct fscrypt_master_key *mk) wipe_master_key_secret(&mk->mk_secret); - for (i = 0; i < ARRAY_SIZE(mk->mk_mode_keys); i++) - crypto_free_skcipher(mk->mk_mode_keys[i]); + for (i = 0; i <= __FSCRYPT_MODE_MAX; i++) { + crypto_free_skcipher(mk->mk_direct_tfms[i]); + crypto_free_skcipher(mk->mk_iv_ino_lblk_64_tfms[i]); + } key_put(mk->mk_users); kzfree(mk); diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index b03b33643e4b2..f87ab930b92a6 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -116,40 +116,54 @@ int fscrypt_set_derived_key(struct fscrypt_info *ci, const u8 *derived_key) return PTR_ERR(tfm); ci->ci_ctfm = tfm; + ci->ci_owns_key = true; return 0; } static int setup_per_mode_key(struct fscrypt_info *ci, - struct fscrypt_master_key *mk) + struct fscrypt_master_key *mk, + struct crypto_skcipher **tfms, + u8 hkdf_context, bool include_fs_uuid) { + const struct inode *inode = ci->ci_inode; + const struct super_block *sb = inode->i_sb; struct fscrypt_mode *mode = ci->ci_mode; u8 mode_num = mode - available_modes; struct crypto_skcipher *tfm, *prev_tfm; u8 mode_key[FSCRYPT_MAX_KEY_SIZE]; + u8 hkdf_info[sizeof(mode_num) + sizeof(sb->s_uuid)]; + unsigned int hkdf_infolen = 0; int err; - if (WARN_ON(mode_num >= ARRAY_SIZE(mk->mk_mode_keys))) + if (WARN_ON(mode_num > __FSCRYPT_MODE_MAX)) return -EINVAL; /* pairs with cmpxchg() below */ - tfm = READ_ONCE(mk->mk_mode_keys[mode_num]); + tfm = READ_ONCE(tfms[mode_num]); if (likely(tfm != NULL)) goto done; BUILD_BUG_ON(sizeof(mode_num) != 1); + BUILD_BUG_ON(sizeof(sb->s_uuid) != 16); + BUILD_BUG_ON(sizeof(hkdf_info) != 17); + hkdf_info[hkdf_infolen++] = mode_num; + if (include_fs_uuid) { + memcpy(&hkdf_info[hkdf_infolen], &sb->s_uuid, + sizeof(sb->s_uuid)); + hkdf_infolen += sizeof(sb->s_uuid); + } err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, - HKDF_CONTEXT_PER_MODE_KEY, - &mode_num, sizeof(mode_num), + hkdf_context, hkdf_info, hkdf_infolen, mode_key, mode->keysize); if (err) return err; - tfm = fscrypt_allocate_skcipher(mode, mode_key, ci->ci_inode); + tfm = fscrypt_allocate_skcipher(mode, mode_key, inode); memzero_explicit(mode_key, mode->keysize); if (IS_ERR(tfm)) return PTR_ERR(tfm); /* pairs with READ_ONCE() above */ - prev_tfm = cmpxchg(&mk->mk_mode_keys[mode_num], NULL, tfm); + prev_tfm = cmpxchg(&tfms[mode_num], NULL, tfm); if (prev_tfm != NULL) { crypto_free_skcipher(tfm); tfm = prev_tfm; @@ -180,7 +194,19 @@ static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci, ci->ci_mode->friendly_name); return -EINVAL; } - return setup_per_mode_key(ci, mk); + return setup_per_mode_key(ci, mk, mk->mk_direct_tfms, + HKDF_CONTEXT_DIRECT_KEY, false); + } else if (ci->ci_policy.v2.flags & + FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) { + /* + * IV_INO_LBLK_64: encryption keys are derived from (master_key, + * mode_num, filesystem_uuid), and inode number is included in + * the IVs. This format is optimized for use with inline + * encryption hardware compliant with the UFS or eMMC standards. + */ + return setup_per_mode_key(ci, mk, mk->mk_iv_ino_lblk_64_tfms, + HKDF_CONTEXT_IV_INO_LBLK_64_KEY, + true); } err = fscrypt_hkdf_expand(&mk->mk_secret.hkdf, @@ -304,8 +330,7 @@ static void put_crypt_info(struct fscrypt_info *ci) if (ci->ci_direct_key) fscrypt_put_direct_key(ci->ci_direct_key); - else if (ci->ci_ctfm != NULL && - !fscrypt_is_direct_key_policy(&ci->ci_policy)) + else if (ci->ci_owns_key) crypto_free_skcipher(ci->ci_ctfm); key = ci->ci_master_key; diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index 4072ba644595b..96f528071bed3 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -29,6 +29,40 @@ bool fscrypt_policies_equal(const union fscrypt_policy *policy1, return !memcmp(policy1, policy2, fscrypt_policy_size(policy1)); } +static bool supported_iv_ino_lblk_64_policy( + const struct fscrypt_policy_v2 *policy, + const struct inode *inode) +{ + struct super_block *sb = inode->i_sb; + int ino_bits = 64, lblk_bits = 64; + + if (policy->flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) { + fscrypt_warn(inode, + "The DIRECT_KEY and IV_INO_LBLK_64 flags are mutually exclusive"); + return false; + } + /* + * It's unsafe to include inode numbers in the IVs if the filesystem can + * potentially renumber inodes, e.g. via filesystem shrinking. + */ + if (!sb->s_cop->has_stable_inodes || + !sb->s_cop->has_stable_inodes(sb)) { + fscrypt_warn(inode, + "Can't use IV_INO_LBLK_64 policy on filesystem '%s' because it doesn't have stable inode numbers", + sb->s_id); + return false; + } + if (sb->s_cop->get_ino_and_lblk_bits) + sb->s_cop->get_ino_and_lblk_bits(sb, &ino_bits, &lblk_bits); + if (ino_bits > 32 || lblk_bits > 32) { + fscrypt_warn(inode, + "Can't use IV_INO_LBLK_64 policy on filesystem '%s' because it doesn't use 32-bit inode and block numbers", + sb->s_id); + return false; + } + return true; +} + /** * fscrypt_supported_policy - check whether an encryption policy is supported * @@ -55,7 +89,8 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u, return false; } - if (policy->flags & ~FSCRYPT_POLICY_FLAGS_VALID) { + if (policy->flags & ~(FSCRYPT_POLICY_FLAGS_PAD_MASK | + FSCRYPT_POLICY_FLAG_DIRECT_KEY)) { fscrypt_warn(inode, "Unsupported encryption flags (0x%02x)", policy->flags); @@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u, return false; } + if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) && + !supported_iv_ino_lblk_64_policy(policy, inode)) + return false; + if (memchr_inv(policy->__reserved, 0, sizeof(policy->__reserved))) { fscrypt_warn(inode, diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index 04f5ed6284454..1a7bffe78ed56 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -61,6 +61,9 @@ struct fscrypt_operations { bool (*dummy_context)(struct inode *); bool (*empty_dir)(struct inode *); unsigned int max_namelen; + bool (*has_stable_inodes)(struct super_block *sb); + void (*get_ino_and_lblk_bits)(struct super_block *sb, + int *ino_bits_ret, int *lblk_bits_ret); }; static inline bool fscrypt_has_encryption_key(const struct inode *inode) diff --git a/include/uapi/linux/fscrypt.h b/include/uapi/linux/fscrypt.h index 39ccfe9311c38..1beb174ad9505 100644 --- a/include/uapi/linux/fscrypt.h +++ b/include/uapi/linux/fscrypt.h @@ -17,7 +17,8 @@ #define FSCRYPT_POLICY_FLAGS_PAD_32 0x03 #define FSCRYPT_POLICY_FLAGS_PAD_MASK 0x03 #define FSCRYPT_POLICY_FLAG_DIRECT_KEY 0x04 -#define FSCRYPT_POLICY_FLAGS_VALID 0x07 +#define FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64 0x08 +#define FSCRYPT_POLICY_FLAGS_VALID 0x0F /* Encryption algorithms */ #define FSCRYPT_MODE_AES_256_XTS 1 -- 2.24.0.rc0.303.g954a862665-goog ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies 2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers @ 2019-10-29 17:47 ` Paul Crowley 2019-11-06 3:35 ` Theodore Y. Ts'o 1 sibling, 0 replies; 12+ messages in thread From: Paul Crowley @ 2019-10-29 17:47 UTC (permalink / raw) To: Eric Biggers Cc: linux-fscrypt, linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Lawrence, Theodore Y . Ts'o, Jaegeuk Kim On Thu, 24 Oct 2019 at 14:57, Eric Biggers <ebiggers@kernel.org> wrote: > From: Eric Biggers <ebiggers@google.com> > > Co-developed-by: Satya Tangirala <satyat@google.com> > Signed-off-by: Satya Tangirala <satyat@google.com> > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > Documentation/filesystems/fscrypt.rst | 63 +++++++++++++++++---------- > fs/crypto/crypto.c | 10 ++++- > fs/crypto/fscrypt_private.h | 16 +++++-- > fs/crypto/keyring.c | 6 ++- > fs/crypto/keysetup.c | 45 ++++++++++++++----- > fs/crypto/policy.c | 41 ++++++++++++++++- > include/linux/fscrypt.h | 3 ++ > include/uapi/linux/fscrypt.h | 3 +- > 8 files changed, 146 insertions(+), 41 deletions(-) I don't understand all of this, but the crypto-relevant part looks good to me. Reviewed-By: Paul Crowley <paulcrowley@google.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies 2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers 2019-10-29 17:47 ` Paul Crowley @ 2019-11-06 3:35 ` Theodore Y. Ts'o 2019-11-06 4:05 ` Eric Biggers 1 sibling, 1 reply; 12+ messages in thread From: Theodore Y. Ts'o @ 2019-11-06 3:35 UTC (permalink / raw) To: Eric Biggers Cc: linux-fscrypt, linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Jaegeuk Kim On Thu, Oct 24, 2019 at 02:54:36PM -0700, Eric Biggers wrote: > @@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u, > return false; > } > > + if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) && > + !supported_iv_ino_lblk_64_policy(policy, inode)) > + return false; > + > if (memchr_inv(policy->__reserved, 0, > sizeof(policy->__reserved))) { > fscrypt_warn(inode, fscrypt_supported_policy is getting more and more complicated, and supported_iv_ino_lblk_64_policy calls a fs-supplied callback function, etc. And we need to use this every single time we need to set up an inode. Granted that compared to the crypto, even if it is ICE, it's probably small beer --- but perhaps we should think about caching some of what fscrypt_supported_policy does on a per-file system basis at some point? - Ted ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies 2019-11-06 3:35 ` Theodore Y. Ts'o @ 2019-11-06 4:05 ` Eric Biggers 2019-11-07 2:49 ` Theodore Y. Ts'o 0 siblings, 1 reply; 12+ messages in thread From: Eric Biggers @ 2019-11-06 4:05 UTC (permalink / raw) To: Theodore Y. Ts'o Cc: linux-fscrypt, linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Jaegeuk Kim On Tue, Nov 05, 2019 at 10:35:44PM -0500, Theodore Y. Ts'o wrote: > On Thu, Oct 24, 2019 at 02:54:36PM -0700, Eric Biggers wrote: > > @@ -83,6 +118,10 @@ bool fscrypt_supported_policy(const union fscrypt_policy *policy_u, > > return false; > > } > > > > + if ((policy->flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) && > > + !supported_iv_ino_lblk_64_policy(policy, inode)) > > + return false; > > + > > if (memchr_inv(policy->__reserved, 0, > > sizeof(policy->__reserved))) { > > fscrypt_warn(inode, > > fscrypt_supported_policy is getting more and more complicated, and > supported_iv_ino_lblk_64_policy calls a fs-supplied callback function, > etc. And we need to use this every single time we need to set up an > inode. Granted that compared to the crypto, even if it is ICE, it's > probably small beer --- but perhaps we should think about caching some > of what fscrypt_supported_policy does on a per-file system basis at > some point? I don't think this will make any difference given everything else that needs to be done to set up a file's key. Also, anything extra we spend here will be far less than the amount of time we save with IV_INO_LBLK_64 policies by not having to do the key derivation and tfm allocation for every file. Christoph suggested replacing ->has_stable_inodes() and ->get_ino_and_lblk_bits() with a new SB_* flag like SB_IV_INO_LBLK_64_SUPPORT. But I don't like that that would result in worse error messages and would "leak" a specific fscrypt policy flag into filesystems rather than having the filesystems declare their properties. If we really wanted to optimize fscrypt_get_encryption_info(), I think we probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather take advantage of the fact that fscrypt_has_permitted_context() already ran. E.g., we could cache the xattr, or skip both the keyring lookup and fscrypt_supported_policy() by grabbing them from the parent directory. - Eric ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies 2019-11-06 4:05 ` Eric Biggers @ 2019-11-07 2:49 ` Theodore Y. Ts'o 0 siblings, 0 replies; 12+ messages in thread From: Theodore Y. Ts'o @ 2019-11-07 2:49 UTC (permalink / raw) To: linux-fscrypt, linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Jaegeuk Kim On Tue, Nov 05, 2019 at 08:05:19PM -0800, Eric Biggers wrote: > If we really wanted to optimize fscrypt_get_encryption_info(), I think we > probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather > take advantage of the fact that fscrypt_has_permitted_context() already ran. > E.g., we could cache the xattr, or skip both the keyring lookup and > fscrypt_supported_policy() by grabbing them from the parent directory. Yes, good point. Certainly, if the parent is encrypted, given that we force files to have the same policy as the containing directory, there's no point calling fscrypt_supported_policy. And if we're using a policy which isn't using per-inode keys, then we can certainly just grab the key from the parent directory. - Ted ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies 2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers 2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers @ 2019-10-24 21:54 ` Eric Biggers 2019-11-06 3:26 ` Theodore Y. Ts'o 2019-10-24 21:54 ` [PATCH v2 3/3] f2fs: " Eric Biggers ` (2 subsequent siblings) 4 siblings, 1 reply; 12+ messages in thread From: Eric Biggers @ 2019-10-24 21:54 UTC (permalink / raw) To: linux-fscrypt Cc: linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Theodore Y . Ts'o, Jaegeuk Kim From: Eric Biggers <ebiggers@google.com> IV_INO_LBLK_64 encryption policies have special requirements from the filesystem beyond those of the existing encryption policies: - Inode numbers must never change, even if the filesystem is resized. - Inode numbers must be <= 32 bits. - File logical block numbers must be <= 32 bits. ext4 has 32-bit inode and file logical block numbers. However, resize2fs can re-number inodes when shrinking an ext4 filesystem. However, typically the people who would want to use this format don't care about filesystem shrinking. They'd be fine with a solution that just prevents the filesystem from being shrunk. Therefore, add a new feature flag EXT4_FEATURE_COMPAT_STABLE_INODES that will do exactly that. Then wire up the fscrypt_operations to expose this flag to fs/crypto/, so that it allows IV_INO_LBLK_64 policies when this flag is set. Signed-off-by: Eric Biggers <ebiggers@google.com> --- fs/ext4/ext4.h | 2 ++ fs/ext4/super.c | 14 ++++++++++++++ 2 files changed, 16 insertions(+) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 03db3e71676ce..b3a2cc7c0252f 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1678,6 +1678,7 @@ static inline bool ext4_verity_in_progress(struct inode *inode) #define EXT4_FEATURE_COMPAT_RESIZE_INODE 0x0010 #define EXT4_FEATURE_COMPAT_DIR_INDEX 0x0020 #define EXT4_FEATURE_COMPAT_SPARSE_SUPER2 0x0200 +#define EXT4_FEATURE_COMPAT_STABLE_INODES 0x0800 #define EXT4_FEATURE_RO_COMPAT_SPARSE_SUPER 0x0001 #define EXT4_FEATURE_RO_COMPAT_LARGE_FILE 0x0002 @@ -1779,6 +1780,7 @@ EXT4_FEATURE_COMPAT_FUNCS(xattr, EXT_ATTR) EXT4_FEATURE_COMPAT_FUNCS(resize_inode, RESIZE_INODE) EXT4_FEATURE_COMPAT_FUNCS(dir_index, DIR_INDEX) EXT4_FEATURE_COMPAT_FUNCS(sparse_super2, SPARSE_SUPER2) +EXT4_FEATURE_COMPAT_FUNCS(stable_inodes, STABLE_INODES) EXT4_FEATURE_RO_COMPAT_FUNCS(sparse_super, SPARSE_SUPER) EXT4_FEATURE_RO_COMPAT_FUNCS(large_file, LARGE_FILE) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index dd654e53ba3d9..b3cbf8622eab6 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1345,6 +1345,18 @@ static bool ext4_dummy_context(struct inode *inode) return DUMMY_ENCRYPTION_ENABLED(EXT4_SB(inode->i_sb)); } +static bool ext4_has_stable_inodes(struct super_block *sb) +{ + return ext4_has_feature_stable_inodes(sb); +} + +static void ext4_get_ino_and_lblk_bits(struct super_block *sb, + int *ino_bits_ret, int *lblk_bits_ret) +{ + *ino_bits_ret = 8 * sizeof(EXT4_SB(sb)->s_es->s_inodes_count); + *lblk_bits_ret = 8 * sizeof(ext4_lblk_t); +} + static const struct fscrypt_operations ext4_cryptops = { .key_prefix = "ext4:", .get_context = ext4_get_context, @@ -1352,6 +1364,8 @@ static const struct fscrypt_operations ext4_cryptops = { .dummy_context = ext4_dummy_context, .empty_dir = ext4_empty_dir, .max_namelen = EXT4_NAME_LEN, + .has_stable_inodes = ext4_has_stable_inodes, + .get_ino_and_lblk_bits = ext4_get_ino_and_lblk_bits, }; #endif -- 2.24.0.rc0.303.g954a862665-goog ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies 2019-10-24 21:54 ` [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies Eric Biggers @ 2019-11-06 3:26 ` Theodore Y. Ts'o 0 siblings, 0 replies; 12+ messages in thread From: Theodore Y. Ts'o @ 2019-11-06 3:26 UTC (permalink / raw) To: Eric Biggers Cc: linux-fscrypt, linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Jaegeuk Kim On Thu, Oct 24, 2019 at 02:54:37PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > IV_INO_LBLK_64 encryption policies have special requirements from the > filesystem beyond those of the existing encryption policies: > > - Inode numbers must never change, even if the filesystem is resized. > - Inode numbers must be <= 32 bits. > - File logical block numbers must be <= 32 bits. > > ext4 has 32-bit inode and file logical block numbers. However, > resize2fs can re-number inodes when shrinking an ext4 filesystem. > > However, typically the people who would want to use this format don't > care about filesystem shrinking. They'd be fine with a solution that > just prevents the filesystem from being shrunk. > > Therefore, add a new feature flag EXT4_FEATURE_COMPAT_STABLE_INODES that > will do exactly that. Then wire up the fscrypt_operations to expose > this flag to fs/crypto/, so that it allows IV_INO_LBLK_64 policies when > this flag is set. > > Signed-off-by: Eric Biggers <ebiggers@google.com> LGTM Acked-by: Theodore Ts'o <tytso@mit.edu> - Ted ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 3/3] f2fs: add support for IV_INO_LBLK_64 encryption policies 2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers 2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers 2019-10-24 21:54 ` [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies Eric Biggers @ 2019-10-24 21:54 ` Eric Biggers 2019-11-01 18:33 ` Jaegeuk Kim 2019-11-01 18:02 ` [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers 2019-11-06 21:04 ` Eric Biggers 4 siblings, 1 reply; 12+ messages in thread From: Eric Biggers @ 2019-10-24 21:54 UTC (permalink / raw) To: linux-fscrypt Cc: linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Theodore Y . Ts'o, Jaegeuk Kim From: Eric Biggers <ebiggers@google.com> f2fs inode numbers are stable across filesystem resizing, and f2fs inode and file logical block numbers are always 32-bit. So f2fs can always support IV_INO_LBLK_64 encryption policies. Wire up the needed fscrypt_operations to declare support. Signed-off-by: Eric Biggers <ebiggers@google.com> --- fs/f2fs/super.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 1443cee158633..851ac95229263 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -2308,13 +2308,27 @@ static bool f2fs_dummy_context(struct inode *inode) return DUMMY_ENCRYPTION_ENABLED(F2FS_I_SB(inode)); } +static bool f2fs_has_stable_inodes(struct super_block *sb) +{ + return true; +} + +static void f2fs_get_ino_and_lblk_bits(struct super_block *sb, + int *ino_bits_ret, int *lblk_bits_ret) +{ + *ino_bits_ret = 8 * sizeof(nid_t); + *lblk_bits_ret = 8 * sizeof(block_t); +} + static const struct fscrypt_operations f2fs_cryptops = { - .key_prefix = "f2fs:", - .get_context = f2fs_get_context, - .set_context = f2fs_set_context, - .dummy_context = f2fs_dummy_context, - .empty_dir = f2fs_empty_dir, - .max_namelen = F2FS_NAME_LEN, + .key_prefix = "f2fs:", + .get_context = f2fs_get_context, + .set_context = f2fs_set_context, + .dummy_context = f2fs_dummy_context, + .empty_dir = f2fs_empty_dir, + .max_namelen = F2FS_NAME_LEN, + .has_stable_inodes = f2fs_has_stable_inodes, + .get_ino_and_lblk_bits = f2fs_get_ino_and_lblk_bits, }; #endif -- 2.24.0.rc0.303.g954a862665-goog ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 3/3] f2fs: add support for IV_INO_LBLK_64 encryption policies 2019-10-24 21:54 ` [PATCH v2 3/3] f2fs: " Eric Biggers @ 2019-11-01 18:33 ` Jaegeuk Kim 0 siblings, 0 replies; 12+ messages in thread From: Jaegeuk Kim @ 2019-11-01 18:33 UTC (permalink / raw) To: Eric Biggers Cc: linux-fscrypt, linux-ext4, linux-f2fs-devel, linux-fsdevel, Satya Tangirala, Paul Crowley, Paul Lawrence, Theodore Y . Ts'o On 10/24, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > f2fs inode numbers are stable across filesystem resizing, and f2fs inode > and file logical block numbers are always 32-bit. So f2fs can always > support IV_INO_LBLK_64 encryption policies. Wire up the needed > fscrypt_operations to declare support. > > Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Jaegeuk Kim <jaegeuk@kernel.org> > --- > fs/f2fs/super.c | 26 ++++++++++++++++++++------ > 1 file changed, 20 insertions(+), 6 deletions(-) > > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c > index 1443cee158633..851ac95229263 100644 > --- a/fs/f2fs/super.c > +++ b/fs/f2fs/super.c > @@ -2308,13 +2308,27 @@ static bool f2fs_dummy_context(struct inode *inode) > return DUMMY_ENCRYPTION_ENABLED(F2FS_I_SB(inode)); > } > > +static bool f2fs_has_stable_inodes(struct super_block *sb) > +{ > + return true; > +} > + > +static void f2fs_get_ino_and_lblk_bits(struct super_block *sb, > + int *ino_bits_ret, int *lblk_bits_ret) > +{ > + *ino_bits_ret = 8 * sizeof(nid_t); > + *lblk_bits_ret = 8 * sizeof(block_t); > +} > + > static const struct fscrypt_operations f2fs_cryptops = { > - .key_prefix = "f2fs:", > - .get_context = f2fs_get_context, > - .set_context = f2fs_set_context, > - .dummy_context = f2fs_dummy_context, > - .empty_dir = f2fs_empty_dir, > - .max_namelen = F2FS_NAME_LEN, > + .key_prefix = "f2fs:", > + .get_context = f2fs_get_context, > + .set_context = f2fs_set_context, > + .dummy_context = f2fs_dummy_context, > + .empty_dir = f2fs_empty_dir, > + .max_namelen = F2FS_NAME_LEN, > + .has_stable_inodes = f2fs_has_stable_inodes, > + .get_ino_and_lblk_bits = f2fs_get_ino_and_lblk_bits, > }; > #endif > > -- > 2.24.0.rc0.303.g954a862665-goog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies 2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers ` (2 preceding siblings ...) 2019-10-24 21:54 ` [PATCH v2 3/3] f2fs: " Eric Biggers @ 2019-11-01 18:02 ` Eric Biggers 2019-11-06 21:04 ` Eric Biggers 4 siblings, 0 replies; 12+ messages in thread From: Eric Biggers @ 2019-11-01 18:02 UTC (permalink / raw) To: linux-fscrypt Cc: linux-f2fs-devel, Theodore Y . Ts'o, Satya Tangirala, Paul Lawrence, linux-fsdevel, Jaegeuk Kim, linux-ext4, Paul Crowley On Thu, Oct 24, 2019 at 02:54:35PM -0700, Eric Biggers wrote: > Hello, > > In preparation for adding inline encryption support to fscrypt, this > patchset adds a new fscrypt policy flag which modifies the encryption to > be optimized for inline encryption hardware compliant with the UFS v2.1 > standard or the upcoming version of the eMMC standard. > > This means using per-mode keys instead of per-file keys, and in > compensation including the inode number in the IVs. For ext4, this > precludes filesystem shrinking, so I've also added a compat feature > which will prevent the filesystem from being shrunk. > > I've separated this from the full "Inline Encryption Support" patchset > (https://lkml.kernel.org/linux-fsdevel/20190821075714.65140-1-satyat@google.com/) > to avoid conflating an implementation (inline encryption) with a new > on-disk format (IV_INO_LBLK_64). This patchset purely adds support for > IV_INO_LBLK_64 policies to fscrypt, but implements them using the > existing filesystem layer crypto. > > We're planning to make the *implementation* (filesystem layer or inline > crypto) be controlled by a mount option '-o inlinecrypt'. > > This patchset applies to fscrypt.git#master and can also be retrieved from > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=inline-crypt-optimized-v2 > > I've written a ciphertext verification test for this new type of policy: > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/xfstests-dev.git/log/?h=inline-encryption > > Work-in-progress patches for the inline encryption implementation of > both IV_INO_LBLK_64 and regular policies can be found at > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=inline-encryption-wip > > Changes v1 => v2: > > - Rename the flag from INLINE_CRYPT_OPTIMIZED to IV_INO_LBLK_64. > > - Use the same key derivation and IV generation scheme for filenames > encryption too. > > - Improve the documentation and commit messages. > > Eric Biggers (3): > fscrypt: add support for IV_INO_LBLK_64 policies > ext4: add support for IV_INO_LBLK_64 encryption policies > f2fs: add support for IV_INO_LBLK_64 encryption policies > Does anyone have any more comments on these patches? - Eric ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies 2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers ` (3 preceding siblings ...) 2019-11-01 18:02 ` [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers @ 2019-11-06 21:04 ` Eric Biggers 4 siblings, 0 replies; 12+ messages in thread From: Eric Biggers @ 2019-11-06 21:04 UTC (permalink / raw) To: linux-fscrypt Cc: linux-f2fs-devel, Theodore Y . Ts'o, Satya Tangirala, Paul Lawrence, linux-fsdevel, Jaegeuk Kim, linux-ext4, Paul Crowley On Thu, Oct 24, 2019 at 02:54:35PM -0700, Eric Biggers wrote: > Hello, > > In preparation for adding inline encryption support to fscrypt, this > patchset adds a new fscrypt policy flag which modifies the encryption to > be optimized for inline encryption hardware compliant with the UFS v2.1 > standard or the upcoming version of the eMMC standard. > > This means using per-mode keys instead of per-file keys, and in > compensation including the inode number in the IVs. For ext4, this > precludes filesystem shrinking, so I've also added a compat feature > which will prevent the filesystem from being shrunk. > > I've separated this from the full "Inline Encryption Support" patchset > (https://lkml.kernel.org/linux-fsdevel/20190821075714.65140-1-satyat@google.com/) > to avoid conflating an implementation (inline encryption) with a new > on-disk format (IV_INO_LBLK_64). This patchset purely adds support for > IV_INO_LBLK_64 policies to fscrypt, but implements them using the > existing filesystem layer crypto. > > We're planning to make the *implementation* (filesystem layer or inline > crypto) be controlled by a mount option '-o inlinecrypt'. > > This patchset applies to fscrypt.git#master and can also be retrieved from > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=inline-crypt-optimized-v2 > > I've written a ciphertext verification test for this new type of policy: > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/xfstests-dev.git/log/?h=inline-encryption > > Work-in-progress patches for the inline encryption implementation of > both IV_INO_LBLK_64 and regular policies can be found at > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=inline-encryption-wip > > Changes v1 => v2: > > - Rename the flag from INLINE_CRYPT_OPTIMIZED to IV_INO_LBLK_64. > > - Use the same key derivation and IV generation scheme for filenames > encryption too. > > - Improve the documentation and commit messages. > > Eric Biggers (3): > fscrypt: add support for IV_INO_LBLK_64 policies > ext4: add support for IV_INO_LBLK_64 encryption policies > f2fs: add support for IV_INO_LBLK_64 encryption policies > > Documentation/filesystems/fscrypt.rst | 63 +++++++++++++++++---------- > fs/crypto/crypto.c | 10 ++++- > fs/crypto/fscrypt_private.h | 16 +++++-- > fs/crypto/keyring.c | 6 ++- > fs/crypto/keysetup.c | 45 ++++++++++++++----- > fs/crypto/policy.c | 41 ++++++++++++++++- > fs/ext4/ext4.h | 2 + > fs/ext4/super.c | 14 ++++++ > fs/f2fs/super.c | 26 ++++++++--- > include/linux/fscrypt.h | 3 ++ > include/uapi/linux/fscrypt.h | 3 +- > 11 files changed, 182 insertions(+), 47 deletions(-) > > -- Applied to fscrypt.git#master for 5.5. - Eric ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-11-07 2:49 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-24 21:54 [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers 2019-10-24 21:54 ` [PATCH v2 1/3] fscrypt: add " Eric Biggers 2019-10-29 17:47 ` Paul Crowley 2019-11-06 3:35 ` Theodore Y. Ts'o 2019-11-06 4:05 ` Eric Biggers 2019-11-07 2:49 ` Theodore Y. Ts'o 2019-10-24 21:54 ` [PATCH v2 2/3] ext4: add support for IV_INO_LBLK_64 encryption policies Eric Biggers 2019-11-06 3:26 ` Theodore Y. Ts'o 2019-10-24 21:54 ` [PATCH v2 3/3] f2fs: " Eric Biggers 2019-11-01 18:33 ` Jaegeuk Kim 2019-11-01 18:02 ` [PATCH v2 0/3] fscrypt: support for IV_INO_LBLK_64 policies Eric Biggers 2019-11-06 21:04 ` Eric Biggers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).