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@meta.com, Omar Sandoval <osandov@osandov.com>
Subject: Re: [PATCH v2 07/17] btrfs: adapt readdir for encrypted and nokey names
Date: Mon, 17 Jul 2023 13:46:41 -0400	[thread overview]
Message-ID: <20230717174641.GK691303@perftesting> (raw)
In-Reply-To: <ba4d9065b8109ea74fc1c5bed788e45c95a07e75.1689564024.git.sweettea-kernel@dorminy.me>

On Sun, Jul 16, 2023 at 11:52:38PM -0400, Sweet Tea Dorminy wrote:
> From: Omar Sandoval <osandov@osandov.com>
> 
> Deleting an encrypted file must always be permitted, even if the user
> does not have the appropriate key. Therefore, for listing an encrypted
> directory, so-called 'nokey' names are provided, and these nokey names
> must be sufficient to look up and delete the appropriate encrypted
> files. See 'struct fscrypt_nokey_name' for more information on the
> format of these names.
> 
> The first part of supporting nokey names is allowing lookups by nokey
> name. Only a few entry points need to support these: deleting a
> directory, file, or subvolume -- each of these call
> fscrypt_setup_filename() with a '1' argument, indicating that the key is
> not required and therefore a nokey name may be provided. If a nokey name
> is provided, the fscrypt_name returned by fscrypt_setup_filename() will
> not have its disk_name field populated, but will have various other
> fields set.
> 
> This change alters the relevant codepaths to pass a complete
> fscrypt_name anywhere that it might contain a nokey name. When it does
> contain a nokey name, the first time the name is successfully matched to
> a stored name populates the disk name field of the fscrypt_name,
> allowing the caller to use the normal disk name codepaths afterward.
> Otherwise, the matching functionality is in close analogue to the
> function fscrypt_match_name().
> 
> Functions where most callers are providing a fscrypt_str are duplicated
> and adapted for a fscrypt_name, and functions where most callers are
> providing a fscrypt_name are changed to so require at all callsites.
> 
> Signed-off-by: Omar Sandoval <osandov@osandov.com>
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>  fs/btrfs/btrfs_inode.h   |   2 +-
>  fs/btrfs/delayed-inode.c |  30 +++++++-
>  fs/btrfs/delayed-inode.h |   4 +-
>  fs/btrfs/dir-item.c      |  77 ++++++++++++++++++---
>  fs/btrfs/dir-item.h      |  13 +++-
>  fs/btrfs/extent_io.c     |  38 +++++++++++
>  fs/btrfs/extent_io.h     |   3 +
>  fs/btrfs/fscrypt.c       |  46 +++++++++++++
>  fs/btrfs/fscrypt.h       |  19 ++++++
>  fs/btrfs/inode.c         | 143 ++++++++++++++++++++++++++-------------
>  fs/btrfs/root-tree.c     |   8 ++-
>  fs/btrfs/root-tree.h     |   2 +-
>  fs/btrfs/tree-log.c      |   3 +-
>  13 files changed, 320 insertions(+), 68 deletions(-)
> 
> diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
> index ec4a06a78aff..464059674ae5 100644
> --- a/fs/btrfs/btrfs_inode.h
> +++ b/fs/btrfs/btrfs_inode.h
> @@ -421,7 +421,7 @@ struct inode *btrfs_lookup_dentry(struct inode *dir, struct dentry *dentry);
>  int btrfs_set_inode_index(struct btrfs_inode *dir, u64 *index);
>  int btrfs_unlink_inode(struct btrfs_trans_handle *trans,
>  		       struct btrfs_inode *dir, struct btrfs_inode *inode,
> -		       const struct fscrypt_str *name);
> +		       struct fscrypt_name *name);
>  int btrfs_add_link(struct btrfs_trans_handle *trans,
>  		   struct btrfs_inode *parent_inode, struct btrfs_inode *inode,
>  		   const struct fscrypt_str *name, int add_backref, u64 index);
> diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
> index 6b457b010cbc..919303d29b76 100644
> --- a/fs/btrfs/delayed-inode.c
> +++ b/fs/btrfs/delayed-inode.c
> @@ -1497,6 +1497,7 @@ int btrfs_insert_delayed_dir_index(struct btrfs_trans_handle *trans,
>  
>  	ret = __btrfs_add_delayed_item(delayed_node, delayed_item);
>  	if (unlikely(ret)) {
> +		// TODO: It would be nice to print the base64encoded name here maybe?

Generally we don't leve TODO's around unless they're big, additionally wrong
comment format.

<snip>

> +/*
> + * This function is extremely similar to fscrypt_match_name() but uses an
> + * extent_buffer. Also, it edits the provided argument to populate the disk_name
> + * if we successfully match and previously were using a nokey name.
> + */
> +bool btrfs_fscrypt_match_name(struct fscrypt_name *fname,
> +			      struct extent_buffer *leaf, unsigned long de_name,
> +			      u32 de_name_len)
> +{
> +	const struct fscrypt_nokey_name *nokey_name =
> +		(const void *)fname->crypto_buf.name;

Cast it to the thing it's going to be, als this whol function needs more
newlines.

> +	u8 digest[SHA256_DIGEST_SIZE];
> +
> +	if (likely(fname->disk_name.name)) {
> +		if (de_name_len != fname->disk_name.len)
> +			return false;
> +		return !memcmp_extent_buffer(leaf, fname->disk_name.name,
> +					     de_name, de_name_len);
> +	}
> +	if (de_name_len <= sizeof(nokey_name->bytes))
> +		return false;
> +	if (memcmp_extent_buffer(leaf, nokey_name->bytes, de_name,
> +				 sizeof(nokey_name->bytes)))
> +		return false;
> +	extent_buffer_sha256(leaf, de_name + sizeof(nokey_name->bytes),
> +			     de_name_len - sizeof(nokey_name->bytes), digest);
> +	if (!memcmp(digest, nokey_name->sha256, sizeof(digest))) {
> +		/*
> +		 * For no-key names, we use this opportunity to find the disk
> +		 * name, so future searches don't need to deal with nokey names
> +		 * and we know what the encrypted size is.
> +		 */
> +		fname->disk_name.name = kmalloc(de_name_len, GFP_KERNEL | GFP_NOFS);

GFP_NOFS is sufficient.

> +		if (!fname->disk_name.name)
> +			fname->disk_name.name = ERR_PTR(-ENOMEM);

This part worries me, we use this code everywhere and it's just screaming for a
gotcha, I'd rather return an error in this case.  Thanks,

Josef

  parent reply	other threads:[~2023-07-17 17:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17  3:52 [PATCH v2 00/17] btrfs: add encryption feature Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 01/17] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 02/17] btrfs: disable verity " Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 03/17] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 04/17] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2023-07-17 15:34   ` Luís Henriques
2023-07-17 17:28     ` David Sterba
2023-07-18  8:36       ` Luís Henriques
2023-07-17  3:52 ` [PATCH v2 05/17] btrfs: add inode encryption contexts Sweet Tea Dorminy
2023-07-17 15:41   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 06/17] btrfs: add new FEATURE_INCOMPAT_ENCRYPT flag Sweet Tea Dorminy
2023-07-17 15:42   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 07/17] btrfs: adapt readdir for encrypted and nokey names Sweet Tea Dorminy
2023-07-17 15:34   ` Luís Henriques
2023-07-17 17:46   ` Josef Bacik [this message]
2023-07-17  3:52 ` [PATCH v2 08/17] btrfs: use correct name hash for " Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 09/17] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 10/17] btrfs: add encryption to CONFIG_BTRFS_DEBUG Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 11/17] btrfs: add get_devices hook for fscrypt Sweet Tea Dorminy
2023-07-17 17:51   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 12/17] btrfs: turn on inlinecrypt mount option for encrypt Sweet Tea Dorminy
2023-07-17 15:34   ` Luís Henriques
2023-07-17 17:55   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 13/17] btrfs: turn on the encryption ioctls Sweet Tea Dorminy
2023-07-17  3:52 ` [PATCH v2 14/17] btrfs: create and free extent fscrypt_infos Sweet Tea Dorminy
2023-07-17 17:58   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 15/17] btrfs: start tracking extent encryption context info Sweet Tea Dorminy
2023-07-17 18:11   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 16/17] btrfs: explicitly track file extent length and encryption Sweet Tea Dorminy
2023-07-17 15:30   ` Josef Bacik
2023-07-17 18:12   ` Josef Bacik
2023-07-17  3:52 ` [PATCH v2 17/17] btrfs: save and load fscrypt extent contexts Sweet Tea Dorminy
2023-07-17 18:15   ` Josef Bacik

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=20230717174641.GK691303@perftesting \
    --to=josef@toxicpanda.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=osandov@osandov.com \
    --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.