On Sun, Jul 09, 2023 at 02:53:43PM -0400, Sweet Tea Dorminy wrote:
> Currently, for inode encryption, once an inode is open IO will not fail
> due to lack of key until the inode is closed. Even if the key is
> removed, open inodes will continue to use the key.
>
> For extent encryption, it's a little harder, since the extent may not be
> createdi/loaded until well after the REMOVE_KEY ioctl is called. To be
> as similar to inode based encryption as plausible, this changes key
> removal to be 'soft' for extent-based encryption, allowing new extents
> to use keys which were in use by open inodes at the time of removal;
> this hopefully follows the discussion at [1].
>
> [1] https://lore.kernel.org/linux-fscrypt/248eac32-96cc-eb2e-85da-422a8d75a376@xxxxxxxxxx/T/#m48f43837cf98e0212de2e70aa6435320e3532d6e
>
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx>
> ---
> fs/crypto/fscrypt_private.h | 37 ++++++++++++++++++++++++++++-----
> fs/crypto/keyring.c | 41 ++++++++++++++++++++++++++++---------
> fs/crypto/keysetup.c | 32 ++++++++++++++++++++++++++++-
> 3 files changed, 94 insertions(+), 16 deletions(-)
>
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index 8bf27ceeecd1..926531597e7b 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -332,6 +332,21 @@ static inline bool fscrypt_uses_extent_encryption(const struct inode *inode)
> return false;
> }
>
> +/**
> + * fscrypt_fs_uses_extent_encryption() -- whether a filesystem uses per-extent
> + * encryption
> + *
> + * @sb: the superblock of the filesystem in question
> + *
> + * Return: true if the fs uses per-extent fscrypt_infos, false otherwise
> + */
> +static inline bool
> +fscrypt_fs_uses_extent_encryption(const struct super_block *sb)
> +{
> + // No filesystems currently use per-extent infos
> + return false;
Wrong comment format.
> +}
> +
> /**
> * fscrypt_get_info_ino() - get the ino or ino equivalent for an info
> *
> @@ -556,11 +571,14 @@ struct fscrypt_master_key {
>
> /*
> * The secret key material. After FS_IOC_REMOVE_ENCRYPTION_KEY is
> - * executed, this is wiped and no new inodes can be unlocked with this
> - * key; however, there may still be inodes in ->mk_decrypted_inodes
> - * which could not be evicted. As long as some inodes still remain,
> - * FS_IOC_REMOVE_ENCRYPTION_KEY can be retried, or
> - * FS_IOC_ADD_ENCRYPTION_KEY can add the secret again.
> + * executed, no new inodes can be unlocked with this key; however,
> + * there may still be inodes in ->mk_decrypted_inodes which could not
> + * be evicted. For inode-based encryption, the secret is wiped; for
> + * extent-based encryption, the secret is preserved while inodes still
> + * reference it, as they may need to create new extents using the
> + * secret to service IO; @soft_deleted is set to true then. As long as
> + * some inodes still remain, FS_IOC_REMOVE_ENCRYPTION_KEY can be
> + * retried, or FS_IOC_ADD_ENCRYPTION_KEY can add the secret again.
> *
> * While ->mk_secret is present, one ref in ->mk_active_refs is held.
> *
> @@ -599,6 +617,13 @@ struct fscrypt_master_key {
> struct list_head mk_decrypted_inodes;
> spinlock_t mk_decrypted_inodes_lock;
>
> + /*
> + * Whether the key is unavailable to new inodes, but still available
> + * to new extents within decrypted inodes. Protected by
> + * ->mk_decrypted_inodes_lock.
> + */
> + bool mk_soft_deleted;
> +
You say this is protected by mk_decrypted_inodes_lock, but you only ever take it
when you set it to false. It looks like it's more used to gate behavior, so the
locking is sort of inconsistent and doesn't appear to be needed? Can you just
do READ_ONCE()/WRITE_ONCE() and it's fine? If not you need to wrap it in the
lock where you're accessing it. Thanks,
Josef
|