All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	Eric Biggers <ebiggers@kernel.org>, Chris Mason <clm@fb.com>,
	David Sterba <dsterba@suse.com>,
	linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
	kernel-team@fb.com
Subject: Re: [PATCH v2 05/20] fscrypt: add extent-based encryption
Date: Thu, 8 Sep 2022 11:33:26 -0400	[thread overview]
Message-ID: <YxoLRh0b4Qf8BtUh@localhost.localdomain> (raw)
In-Reply-To: <48d09d4905d0c6e5e72d37535eb852487f1bd9cb.1662420176.git.sweettea-kernel@dorminy.me>

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

  parent reply	other threads:[~2022-09-08 15:33 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06  0:35 [PATCH v2 00/20] btrfs: add fscrypt integration Sweet Tea Dorminy
2022-09-06  0:35 ` [PATCH v2 01/20] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2022-09-08 13:41   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 02/20] fscrypt: add flag allowing partially-encrypted directories Sweet Tea Dorminy
2022-09-08 13:43   ` Josef Bacik
2022-09-12  1:42   ` Eric Biggers
2022-09-15 18:58     ` Sweet Tea Dorminy
2022-09-13 10:07   ` Anand Jain
2022-09-13 11:02     ` Neal Gompa
2022-09-06  0:35 ` [PATCH v2 03/20] fscrypt: add fscrypt_have_same_policy() to check inode compatibility Sweet Tea Dorminy
2022-09-08 13:53   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 04/20] fscrypt: allow fscrypt_generate_iv() to distinguish filenames Sweet Tea Dorminy
2022-09-08 14:01   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 05/20] fscrypt: add extent-based encryption Sweet Tea Dorminy
2022-09-07 19:59   ` Omar Sandoval
2022-09-08 15:33   ` Josef Bacik [this message]
2022-09-10 18:53   ` kernel test robot
2022-09-12  1:34   ` Eric Biggers
2022-09-06  0:35 ` [PATCH v2 06/20] fscrypt: document btrfs' fscrypt quirks Sweet Tea Dorminy
2022-09-08 15:34   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 07/20] btrfs: store directory's encryption state Sweet Tea Dorminy
2022-09-08 15:37   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 08/20] btrfs: use fscrypt_names instead of name/len everywhere Sweet Tea Dorminy
2022-09-07 20:04   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 09/20] btrfs: setup fscrypt_names from dentrys using helper Sweet Tea Dorminy
2022-09-08 19:11   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 10/20] btrfs: factor a fscrypt_name matching method Sweet Tea Dorminy
2022-09-08 19:27   ` Josef Bacik
2022-09-09 10:15   ` David Sterba
2022-09-09 13:00     ` Christoph Hellwig
2022-09-09 13:34       ` David Sterba
2022-09-16 22:18         ` J Lovejoy
2022-09-19  2:00           ` Bradley M. Kuhn
2022-09-19 17:20             ` David Sterba
2022-09-19 16:52           ` David Sterba
2022-09-09 13:41       ` Chris Mason
2022-09-06  0:35 ` [PATCH v2 11/20] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-09-06  6:36   ` kernel test robot
2022-09-07 20:11   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 12/20] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-09-07 20:17   ` David Sterba
2022-09-07 20:42     ` Sweet Tea Dorminy
2022-09-12  1:50       ` Eric Biggers
2022-09-08 19:42   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 13/20] btrfs: add fscrypt_context items Sweet Tea Dorminy
2022-09-07 20:43   ` David Sterba
2022-09-08 20:06   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 14/20] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-09-08 20:07   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 15/20] btrfs: store a fscrypt extent context per normal file extent Sweet Tea Dorminy
2022-09-07 21:10   ` David Sterba
2022-09-07 21:39     ` Sweet Tea Dorminy
2022-09-09 10:04       ` David Sterba
2022-09-06  0:35 ` [PATCH v2 16/20] btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag Sweet Tea Dorminy
2022-09-09 11:35   ` David Sterba
2022-09-12  1:36   ` Eric Biggers
2022-09-06  0:35 ` [PATCH v2 17/20] btrfs: reuse encrypted filename hash when possible Sweet Tea Dorminy
2022-09-07 21:24   ` David Sterba
2022-09-06  0:35 ` [PATCH v2 18/20] btrfs: adapt directory read and lookup to potentially encrypted filenames Sweet Tea Dorminy
2022-09-08 20:15   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 19/20] btrfs: encrypt normal file extent data if appropriate Sweet Tea Dorminy
2022-09-08 20:19   ` Josef Bacik
2022-09-06  0:35 ` [PATCH v2 20/20] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-09-07 21:33   ` David Sterba
2022-09-06 22:35 ` [PATCH v2 00/20] btrfs: add fscrypt integration Eric Biggers
2022-09-06 23:01   ` Sweet Tea Dorminy
2022-09-06 23:10     ` Eric Biggers
2022-09-07  0:01       ` Sweet Tea Dorminy
2022-09-07 19:38 ` David Sterba

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=YxoLRh0b4Qf8BtUh@localhost.localdomain \
    --to=josef@toxicpanda.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=sweettea-kernel@dorminy.me \
    --cc=tytso@mit.edu \
    /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.