| Message ID | 48d09d4905d0c6e5e72d37535eb852487f1bd9cb.1662420176.git.sweettea-kernel@dorminy.me (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | btrfs: add fscrypt integration | expand |
On Mon, Sep 05, 2022 at 08:35:20PM -0400, Sweet Tea Dorminy wrote: > Some filesystems need to encrypt data based on extents, rather than on > inodes, due to features incompatible with inode-based encryption. For > instance, btrfs can have multiple inodes referencing a single block of > data, and moves logical data blocks to different physical locations on > disk in the background; these two features mean inode or > physical-location-based policies will not work for btrfs. I really like how this abstracts away the encryption details from the filesystem. > This change introduces fscrypt_extent_context objects, in analogy to > existing context objects based on inodes. For a filesystem which uses > extents, This makes it sounds like all filesystems that store allocations as extents should define these, but ext4 (for example) uses extents but is fine with inode-based encryption policies. Perhaps this can say something like "A filesytem can opt into the extent-based encryption policy by defining new hooks that manage a new fscrypt_extent_context." > a new hook provides a new fscrypt_extent_context. During file > content encryption/decryption, the existing fscrypt_context object > provides key information, while the new fscrypt_extent_context provides > IV information. For filename encryption, the existing IV generation > methods are still used, since filenames are not stored in extents. > > As individually keyed inodes prevent sharing of extents, such policies > are forbidden for filesystems with extent-based encryption. This ends up forcing Btrfs to use Adiantum. However, I imagine that most users would prefer to use AES if their CPU has AES instructions. From what I understand, it should still be possible to use the AES encryption modes with extent contexts, correct? We just need to decide how to make that work with the encryption policy flags. I see a couple of options: 1. We add a specific FSCRYPT_POLICY_FLAG_EXTENT_BASED or something like that which the user must specify for filesystems requiring extent-based encryption. 2. The "default" mode (i.e., none of DIRECT_KEY, IV_INO_LBLK_64, nor IV_INO_LBLK_32 are specified) automatically opts into extent-based encryption for filesystems requiring it. Either way, we should probably still disallow IV_INO_LBLK_64 and IV_INO_LBLK_32 since neither of those make sense with per-extent IVs. I'd love to hear what Eric would prefer here. Thanks, Omar
On Mon, Sep 05, 2022 at 08:35:20PM -0400, Sweet Tea Dorminy wrote: > Some filesystems need to encrypt data based on extents, rather than on > inodes, due to features incompatible with inode-based encryption. For > instance, btrfs can have multiple inodes referencing a single block of > data, and moves logical data blocks to different physical locations on > disk in the background; these two features mean inode or > physical-location-based policies will not work for btrfs. > > This change introduces fscrypt_extent_context objects, in analogy to > existing context objects based on inodes. For a filesystem which uses > extents, a new hook provides a new fscrypt_extent_context. During file > content encryption/decryption, the existing fscrypt_context object > provides key information, while the new fscrypt_extent_context provides > IV information. For filename encryption, the existing IV generation > methods are still used, since filenames are not stored in extents. > > As individually keyed inodes prevent sharing of extents, such policies > are forbidden for filesystems with extent-based encryption. > > Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> > --- > fs/crypto/crypto.c | 15 +++++++- > fs/crypto/fscrypt_private.h | 26 ++++++++++++- > fs/crypto/inline_crypt.c | 29 +++++++++++--- > fs/crypto/policy.c | 77 +++++++++++++++++++++++++++++++++++++ > include/linux/fscrypt.h | 41 ++++++++++++++++++++ > 5 files changed, 178 insertions(+), 10 deletions(-) > > diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c > index 7fe5979fbea2..77537736096b 100644 > --- a/fs/crypto/crypto.c > +++ b/fs/crypto/crypto.c > @@ -81,8 +81,19 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, > const struct fscrypt_info *ci) > { > u8 flags = fscrypt_policy_flags(&ci->ci_policy); > + struct inode *inode = ci->ci_inode; > + const struct fscrypt_operations *s_cop = inode->i_sb->s_cop; > > memset(iv, 0, ci->ci_mode->ivsize); > + if (s_cop->get_extent_context && lblk_num != U64_MAX) { > + size_t extent_offset; > + union fscrypt_extent_context ctx; > + int ret = fscrypt_get_extent_context(inode, lblk_num, &ctx, &extent_offset, NULL); Newline between declarations and code, and since you use the warnon i'd do int ret; ret = fscrypt_get_extent_context(); WARN_ON_ONCE(ret); > + WARN_ON_ONCE(ret != 0); > + memcpy(iv->raw, ctx.v1.iv, ci->ci_mode->ivsize); > + iv->lblk_num = iv->lblk_num + cpu_to_le64(extent_offset); > + return; > + } > > /* > * Filename encryption. For inode-based policies, filenames are > @@ -93,8 +104,8 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, > > if (flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) { > WARN_ON_ONCE(lblk_num > U32_MAX); > - WARN_ON_ONCE(ci->ci_inode->i_ino > U32_MAX); > - lblk_num |= (u64)ci->ci_inode->i_ino << 32; > + WARN_ON_ONCE(inode->i_ino > U32_MAX); > + lblk_num |= (u64)inode->i_ino << 32; > } else if (flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32) { > WARN_ON_ONCE(lblk_num > U32_MAX); > lblk_num = (u32)(ci->ci_hashed_ino + lblk_num); > diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h > index 3afdaa084773..2092ef63c80a 100644 > --- a/fs/crypto/fscrypt_private.h > +++ b/fs/crypto/fscrypt_private.h > @@ -165,6 +165,27 @@ fscrypt_policy_flags(const union fscrypt_policy *policy) > BUG(); > } > > +#define FSCRYPT_MAX_IV_SIZE 32 > + > +/* > + * fscrypt_extent_context - the encryption context for an extent > + * Whitespace. > + * For filesystems that support extent encryption, this context provides the > + * necessary randomly-initialized IV in order to encrypt/decrypt the data > + * stored in the extent. It is stored alongside each extent, and is > + * insufficient to decrypt the extent: the extent's owning inode(s) provide the > + * policy information (including key identifier) necessary to decrypt. > + */ > +struct fscrypt_extent_context_v1 { > + u8 version; > + u8 iv[FSCRYPT_MAX_IV_SIZE]; > +}; > + > +union fscrypt_extent_context { > + u8 version; > + struct fscrypt_extent_context_v1 v1; > +}; > + > /* > * For encrypted symlinks, the ciphertext length is stored at the beginning > * of the string in little-endian format. > @@ -279,8 +300,6 @@ fscrypt_msg(const struct inode *inode, const char *level, const char *fmt, ...); > #define fscrypt_err(inode, fmt, ...) \ > fscrypt_msg((inode), KERN_ERR, fmt, ##__VA_ARGS__) > > -#define FSCRYPT_MAX_IV_SIZE 32 > - > union fscrypt_iv { > struct { > /* logical block number within the file */ > @@ -628,5 +647,8 @@ int fscrypt_policy_from_context(union fscrypt_policy *policy_u, > const union fscrypt_context *ctx_u, > int ctx_size); > const union fscrypt_policy *fscrypt_policy_to_inherit(struct inode *dir); > +int fscrypt_get_extent_context(const struct inode *inode, u64 lblk_num, > + union fscrypt_extent_context *ctx, > + size_t *extent_offset, size_t *extent_length); > > #endif /* _FSCRYPT_PRIVATE_H */ > diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c > index 90f3e68f166e..0537f710047e 100644 > --- a/fs/crypto/inline_crypt.c > +++ b/fs/crypto/inline_crypt.c > @@ -1,3 +1,4 @@ > + Whitespace. Thanks, Josef
On Mon, Sep 05, 2022 at 08:35:20PM -0400, Sweet Tea Dorminy wrote: > Some filesystems need to encrypt data based on extents, rather than on > inodes, due to features incompatible with inode-based encryption. For > instance, btrfs can have multiple inodes referencing a single block of > data, and moves logical data blocks to different physical locations on > disk in the background; these two features mean inode or > physical-location-based policies will not work for btrfs. > > This change introduces fscrypt_extent_context objects, in analogy to > existing context objects based on inodes. For a filesystem which uses > extents, a new hook provides a new fscrypt_extent_context. During file > content encryption/decryption, the existing fscrypt_context object > provides key information, while the new fscrypt_extent_context provides > IV information. For filename encryption, the existing IV generation > methods are still used, since filenames are not stored in extents. > > As individually keyed inodes prevent sharing of extents, such policies > are forbidden for filesystems with extent-based encryption. > > Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> > --- > fs/crypto/crypto.c | 15 +++++++- > fs/crypto/fscrypt_private.h | 26 ++++++++++++- > fs/crypto/inline_crypt.c | 29 +++++++++++--- > fs/crypto/policy.c | 77 +++++++++++++++++++++++++++++++++++++ > include/linux/fscrypt.h | 41 ++++++++++++++++++++ > 5 files changed, 178 insertions(+), 10 deletions(-) > I'm on vacation at the moment, but I've been thinking about this patchset and I'll leave some quick high-level feedback. I think that you've sort of ended up with something reasonable in this patch, though maybe not for exactly the reasons you thought, and it still needs to be tweaked a bit. Thinking abstractly, an encryption policy indicates that a set of files is encrypted with a particular key. That set of files contains a set of objects containing "file contents", each containing a sequence of file contents blocks. File contents encryption is the encryption that is applied to these objects. With other filesystems, the "file contents objects" are inodes. With btrfs, the "file contents objects" are extents. I think it's fair to say that this is just a difference in the filesystems, and it doesn't need to be explicitly indicated in the encryption policy. What *is* super important, though, is to keep the cryptography consistent. Consider the existing default setting, which derives a per-inode key from the master key and a per-inode nonce, and sets the IV to the offset into the inode. There is a natural mapping of that to extent-based encryption: derive a per-extent key from the master key and a per-extent nonce, and set the IV to the offset into the extent. But you haven't actually implemented that. I assume that you've discarded per-extent keys as infeasible? If that's the case, then the alternative is to do file contents encryption with a per-mode key, using an IV generation method that makes the IVs identify both the file contents object *and* the offset into it, rather than just the latter. The existing methods for that are DIRECT_KEY, IV_INO_LBLK_32, and IV_INO_LBLK_64. DIRECT_KEY uses a 16-byte nonce to identify the file contents object. IV_INO_LBLK_32 and IV_INO_LBLK_64 use a filesystem-assigned ID; currently this ID is inode number, but if they were to be applied to extent-based encryption, it would be an "extent number" instead. So if you do want to implement the DIRECT_KEY method, the natural thing to do would be to store a 16-byte nonce along with each extent, and use the DIRECT_KEY IV generation method as-is. It seems that you've done it a bit differently; you store a 32-byte nonce and generate the IV as 'nonce + lblk_num', instead of 'nonce || lblk_num'. I think that's a mistake -- it should be exactly the same. If the issue is that the 'nonce || lblk_num' method doesn't allow for AES-XTS support, we could extend DIRECT_KEY to do 'nonce + lblk_num' *if* the algorithm has a 16-byte IV size and thus has to tolerate some chance of IV reuse. Note that this change would be unrelated to extent-based encryption, and could be applied regardless of it. Side note: please don't use the phrase "file-based encryption" to distinguish from "extent-based encryption", as "file-based encryption" is already in use to distinguish from block-device based encryption. (See e.g. all the Android documentation that refers to file-based encryption.) Maybe use "inode-based encryption", or "inode-based file contents encryption" to be extra clear. - Eric
diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 7fe5979fbea2..77537736096b 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -81,8 +81,19 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, const struct fscrypt_info *ci) { u8 flags = fscrypt_policy_flags(&ci->ci_policy); + struct inode *inode = ci->ci_inode; + const struct fscrypt_operations *s_cop = inode->i_sb->s_cop; memset(iv, 0, ci->ci_mode->ivsize); + if (s_cop->get_extent_context && lblk_num != U64_MAX) { + size_t extent_offset; + union fscrypt_extent_context ctx; + int ret = fscrypt_get_extent_context(inode, lblk_num, &ctx, &extent_offset, NULL); + WARN_ON_ONCE(ret != 0); + memcpy(iv->raw, ctx.v1.iv, ci->ci_mode->ivsize); + iv->lblk_num = iv->lblk_num + cpu_to_le64(extent_offset); + return; + } /* * Filename encryption. For inode-based policies, filenames are @@ -93,8 +104,8 @@ void fscrypt_generate_iv(union fscrypt_iv *iv, u64 lblk_num, if (flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64) { WARN_ON_ONCE(lblk_num > U32_MAX); - WARN_ON_ONCE(ci->ci_inode->i_ino > U32_MAX); - lblk_num |= (u64)ci->ci_inode->i_ino << 32; + WARN_ON_ONCE(inode->i_ino > U32_MAX); + lblk_num |= (u64)inode->i_ino << 32; } else if (flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32) { WARN_ON_ONCE(lblk_num > U32_MAX); lblk_num = (u32)(ci->ci_hashed_ino + lblk_num); diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h index 3afdaa084773..2092ef63c80a 100644 --- a/fs/crypto/fscrypt_private.h +++ b/fs/crypto/fscrypt_private.h @@ -165,6 +165,27 @@ fscrypt_policy_flags(const union fscrypt_policy *policy) BUG(); } +#define FSCRYPT_MAX_IV_SIZE 32 + +/* + * fscrypt_extent_context - the encryption context for an extent + * + * For filesystems that support extent encryption, this context provides the + * necessary randomly-initialized IV in order to encrypt/decrypt the data + * stored in the extent. It is stored alongside each extent, and is + * insufficient to decrypt the extent: the extent's owning inode(s) provide the + * policy information (including key identifier) necessary to decrypt. + */ +struct fscrypt_extent_context_v1 { + u8 version; + u8 iv[FSCRYPT_MAX_IV_SIZE]; +}; + +union fscrypt_extent_context { + u8 version; + struct fscrypt_extent_context_v1 v1; +}; + /* * For encrypted symlinks, the ciphertext length is stored at the beginning * of the string in little-endian format. @@ -279,8 +300,6 @@ fscrypt_msg(const struct inode *inode, const char *level, const char *fmt, ...); #define fscrypt_err(inode, fmt, ...) \ fscrypt_msg((inode), KERN_ERR, fmt, ##__VA_ARGS__) -#define FSCRYPT_MAX_IV_SIZE 32 - union fscrypt_iv { struct { /* logical block number within the file */ @@ -628,5 +647,8 @@ int fscrypt_policy_from_context(union fscrypt_policy *policy_u, const union fscrypt_context *ctx_u, int ctx_size); const union fscrypt_policy *fscrypt_policy_to_inherit(struct inode *dir); +int fscrypt_get_extent_context(const struct inode *inode, u64 lblk_num, + union fscrypt_extent_context *ctx, + size_t *extent_offset, size_t *extent_length); #endif /* _FSCRYPT_PRIVATE_H */ diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c index 90f3e68f166e..0537f710047e 100644 --- a/fs/crypto/inline_crypt.c +++ b/fs/crypto/inline_crypt.c @@ -1,3 +1,4 @@ + // SPDX-License-Identifier: GPL-2.0 /* * Inline encryption support for fscrypt @@ -466,6 +467,7 @@ EXPORT_SYMBOL_GPL(fscrypt_dio_supported); */ u64 fscrypt_limit_io_blocks(const struct inode *inode, u64 lblk, u64 nr_blocks) { + const struct fscrypt_operations *s_cop = inode->i_sb->s_cop; const struct fscrypt_info *ci; u32 dun; @@ -476,14 +478,29 @@ u64 fscrypt_limit_io_blocks(const struct inode *inode, u64 lblk, u64 nr_blocks) return nr_blocks; ci = inode->i_crypt_info; - if (!(fscrypt_policy_flags(&ci->ci_policy) & - FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)) - return nr_blocks; - /* With IV_INO_LBLK_32, the DUN can wrap around from U32_MAX to 0. */ + if (s_cop->get_extent_context) { + size_t extent_offset, extent_length; + int ret = fscrypt_get_extent_context(inode, lblk, NULL, + &extent_offset, + &extent_length); + if (ret < 0) { + WARN_ON_ONCE(ret < 0); + return 1; + } + return extent_length - extent_offset; + } - dun = ci->ci_hashed_ino + lblk; + if ((fscrypt_policy_flags(&ci->ci_policy) & + FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)) { + /* + * With IV_INO_LBLK_32, the DUN can wrap around from U32_MAX to + * 0. + */ + dun = ci->ci_hashed_ino + lblk; + return min_t(u64, nr_blocks, (u64)U32_MAX + 1 - dun); + } - return min_t(u64, nr_blocks, (u64)U32_MAX + 1 - dun); + return nr_blocks; } EXPORT_SYMBOL_GPL(fscrypt_limit_io_blocks); diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index ed8b7b6531e5..2a92500e1e08 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -175,6 +175,13 @@ static bool fscrypt_supported_v1_policy(const struct fscrypt_policy_v1 *policy, return false; } + if (inode->i_sb->s_cop->get_extent_context && + !(policy->flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY)) { + fscrypt_warn(inode, + "v1 with direct key required for this filesystem"); + return false; + } + if ((policy->flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) && !supported_direct_key_modes(inode, policy->contents_encryption_mode, policy->filenames_encryption_mode)) @@ -222,6 +229,13 @@ static bool fscrypt_supported_v2_policy(const struct fscrypt_policy_v2 *policy, return false; } + if (inode->i_sb->s_cop->get_extent_context && + !(policy->flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY)) { + fscrypt_warn(inode, + "Direct key policy required for this filesystem using extent-based encryption"); + return false; + } + if ((policy->flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) && !supported_direct_key_modes(inode, policy->contents_encryption_mode, policy->filenames_encryption_mode)) @@ -781,6 +795,69 @@ int fscrypt_set_context(struct inode *inode, void *fs_data) } EXPORT_SYMBOL_GPL(fscrypt_set_context); +/** + * fscrypt_get_extent_context() - Get the fscrypt extent context for a location + * @inode: an inode associated with the extent + * @lblk_num: a logical block number within the inode owned by the extent + * @ctx: a pointer to return the context found (may be NULL) + * @extent_offset: a pointer to return the offset of @lblk_num within the + * extent (may be NULL) + * @extent_length: a pointer to return the length of the extent found (may be + * NULL) + * + * Return: 0 on success, -errno on failure + */ +int fscrypt_get_extent_context(const struct inode *inode, u64 lblk_num, + union fscrypt_extent_context *ctx, + size_t *extent_offset, size_t *extent_length) +{ + int ret; + int ctxsize = (ctx == NULL ? 0 : sizeof(*ctx)); + + if (!IS_ENCRYPTED(inode)) + return -ENODATA; + + ret = inode->i_sb->s_cop->get_extent_context(inode, lblk_num, ctx, + ctxsize, extent_offset, + extent_length); + if (ret == ctxsize && (!ctx || ctx->version == 1)) + return 0; + if (ret > 0) + return -EINVAL; + return ret; +} +EXPORT_SYMBOL_GPL(fscrypt_get_extent_context); + +/** + * fscrypt_set_extent_context() - Set an extent's fscrypt context + * + * @inode: an inode to which the extent belongs + * @extent: private data referring to the extent, given by the FS and passed + * to ->set_extent_context() + * + * This should be called after fscrypt_prepare_new_inode(), generally during a + * filesystem transaction. Everything here must be %GFP_NOFS-safe. + * + * Return: 0 on success, -errno on failure + */ +int fscrypt_set_extent_context(struct inode *inode, void *extent) +{ + struct fscrypt_info *ci = inode->i_crypt_info; + union fscrypt_extent_context ctx; + int ivsize; + + if (!IS_ENCRYPTED(inode)) + return -ENODATA; + + ivsize = ci->ci_mode->ivsize; + ctx.v1.version = 1; + get_random_bytes(ctx.v1.iv, ivsize); + + return inode->i_sb->s_cop->set_extent_context(extent, + &ctx, ivsize + 1); +} +EXPORT_SYMBOL_GPL(fscrypt_set_extent_context); + /** * fscrypt_parse_test_dummy_encryption() - parse the test_dummy_encryption mount option * @param: the mount option diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h index 16d2252d5562..136395f4d82d 100644 --- a/include/linux/fscrypt.h +++ b/include/linux/fscrypt.h @@ -94,6 +94,13 @@ struct fscrypt_nokey_name { /* Maximum value for the third parameter of fscrypt_operations.set_context(). */ #define FSCRYPT_SET_CONTEXT_MAX_SIZE 40 +/* + * Maximum value for the third parameter of + * fscrypt_operations.set_extent_context(). Update if fscrypt_private.h: + * FSCRYPT_MAX_IVSIZE changes + */ +#define FSCRYPT_EXTENT_CONTEXT_MAX_SIZE 33 + #ifdef CONFIG_FS_ENCRYPTION /* @@ -152,6 +159,39 @@ struct fscrypt_operations { int (*set_context)(struct inode *inode, const void *ctx, size_t len, void *fs_data); + /* + * Get the fscrypt extent context for a given inode and lblk number. + * + * @inode: the inode to which the extent belongs + * @lblk_num: the block number within the file whose extent is being + * queried + * @ctx: the buffer into which to get the context (may be NULL) + * @len: the length of the @ctx buffer in bytes + * @extent_offset: a pointer to return the offset of @lblk_num within + * the extent whose context is returned (may be NULL) + * @extent_length: a pointer to return the total length of the extent + * whose context was found (may be NULL) + * + * Return: On success, returns the length of the context in bytes, + * which may be less than @len. On failure, returns -ENODATA if the + * extent doesn't have a context, -ERANGE if the context is longer + * than @len, or another -errno code. + */ + int (*get_extent_context)(const struct inode *inode, u64 lblk_num, + void *ctx, size_t len, + size_t *extent_offset, size_t *extent_length); + + /* + * Set the fscrypt extent context for an extent. + * + * @extent: an opaque pointer to the filesystem's extent object + * @ctx: the buffer containing the extent context to set + * @len: the length of the @ctx buffer in bytes + * + * Return: 0 on success, -errno on failure. + */ + int (*set_extent_context)(void *extent, void *ctx, size_t len); + /* * Get the dummy fscrypt policy in use on the filesystem (if any). * @@ -326,6 +366,7 @@ int fscrypt_ioctl_get_nonce(struct file *filp, void __user *arg); int fscrypt_has_permitted_context(struct inode *parent, struct inode *child); int fscrypt_context_for_new_inode(void *ctx, struct inode *inode); int fscrypt_set_context(struct inode *inode, void *fs_data); +int fscrypt_set_extent_context(struct inode *inode, void *extent); struct fscrypt_dummy_policy { const union fscrypt_policy *policy;
Some filesystems need to encrypt data based on extents, rather than on inodes, due to features incompatible with inode-based encryption. For instance, btrfs can have multiple inodes referencing a single block of data, and moves logical data blocks to different physical locations on disk in the background; these two features mean inode or physical-location-based policies will not work for btrfs. This change introduces fscrypt_extent_context objects, in analogy to existing context objects based on inodes. For a filesystem which uses extents, a new hook provides a new fscrypt_extent_context. During file content encryption/decryption, the existing fscrypt_context object provides key information, while the new fscrypt_extent_context provides IV information. For filename encryption, the existing IV generation methods are still used, since filenames are not stored in extents. As individually keyed inodes prevent sharing of extents, such policies are forbidden for filesystems with extent-based encryption. Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> --- fs/crypto/crypto.c | 15 +++++++- fs/crypto/fscrypt_private.h | 26 ++++++++++++- fs/crypto/inline_crypt.c | 29 +++++++++++--- fs/crypto/policy.c | 77 +++++++++++++++++++++++++++++++++++++ include/linux/fscrypt.h | 41 ++++++++++++++++++++ 5 files changed, 178 insertions(+), 10 deletions(-)